>All,
>
>I am supporting a legacy application writtein in FoxPro 2.6a for Windows. The application has been running fine for years with the usual occasional problems that can happen with FoxPro in a multi-user environment.
>
>However we had a problem recently that defied explanation and I wanted your thoughts on it.
>
>We recently upgraded most of our desktops to Windows 7. It appears that our FoxPro for Windows application works fine on it. However, a user recently began having a problem printing a report for certain records. We tried all the usual troubleshooting efforts. We deleted the user resource file, reindexed all the tables etc. None of this worked. We tried from other machines and the same thing occured. Renaming the report file would solve the problem only temporarily. Tried updating print drivers, using postscript drivers, using universal drivers etc. Again the report would still hang for certain records.
>
>Now the report in question did have function calls in some of the field expressions. I tried creating a new version of the report without any expressions or function calls at all and this cleared the problem in testing. So I tried to put the expression/functions back on the report one by one to isolate the problem function. But the behavior was never consistant and I could never isolate it to just one function call or expression.
>
>After a few days of trying to trouble and resolving to re-write the report and just do all the expression formatting and function calls in the query leading up to the report call, the problem just dissapeared. All of a sudden every data record was printing fine. Other problems in the system seemed to be resolved too.
>
>Now to verify our assumption that the issue was data related, we had the data restored from a day when we knew it was bad, and sure enough we could reproduce the problem with that data set. We looked at that data set and saw no obvious corruption or funny characters.
>
>It's a mystery that I would still like to solve. I don't like when a problem just appears and dissapears with no explantion.
>
>Thoughts?

Index files can become corrupted in ways that can't be fixed with a simple REINDEX command. In that case, you have 2 choices:

1. Delete all the tags from a table, then manually re-create them

2. Overwrite the suspected bad CDX file with a known good one e.g. from backup (even if it's older or newer, or even has no records), then REINDEX the corresponding table

The second possibility is something you can test:

1. Now that your data are "good", backup its CDXs
2. Restore the "bad" data
3. Overwrite the bad data's CDX files with the known good ones
4. REINDEX the bad data's tables
5. Test your reports

Another thing that can cause problems is corrupt data in DBF or FPT files. One thing I've seen from time to time is the appearance of CHR( 0 ) characters in all or part of a field/column, or an entire record/row in a data table. This can usually be traced to workstation crashes, network glitches etc. These appear in a BROWSE window as thin solid black vertical bars. If any of these are present in your data, you will encounter intermittent problems.

If the differences between the bad and good data are not extensive, and can be pinpointed, maybe you could inspect the tables for the presence of bad characters. Remember to inspect with SET DELETED OFF, as corrupted columns or rows can cause problems even if the row is DELETED().

********************

Another thing to be aware of, with newer environments, is the possibility that your workstations and servers are communicating via SMB2 rather than the older SMB (v1). This happens by default if Vista or Win7 talk to other Vista or Win7 workstations and/or Server 2008/2008 R2 servers. Under some circumstances this can cause index corruption with FoxPro, and with other "file-server" databases such as Microsoft Access. See Thread#1440085

Unhappily, the chances of this issue ever getting fixed don't look good, at this point.