Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
TableUpdate within transaction
Message
 
 
À
09/12/2005 18:29:38
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 9
OS:
Windows XP SP2
Database:
Visual FoxPro
Divers
Thread ID:
01076280
Message ID:
01076923
Vues:
28
>Hi Again.
>
>Firstly, you seem to have missed my point about the inserts, when you say "We're only saving data in transaction, all inserts happen before the begin transaction command." you're forgetting that on a buffered table each insert happens twice. At the time you execute the Insert command it adds a record to the buffered table, and then when you are doing the TableUpdate the Inserts are efectivly happening again to the actual table on disk, and that is when the table header is locked.
>
>As for the implications for your data, under normal circumstances it will make no difference, but should something odd happen like a software or hardware crash and the DBF become damaged then without the TableValidate FoxPro is more likely not to notice and continue to use the damaged tables.
>
>The main cause of the problem that I can see is that you are performing processing during the Transaction. What are you doing? If it's altering data and so should be caught in the Transaction then the way to do it is to do it before the Begin Transaction as if the transaction worked, then let it update or rollback along with everything else. If it's not updating data, say it's generating a report, then you should move it outside of the Begin / End Transaction. There should never be anything but the buffering commands between the Begin & End transaction. If you only have TableUpdates in there FoxPro can add thousands of records in a fraction of a second.
>
>Regardless of what you do there will always be the posibility that your program will colide during an update, and the easiest way around that is probably to add code to your error handler to automatically retry File is in use errors a couple of times before assuming that they are real unrecoverable errors.
>
>Ian Simcock.

Ian,

We have only TABLEUPDATE command within transaction. We need to do tableupdate of a dozen tables for ~1000 records to insert in each of them. These tables are involved in the relationships and have triggers and table rules. So, there are things happenning during tableupdate. But even if we turn off the table rule and triggers, the tableupdate still takes 30 seconds at least for each of the table. So, the whole saving process may take up to 10 minutes...
If it's not broken, fix it until it is.


My Blog
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform