Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
SERIOUS FRUSTRATION - Transactions and data corruption
Message
De
08/10/1999 11:19:22
 
 
À
06/07/1999 13:05:16
Eric Barnett
Barnett Solutions Group, Inc
Sonoma, Californie, États-Unis
Information générale
Forum:
Visual FoxPro
Catégorie:
Problèmes
Divers
Thread ID:
00236192
Message ID:
00274257
Vues:
30
Did you ever reach a conclusion or a solution to the problem? I read this entire thread with growing enthusiasm as you describe a situation I've had 3 times in the last 2 weeks. You never say if you found a decent solution or put it in Microsoft's capable hands.

thanks

>I'm not positive if the error Andrzej describes in caused by the smae problem I encounter or not (although some things are similar), but I only use table buffering as well.
>
>I'm wondering about something. Say two users are both adding multiple records to a table at the same time. The records will be added ASAP from each client, but of course there will be some locking contention. When each of them are done they will each try to write the header. What if the one that writes the header is not the one who wrote the last record, and the size of the table is still smaller than expected because the server is not yet reporting the increased file size (through experimentation I've found that this can happen occasionally, even with write-cache off). Could the table be written with an incorrect header?
>
>If so, when not using Transactions this does not become a fatal error, because the new locking mechanism implemented for inserts doesn't even bother with the stored value in the header when doing an insert (hence APPEND BLANK fixing the problem). After the insert the header is re-written correctly. But inside a Transaction the same behavior does not happen (of this I am sure); instead it starts the write from the calculated offset using the value of the number of records from the header - hence overwritten data.
>
>It seems to me that based on the insert mechanism when Transactions are not being used that the VFP anticipated this problem with the header. Why would they implement different behavior for Transactions?
>
>I am working on some sample code that shows the differences in behavior on a table with an incorrect header both inside and outside a Transaction. I will post it when I finish - you can tell me if you think it needs to be reported.
>
>>Andrzej,
>>
>>You said you are using Optimistic row buffering, I would assume that you are using table buffering on the child table?
>>
>>I only use Optimistic Table buffering so the problem may lie in the row buffering. If it does then it makes sense that I don't see it since I don't use row buffering.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform