<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2802" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=328140917-10032006><FONT 
face="Courier New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</FONT></SPAN></DIV>
<DIV><SPAN class=328140917-10032006><FONT face="Courier New">I don't believe 
anyone is/can give you much more hope with PF variables. Could be, setting 
PFIXBUILD=2 might help... but I would, of course, test this. Also, I'm not sure 
what is meant by the "old 4.1 sorting". Doe it mean you can't have multi-segment 
indexes?&nbsp; Don't know. Ken, can illucidate.</FONT></SPAN></DIV>
<DIV><SPAN class=328140917-10032006><FONT 
face="Courier New"></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=328140917-10032006><FONT 
face="Courier New">Otherwise,</FONT></SPAN></DIV>
<DIV><SPAN class=328140917-10032006></SPAN><SPAN 
class=328140917-10032006></SPAN><SPAN class=328140917-10032006><FONT 
face="Courier New"></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=328140917-10032006><FONT face="Courier New">I think you need to 
look to an overall hardware/software upgrade to get the results you want. For 
now, an overnight of index building seems the only fate you 
have.</FONT></SPAN></DIV>
<DIV><SPAN class=328140917-10032006><FONT 
face="Courier New"></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=328140917-10032006><FONT face="Courier New">You did not mention 
the hard disks and type that you are using. I blieve these would be of paramount 
importance with questions of index-building speed. Well, it's true that the CPu 
does the intensive work of indexing, but you have to get the records "to" the 
CPU and that is disk i/o and memory caching. Assuming the filePro routines let 
you do the best you can with caching, the onus is on the disk i/o to speed 
things to the fastest they can be at this bottle neck... and this is the 
sloooowwest point in the chain for indexing. So, here is a scenario that just 
happened to me. I cahnged a single disk 9gig Baracuda running on a SCSI-2 
adpator... (and a Pentium 100Mhz machine to a 36Gb ultra 310 dirve, running an 
LVD adaptor on a 2.8Ghz Celeron. The indexing of one large file used to take 4.5 
hours. On the new system, it took just under 3 minutes. Needless to say the 
customer was pretty happy. Also, here daily which took about 5 to 8 minutes to 
run happened so fast that she called me and said it was broken. Becuase it 
happened in the blink of an eye she thought it hadn't run. :-)&nbsp; 
</FONT></SPAN></DIV>
<DIV><SPAN class=328140917-10032006><FONT 
face="Courier New"></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=328140917-10032006><FONT face="Courier New">Okay, the addition 
of the 2.8Gb Celeron over the Pentium 100Mhz is a 28 times increase in processor 
speed... but I believe it was the fantastic difference in the drive chain. If 
you can afford 15K or 20K drives and put these on your same 2.8 it will be 
great. If you put them on a Pentium Extrem 3.73Ghz CPU... I think your hour per 
index will drop substantially... maybe down to single digit minutes even. 
Judging (guessing) by the 5.0.9 software you are running, it is probable that 
you are not running the newest SCSI drives... more probably SCSI 2.&nbsp; So, 
you can expect huge speed-ups with new hardware.</FONT></SPAN></DIV>
<DIV><SPAN class=328140917-10032006><FONT 
face="Courier New"></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=328140917-10032006><FONT face="Courier New">So, changing to 
this new stuff will make a world of difference... and we haven't even mentioned 
optical drives yet. :-)</FONT></SPAN></DIV>
<DIV><SPAN class=328140917-10032006><FONT 
face="Courier New"></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=328140917-10032006><FONT face="Courier New">John 
Esak</FONT></SPAN></DIV>
<DIV><SPAN class=328140917-10032006><FONT 
face="Courier New"></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=328140917-10032006><FONT 
face="Courier New"></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #ffff00 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> 
  filepro-list-bounces@lists.celestial.com 
  [mailto:filepro-list-bounces@lists.celestial.com]<B>On Behalf Of </B>Mike 
  Fedkiw<BR><B>Sent:</B> Friday, March 10, 2006 10:40 AM<BR><B>To:</B> 
  filepro-list@lists.celestial.com<BR><B>Subject:</B> Indexing a file with 
  3,000,000 records FAST ?<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial size=2><FONT face="Times New Roman" 
  size=3>system<BR>filepro 5.0.09<BR>windows 2000 advances server<BR>P4 2.4 
  GHz<BR>2 gig of ram<BR><BR>BTW, I don't want to upgrade to 5.0.14. I am 
  waiting for next ver. Ray said<BR>that the bug slowing browse window scrolling 
  and flickering when using lots<BR>of show commands would be fixed in ver 
  5.0.15 and above.<BR><BR>I have a file with about three million records. 
  Recently I deleted some<BR>records out of this file. Now I am getting node 
  errors on a particular<BR>Index. I rebuilt one index this morning and it took 
  over an hour. now add up<BR>(a-p times 1 hour). That's 16 hours. There has to 
  be a faster/better way. I<BR>did try setting PFNUMIXBUF=15000 and that helped 
  a little. What about<BR>PFNUMIXBUILD.<BR><BR>Any help will be greatly 
  appreciated. I am not looking forward to fifteen<BR>hours of indexing for one 
  file.<BR><BR>Thanks in Advance, Mike 
Fedko</FONT><BR></FONT></DIV></BLOCKQUOTE></BODY></HTML>