Information générale
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
If TABLEUPDATE() fails, an error handler won't catch the error. You have to test it with AERROR() on the next line of code immediately following the call to TABLEUPDATE(). Then either commit or rollback the transaction.
Also, Pessimistic locking does not scale well and is not considered good practice. Since a record is locked when an edit begins, a person can begin an edit then walk away from their machine and lock out the whole network. Use Optimistic locking instead. With it, the record is only locked for the amount of time it takes to commit a changes. You can also write custom conflict resolution code to flag whether someone made changes while you were editing. There are some good examples of this in the Developers Guide.
Charlie
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement