The VFP Help... About... for my VFP7SP1 shows "VFP7 SP1" on the top line.

If you have other copies around, be sure to check them all, especially if there are other people involved.

good luck and that time difference is dramatic to say the least! Almost makes one thing that possibly the HD itself *may* have some problem.

Also, HilmarZ's observation bears checking carefully because it sure looks like Rushmore ain't in these longer cases.


>For Jan data it took 2 seconds.
>For Feb data it took 3 seconds.
>For Mar data it took 3 seconds.
>For Apr data it took 7 minutes 11 seconds.
>For May data it took 2 minutes 36 seconds.
>
>Is there a file I can search for to tell if it's VFP7SP1?
>
>
>
>>Sorry, Paul, but I don't know how to read the timings from that info.
>>
>>I really just wanted to know if the times with the double-szed indexes were double too, or maybe just 5%-10% more or...
>>
>>So you are fully confident that NO SP1 of VFP7 could be lurking about and used for any part of reindex type processing?
>>
>>again, good luck
>>
>>
>>>Here are the processing times for each month.
>>>
>>>2004/06/18 07:57:57 AM Processing 2004 01...logins ...newerceng ...logouts ...accessreq ...timeouts ...failaccess ...lu ...reposimx ...Done.
>>>2004/06/18 07:57:59 AM Processing 2004 02...logins ...newerceng ...logouts ...accessreq ...timeouts ...failaccess ...lu ...reposimx ...Done.
>>>2004/06/18 07:58:02 AM Processing 2004 03...logins ...newerceng ...logouts ...accessreq ...timeouts ...failaccess ...lu ...reposimx ...Done.
>>>2004/06/18 07:58:05 AM Processing 2004 04...logins ...newerceng ...logouts ...accessreq ...timeouts ...failaccess ...lu ...reposimx ...Done.
>>>2004/06/18 08:05:16 AM Processing 2004 05...logins ...newerceng ...logouts ...accessreq ...timeouts ...failaccess ...lu ...reposimx ...Done.
>>>2004/06/18 08:07:52 AM Done.
>>>
>>>Here are the table and index sizes.
>>>
>>>jan2004\accessreq.dbf 1184946216 bytes
>>>jan2004\accessreq.cdx 361071616 bytes
>>>feb2004\accessreq.dbf 1289297316 bytes
>>>feb2004\accessreq.cdx 399453696 bytes
>>>mar2004\accessreq.dbf 1522693316 bytes
>>>mar2004\accessreq.cdx 469294080 bytes
>>>apr2004\accessreq.dbf 1360570416 bytes
>>>apr2004\accessreq.cdx 673404928 bytes
>>>may2004\accessreq.dbf 1296286061 bytes
>>>may2004\accessreq.cdx 272089088 bytes
>>>
>>>
>>>Here are the structures.
>>>
>>>Structure for table: JAN2004\ACCESSREQ.DBF
>>>Number of data records: 6405111
>>>Date of last update: 2004/05/14
>>>Code Page: 1252
>>>Field Field Name Type Width Dec Index Collate Nulls Next Step
>>> 1 DATETIME Character 17 No
>>> 2 KEY Character 1 No
>>> 3 SESSIONNUM Character 16 Asc Machine No
>>> 4 PRODCODE Character 21 Asc Machine No
>>> 5 SEGMENT Character 20 No
>>> 6 DATE Character 10 Asc Machine No
>>> 7 TIME Character 8 No
>>> 8 DATE_TIME DateTime 8 No
>>> 9 ACCOUNTNUM Character 10 Asc Machine No
>>> 10 SUBACCOUNT Character 13 Asc Machine No
>>> 11 TRANSPCODE Character 10 Asc Machine No
>>> 12 PRODDESC Character 50 No
>>>** Total ** 185
>>>
>>>Structure for table: FEB2004\ACCESSREQ.DBF
>>>Number of data records: 6969171
>>>Date of last update: 2004/05/14
>>>Code Page: 1252
>>>Field Field Name Type Width Dec Index Collate Nulls Next Step
>>> 1 DATETIME Character 17 No
>>> 2 KEY Character 1 No
>>> 3 SESSIONNUM Character 16 Asc Machine No
>>> 4 PRODCODE Character 21 Asc Machine No
>>> 5 SEGMENT Character 20 No
>>> 6 DATE Character 10 Asc Machine No
>>> 7 TIME Character 8 No
>>> 8 DATE_TIME DateTime 8 No
>>> 9 ACCOUNTNUM Character 10 Asc Machine No
>>> 10 SUBACCOUNT Character 13 Asc Machine No
>>> 11 TRANSPCODE Character 10 Asc Machine No
>>> 12 PRODDESC Character 50 No
>>>** Total ** 185
>>>
>>>Structure for table: MAR2004\ACCESSREQ.DBF
>>>Number of data records: 8230771
>>>Date of last update: 2004/05/14
>>>Code Page: 1252
>>>Field Field Name Type Width Dec Index Collate Nulls Next Step
>>> 1 DATETIME Character 17 No
>>> 2 KEY Character 1 No
>>> 3 SESSIONNUM Character 16 Asc Machine No
>>> 4 PRODCODE Character 21 Asc Machine No
>>> 5 SEGMENT Character 20 No
>>> 6 DATE Character 10 Asc Machine No
>>> 7 TIME Character 8 No
>>> 8 DATE_TIME DateTime 8 No
>>> 9 ACCOUNTNUM Character 10 Asc Machine No
>>> 10 SUBACCOUNT Character 13 Asc Machine No
>>> 11 TRANSPCODE Character 10 Asc Machine No
>>> 12 PRODDESC Character 50 No
>>>** Total ** 185
>>>
>>>Structure for table: APR2004\ACCESSREQ.DBF
>>>Number of data records: 7354431
>>>Date of last update: 2004/06/14
>>>Code Page: 1252
>>>Field Field Name Type Width Dec Index Collate Nulls Next Step
>>> 1 DATETIME Character 17 No
>>> 2 KEY Character 1 No
>>> 3 SESSIONNUM Character 16 No
>>> 4 PRODCODE Character 21 No
>>> 5 SEGMENT Character 20 No
>>> 6 DATE Character 10 No
>>> 7 TIME Character 8 No
>>> 8 DATE_TIME DateTime 8 No
>>> 9 ACCOUNTNUM Character 10 No
>>> 10 SUBACCOUNT Character 13 No
>>> 11 TRANSPCODE Character 10 No
>>> 12 PRODDESC Character 50 No
>>>** Total ** 185
>>>
>>>Structure for table: MAY2004\ACCESSREQ.DBF
>>>Number of data records: 7006948
>>>Date of last update: 2004/06/16
>>>Code Page: 1252
>>>Field Field Name Type Width Dec Index Collate Nulls Next Step
>>> 1 DATETIME Character 17 No
>>> 2 KEY Character 1 No
>>> 3 SESSIONNUM Character 16 Asc Machine No
>>> 4 PRODCODE Character 21 Asc Machine No
>>> 5 SEGMENT Character 20 No
>>> 6 DATE Character 10 Asc Machine No
>>> 7 TIME Character 8 No
>>> 8 DATE_TIME DateTime 8 No
>>> 9 ACCOUNTNUM Character 10 Asc Machine No
>>> 10 SUBACCOUNT Character 13 Asc Machine No
>>> 11 TRANSPCODE Character 10 Asc Machine No
>>> 12 PRODDESC Character 50 No
>>>** Total ** 185
>>>
>>>
>>>>Paul,
>>>>
>>>>The problem was introduced in VFP7 SP1, so if you are using VFP7 vanilla you won't see that bug.
>>>>Is it possible that you "upgraded" to a SP1 version in the recent past... or possibly that your reindexing is being run on a SP1 version?
>>>>
>>>>How much slower are the processes now?
>>>>
>>>>The collate sequence also sound like it could be involved and probably warrants more investigation.
>>>>
>>>>good luck
>>>>
>>>>
>>>>
>>>>>Thanx for the quick reply, but I've been using VFP7 since it came out so I don't think that is the case. Also I have tried reindexing with VFP8(and service pack) with the same result.
>>>>>
>>>>>>Hi Paul,
>>>>>>
>>>>>>There's a bug in VFP7 that significantly increases the size of indexes created in it compare to VFP6. It has been fixed in VFP8.
>>>>>>
>>>>>>>Not sure quite how to explain this, but here goes. First of all, I am using VFP 7.0 with all of the service packs installed on Win2K Pro. I deal with a lot of large tables - 800MB to 1.7GB. They all have the exact same columns and indexes, just different data, oh and nulls are not allowed. It's a data warehouse, so once the tables are loaded they are pretty much static. The code I've been running has been running really fast, like it's supposed to. Recently, within the last month, I noticed that my processes that report on these tables have slowed down considerably on the last months batch of data, but run just as fast as they had been on months prior. In comparing the size of the indexes relative to the tables, I noticed the indexes have doubled in size, while the size of the data is about the same. What would cause this??? I noticed that somehow the collation sequence had gotten changed from machine to general, so I deleted the indexes on last months data and set the
>>>>>>>collation sequence back to machine and rebuilt the indexes. The indexes did decrease in size, but the process still slows down when it hits last months tables. I thought, ok, let's delete the indexes from the April data and rebuild them just to see what happens. Well, now Aprils data is just as slow as May data! What do I need to do to get my speed back?!? Is there some other setting that I am missing?