[SQL Server] Transaction, rollback

Transaction, rollback [SQL Server] - Programmation

Marsh Posté le 24-04-2001 à 15:38:32    

Probleme:
 
Delete from table where...
traitement divers  
insert into table ...
 
L'objectif et de reactualizer la table, et donc je supprime tout pour ne pas avoir a faire la difference entre update et insert...
 
Le problemem c'est qu'en cas de plantage lors de mon trai^tement, je pers tout... radical, j'ai teste :-)
 
On ma parler de rollback ou de transaction, mais j'ai vaguement (en cours,  donc..) vu ca pour oracle, et j'aurais voulu avoir des precision pour sql server pour recuperer les donnees...

Reply

Marsh Posté le 24-04-2001 à 15:38:32   

Reply

Marsh Posté le 24-04-2001 à 15:48:41    

Code :
  1. BEGIN TRANSACTION toto
  2. DELETE...
  3. INSERT...
  4. IF @@ERROR = 0
  5.    COMMIT TRANSACTION toto
  6. ELSE
  7.    ROLLBACK TRANSACTION toto

Reply

Marsh Posté le 24-04-2001 à 16:43:34    

y'a pas moyen de faire:

Code :
  1. VB
  2. {debut de transaction}
  3. delete
  4. VB
  5. insert
  6. VB
  7. ....
  8. On error ....  rollback


Ca c'est po possible??

Reply

Marsh Posté le 24-04-2001 à 17:12:31    

Si mais dans ce cas la il faut que tu utilises la transaction au niveau de l'objet ADO Connection.

Reply

Marsh Posté le 24-04-2001 à 17:21:32    

je passe toutes mes requete par l'intermediaire d'une adodb.command, alors j'aurais voulu savoir si c'etait compatible...si oui, precise parce que la je ne vois po
 
J'avai pense tout mettre dans une string, et executer la string en une fois, mais je fais des select apres le delete, et cest eux qui definissent les insertion suivante..
Suis pas sur d'avoir ete clair, mais j'espere.

Reply

Marsh Posté le 24-04-2001 à 17:47:12    

Au début de ton traitement tu ouvres une connexion a la base en utilisant un objet ADODB.Connection. Ensuite tu inities la transaction objConnection.BeginTrans (si ma mémoire est bonne) tu fais tes traitements via des objets Command ou Recordset mais utilisant tous la connexion ouverte dans l'objet précédent. En fin de traitement tu peux alors selon le cas faire objConnection.CommitTrans ou objConnection.RollbackTrans

Reply

Marsh Posté le 25-04-2001 à 08:35:56    

et tant qu'on est dans le vif du sujet, est-ce qu'il y a un nombre limite de requete avant le commit, parce qu avant j'aurais aimer passer dans une boucle plus ou moin longue...
De plus, comment ca se passe, il execute les requetes reelement, et les annule si rollback, ou il les execute quand on fais commit??

 

[edit]--Message édité par trictrac--[/edit]

Reply

Marsh Posté le 25-04-2001 à 09:59:57    

Voila ce que dit l'aide de SQL Server
 

Citation :


Transactions
A transaction is a sequence of operations performed as a single logical unit of work. A logical unit of work must exhibit four properties, called the ACID (Atomicity, Consistency, Isolation, and Durability) properties, to qualify as a transaction:  
 
Atomicity  
A transaction must be an atomic unit of work; either all of its data modifications are performed, or none of them is performed.  
Consistency  
When completed, a transaction must leave all data in a consistent state. In a relational database, all rules must be applied to the transaction’s modifications to maintain all data integrity. All internal data structures, such as B-tree indexes or doubly linked lists, must be correct at the end of the transaction.  
Isolation  
Modifications made by concurrent transactions must be isolated from the modifications made by any other concurrent transactions. A transaction either sees data in the state it was in before another concurrent transaction modified it, or it sees the data after the second transaction has completed, but it does not see an intermediate state. This is referred to as serializability because it results in the ability to reload the starting data and replay a series of transactions to end up with the data in the same state it was in after the original transactions were performed.  
Durability  
After a transaction has completed, its effects are permanently in place in the system. The modifications persist even in the event of a system failure.  
Specifying and Enforcing Transactions
SQL programmers are responsible for starting and ending transactions at points that enforce the logical consistency of the data. The programmer must define the sequence of data modifications that leave the data in a consistent state relative to the organization’s business rules. The programmer then includes these modification statements in a single transaction so that Microsoft® SQL Server™ can enforce the physical integrity of the transaction.
 
It is the responsibility of an enterprise database system, such as SQL Server, to provide mechanisms ensuring the physical integrity of each transaction. SQL Server provides:  
 
Locking facilities that preserve transaction isolation.  
Logging facilities that ensure transaction durability. Even if the server hardware, operating system, or SQL Server itself fails, SQL Server uses the transaction logs, upon restart, to automatically roll back any uncompleted transactions to the point of the system failure.  
Transaction management features that enforce transaction atomicity and consistency. After a transaction has started, it must be successfully completed, or SQL Server undoes all of the data modifications made since the transaction started.  

Reply

Marsh Posté le 25-04-2001 à 10:06:28    

Je te remercie GURU, les informations donnees sont exhaustives, une fois de plus.
Le probleme est reglé (pour l'instant)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed