Do Multi-core processors cause "Record in Use" errors in Visual FoxPro?

Topics: General
Apr 22, 2010 at 7:51 PM

We have an 11 year old Visual FoxPro application that this company developed.  I started working on this 2 years ago and I am noticing a lot of the same consistent errors at our customer sites.  The application is a single thread single tear application that accesses a local Visual FoxPro database.  The users access the application by logging into a server via Terminal Server.  So the standard setup is one BIG server with the app and DB local with multiple terminal server sessions accessing the app.  In the last two years my team has addressed a lot of the big errors but we are baffled by the “record in use” error.  Our larger clients (20 to 60 users) appear to encounter it much more than the smaller clients.  When they encounter the error, we reindex tables in the database and it makes the error go away.  However, within weeks the errors come back.  We then reindex again and it works.  I know, you’re asking yourself why we don’t have them reindex every night.  Well we can but that does not solve the problem it just hides it.  I would prefer to fix the problem.

I hear from others in the company that it appears that we have been having more of these error in the past 4 years than ever before.  The main difference that we have is really the hardware.  Now our customers have much bigger, faster servers.  I believe that the main culprit is the speed of the processors and the multi-core hardware.  I have found documents about Visual FoxPro and multithreading that lead me to this suspicion.  According to Microsoft docs, every time a “select” statement is made, the OS runs that in another thread if available.  Without coding for that, it appears to me that this could cause errors like “record in use” and “sequence out of sync”.

If there is anyone out there that knows VFP, can you shed some light on this for me?  Am I on the right track or out to left field?

Coordinator
May 14, 2010 at 12:08 PM

I haven't seen anything like this, thousands of installations and many running dual and quad-core... also plenty of multi-cpu server installs without incident. What are the lines of code that "record in use" error is appearing from? Try changing the settings you have for Set Reprocess and Set TableValidate? I'm not sure what the reindexing would have to do with the "Record in use" error... could be just the fact that you have all users exit system to reindex database and then they come back in and don't have the problem for awhile until the next time two user's tangle over the same record. That'd be my guess.

I've had some hard to get rid of File In Use errors in large mutli-user deployments, but never record in use errors that I couldn't squash pretty quickly. One thing you may find is that scoped commands, such as Replace ALL MyField with Whatever, are more likely to give you this sort of conflict situation. An easy way around that (small performance hit, but worth the added stability) is to use a scan loop with a single record replace inside it. Tricks like that might need to be employed, but I'd need to see what kind of code lines this error is happening on for you.

This reindex thing... are you actually verifying that there is index corruption before doing this? If so, what is it corrupting and more importantly do those indexes that are being corrupted have any relation to the tables your application is working with when the user's get the error?