>>>This VFP 6 app has been running since 2001,
>>>Last week the client noticed that in the first line of a report (a grouped line) the numbers were doubled.
>>>Just the first line. All other lines were OK.
>>>A browse of the table showed that the data was correct.
>>>After futzing for a while, I reindexed the table and the report showed OK In the preview screen.
>>>That's the first time I've had to reindex a table in that app.
>>>This particular table is used to house monthly data and is zapped every month when the month is closed.
>>>I thought, "Wow 14 years and one blown index.. that's not shabby, is it?"
>>>Today, the same client called and said that the report was OK in the preview screen, but when she clicked the print button and printed the report, the first line was doubled again.
>>>I got the data here and was able to reproduce it.
>>>OK in the preview, doubled when printed.
>>>Strange.
>>>That's a first for me. I've seen many format differences but never saw a report have a different grouping result when printed.
>>>I reindexed the table again and packed it this time.
>>>Now the printed version is OK.
>>>Any ideas as to what might be going on?
>>
>>In addition to what others have suggested, on some occasions when dealing with intermittent index problems I've had to:
>>
>>- Replace the .CDX file with a known good one e.g. from an old backup (or even from your dev environment). Even if it's way out of date, you can then REINDEX to bring it back to date. A similar thing would be to DELETE TAG ALL and manually rebuild the tags, but if the table is part of a .DBC and there are relations set etc. that can cause problems. I've found it's easier just to nuke the old CDX and drop in a new one.
>>
>>- Check the DBF for the presence of odd ASCII characters, especially CHR( 0 ). I've seen these get injected into tables, usually in character type fields ( Char, Memo etc. ) when workstations crash or get disconnected from the network for any reason
>>
>>- If they've recently replaced a lot of equipment, hopefully they haven't moved to wireless networking.
>
>
>Thank you, Al.
>We have a utility that does DELETE TAG and rebuilds the CDX from a data dictionary.
>Running that and packing the table did the job.
>This is an existing Terminal Server installation remoting to a large LAN. Just new workstations.

If you have new workstations, are they directly opening DBFs/CDXs etc.? And, is it possible the old ones were XP, and the new ones are Win7, Win8 etc.?

If both those conditions are true then you may be in a situation where the workstations are connecting to the server via SMB2 or later, rather than SMB1. That requires adjusting some networking parameters on Vista or later workstations so that things like index corruption don't occur.

This SMB2(+) bug is something which I understand Microsoft has never fully addressed so there's some controversy over how to work around it. Some people advocate disabling SMB2 or later completely but I think that may be overkill, and some newer network functions rely on the newer protocols. Alaska Software offers a more targeted approach - you can download and run a patch on all workstations that are Vista or later: http://www.alaska-software.com/fixes/smb2/overview.shtm

Also, if there is a new antivirus program on the new workstations, and they are accessing VFP data files directly, you may need to exclude the data and temp file folders from real-time scanning.