Eric,

Try using the NewID() function before BEGIN TRANSACTION. Certain commands and functions (e.g. INSERT, TABLEREVERT, CURSORSETPROP) cannot be performed on tables within a transaction. Also, if you take a lock on a view (never neccessary) within a transaction, it could screw-up SET REPROCESS.

Always best to keep code within a transaction simple, short, and fast as possible.

Hope this helps


>Jeff,
>
>I don't issue any specific RLOCK()s in the Transaction itself. HOWEVER, I ad a NewId function which is used as a primary key generator and is set as the default value for the table's primary key (Default=NewID()). This references a table called Identity, which contains the typical TableName,LastID fields. I issue an RLOCK() when getting the lastid from Identity and replacing the field containing the LastID with the next incremented number to prevent two inserts on the same table from getting the same key. Could the RLOCK() in this table during the Transaction be causing the corruption in the other table?
>
>>Hi Eric,
>>
>>Are you taking any locks (e.g. RLOCK()) within the TRANSACTION? If so, this can be a problem for INSERTS.
>>
>>
>>>>This situation is not common in VFP. It was quite common in earlier versions of FoxPro. VFP did a lot of fixing of how and when it writes to disk and how data it will cache. The changes in VFP have greatly reduced the frequency of this problem, but it has not been completely eliminated. I suspect that there is some set of circumstances that are causing your app to suffer this problem. Finding out exactly what will not be easy.
>>>>
>>>>In prior version of Fox this was the dreaded "Not A Database File" error because earlier version checked the record count on opening the dbf and refused to open it if the count was off. VFP doesn't check that particular issue any more and is supposed to correct the record count on opening the dbf. Are these systesm running on the same network software? Which net software Novell, NT? Because the way VFP checks the dbf is to compare the
>>>>
>>>>(file sze - header size) / Record size TO the record count
>>>>
>>>>If for some reason the server is reporting the old file size instead of the new one, that would explain why VFP isn't fixing this itself.
>>>
>>>Here's the thing: if I go and add a record to the table interactively from the command prompt, not in aa Transaction, the problem fixes itself as you describe. However it appears that the mechanism used during the Transaction for the update is different, and not so savvy. Once the problem happens, what ends up occurring is not the dreaded "Not a database file", but something more insidious. When you call TABLEUPDATE()/END TRANSACTION, VFP simply seems to say, OK, I expect the EOF to be HEADER()+1+RECCOUNT()*RECSIZE(), and writes the record starting at the point it thinks it is supposed to. However, this is really the starting point of the last record!!! So the last record gets overwritten each time an update is made. Since no write errors were encountered, TABLEUPDATE() returns .T., and since the file dize didn't change the number of records in the header is not recalculated. If you go and fix the header, this mysterious missing record appears, with the data from the last
>>>attempted update. All other updates are of course gone, because they have been long overwritten.
>>>
>>>The reason I'm so annoyed is because I know that these types of problems have always been the bane of XBase, and I can't figure why MS decided to use what appears to be two different mechansims for update: one that fixes the problem and one that makes it worse.
>>>
>>>Problem seems to exist regardless of platforms, but I will try to compile a list of platforms on which I have seen it, if that will help.
>>>
>>>I will be testing out the FLUSH stuff. Although it will be hard to tell if this fixes the problem until the next time I encounter it...
>>>
>>>Thanks to everyone for input so far.