Discussion :

[berceker united]

Bonjour,
J'ai besoin de savoir s'il était possible de faire un autocommit pour une table en particulier au moment ou je fais un une écriture insert ou update malgré qu'elle soit dans une transaction. En gros, s'il y a un rollback dans ma procédure, les données reste quand même présente.

En faite, dans cette table je fais qu'insérer un texte en brute donc il y pas de relation entre les données présent dans la transaction.

Merci

[elsuket]

Bonjour,

Vous pouvez utiliser l'instruction SAVE TRANSACTION et la combiner avec des tests pour la valider finalement.

@++

[berceker united]

Merci beaucoup, je vais m'orienter vers cette voie.

[elsuket]

Cela n'étant pas forcément la meilleure solution, pourriez-vous poster votre code ?

@++

[berceker united]

Cela n'étant pas forcément la meilleure solution, pourriez-vous poster votre code ?

@++

En faite, le code est beaucoup trop gros mais je peux donner un exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
BEGIN TRY
BEGIN TRAN
  INSERT INTO maTable (xxx) VALUES (xxx)
  UPDATE DBO.maTable2 SET Message= CAST(@@ROWCOUNT AS VARCHAR(50)) + ' row inserted';
  COMMIT TRAN
END TRY
BEGIN CATCH
  ROLLBACK TRAN
END CATCH

Je souhaite que l'update ne puisse être affecté par la transaction. En gros, même si ça a planté je veux conserver le message présent.
Mon but me permet de savoir jusqu'où l'opération à été et le nombre de lignes affectées. Comme ça va être une procédures lancé via un Job. Si jamais ça plante ça permet d'avoir des informations.

Merci

[elsuket]

Bonjour,

Lorsque vous spécifiez une commande INSERt, UPDATE, DELETE ou SELECT, il s'agit d'un transaction, qui de ce fait doit être atomique.
Donc si votre INSERT plante, vous aurez 0 lignes affectées, et aucune ligne ne sera ajoutée à votre table.
Cela permet de conserver votre base de données dans un état cohérent et consistant : si la transaction plante, alors la table sur laquelle celle-ci avait lieu se trouve dans l'état dans lequel elle était avant que vous tentiez d'y insérer des lignes.
Si la transaction réussit, alors toute application qui consulte les données insérées doit pouvoir les lire, sans aucune ambiguïté : c'est la propriété ACID (Atomicité, Consitance/Cohérence, Isolation, Durabilité) de tout bon SGBD.

Vous pouvez en revanche dans le traitement de votre CATCH enregistrer dans une table ce que vous retourneront les fonctions ERROR_LINE(), ERROR_NUMBER(), ERROR_PROCEDURE(), ERROR_SEVERITY(), ERROR_STATE(), et la plus intéressante dans votre cas : ERROR_MESSAGE().

@++