>I have a commercial VFP 9.0 SP1 application with hundreds of locations and several thousand users.
>
>At one location and only on one computer at that location I have a user where VFP will lock up on the way into a particular form/screen. The problem is tied to the computer. The same user can log into other computers and work fine. If another user logs into the problem computer they have the same problem. There is no VFP error message. The Windows event log shows:
>
>Description
>A problem caused this program to stop interacting with Windows.
>
>Problem signature
>Problem Event Name: AppHangB1
>
>
>I have isolated the problem to a single command which is a USE statement that opens a remote view to a MS SQL Server table. The remote view is parameterized and I can create a button on the main menu that does nothing more than set the parameter value and try and open the table and it will lockup the application every time.
>
>vp_nSurveyID = 1909
>use vp_Survey_Instrument alias Survey_Instrument
>
>The odd part is that the application is being run from a shared network folder. Other users on the same network can open the form or run this test without problem. And much to my surprise the user/computer with the problem can select another set of records (which just changes the parameter to something like vp_nSurveyID = 1908) and opens the same form and that works. (There are only 9 sets of records in the table and 3 of them fail and 6 work for that one user/computer.) That would normally indicate an issue with the data. However on any other computer at the same center they can work with all 9 sets of records without errors, which contra-indicates that it is a data problem.
>
>I had them send me their SQL Server database and I restored it at my location and like the other users at the client site I had no problems and see nothing irregular in the data.
>
>They have tried various things on that one computer like running it in Safe Mode, running the application as administrator, uninstalling and reinstalling the FoxPro runtime files, copying the entire application to a local folder instead of running it from the network share, and since it makes local copies of the database container (e.g. dbc, dct, dcx files) I had them delete those files in case they were corrupted so the application would make a new set of those the next time it started. None of these helped.
>
>I am starting to think of esoteric things like a bad memory chip.
>Any ideas?

I wish I would of seen this before. I would of tried re-installing the ODBC drivers...