Data Integrity with VFP 8 and Older Code

I was working on a problem earlier this week with VFP 8 (SP1) and an application that has been "upgraded" over the years from DOS to Windows to VFP. With any such application, unless it's been lucky enough to receive a complete re-write, there are always lots of older pieces of code that are running around that do FLOCK( ), RLOCK()  and the like.
 
When this application was first distributed, an alarming number of "record is in use" messages occurred. And it was determined by the company's development and support staff that it was because of change in VFP 8 with the new SET VALIDATE TO, which creates better corruption awareness. As a result, we immediately switched all their customers' SET VALIDATE to a value of 0, to minimize the problem.
 
But now the problem seems to be resurfacing. Obviously, this is a case for "why aren't they using TABLEUPDATE() ,buffering and etc?" but I'm wondering - has anyone else seen this problem with older applications recompiled under VFP 8 or is it simply the case of an older application needing a wakeup call?
 
(yes, things like network issues, etc are being looked at but it's very interesting that it only occurred in a more recent version). If we find an obvious reason in the meantime, I'll be posting it but it's an interesting scenario.

Comments

Popular Posts