Discussion :

[cmako]

Bonjour,

J'ai un petit problème. J'aimerais faire des enregistrement dans la table LOGS, qui sera ma table journal.

Le problème est que si à l'intérieur d'une transaction je fais des enregistrements dans la table LOGS, si je ROLLBACKe ma transation, les enregistrements de la table LOGS sont rollbackés également. Alors comment faire un ROLLBACK sans toucher à la table LOGS ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
BEGIN TRY
	BEGIN TRAN matransaction
 
	INSERT INTO LOGS VALUES ('Début Action 1')
	(action SQL 1)
 
	INSERT INTO LOGS VALUES ('Début Action 2')
	(action SQL 2)
 
	...
 
	INSERT INTO LOGS VALUES ('Début Action finale')
	(action SQL finale)
	INSERT INTO LOGS VALUES ('Success')
 
	COMMIT TRAN matransaction
END TRY
BEGIN CATCH
	ROLLBACK TRAN matransaction
	-- ici, en cas de problème tous mes enregistrements dans la table LOGS sont rollbackés
END CATCH

[SQLpro]

Vous ne pouvez pas. C'est le principe même du concept des transaction. Soit tout est effectué, soit tout est annulé (tout ou rien).

Cependant rien ne vous empêche avant ou après la transaction de dire ce que vous allez faire !

A +

[cmako]

Vous ne pouvez pas. C'est le principe même du concept des transaction. Soit tout est effectué, soit tout est annulé (tout ou rien).

Cependant rien ne vous empêche avant ou après la transaction de dire ce que vous allez faire !

A +

Alors là c'est trop fort !

Je ne peux même pas savoir ce qui cloche et a quelle étape de ma transaction le problème est survenu et ensuite le reporter dans un journal ?

Chez ORACLE par exemple on peut faire des Autonomous Transactions. Et en SQL Server?

[SQLpro]

SQL Server respecte la norme SQL et les principe d'atomicité des transactions. Oracle, fait ce qu'il veut, mais en aucun cas une transaction peut décider de faire certaines parties et pas d'autres. Cela ne constituerait plus par essence même une transaction.

A +

[elsuket]

Bonjour,

Vous pouvez utiliser les contrôleurs de flux TRY ... CATCH introduits sous SQL Server 2005.

@++

[SQLpro]

Si j'ai bien compris ces "Autonomous Transactions" sont des transactions imbriquées effectuées partiellement. Cela contrevient aux fondement même du transactionnel et les auteurs s'accordent à dire que c'est une foutaise !
C'est d'ailleurs assez casse gueule comme le montre cet article : http://www.orafaq.com/node/1915

Cependant, vous pouvez simuler ce genre de bêtise dans SQL Server. Voila un article qui vous guidera sur le sujet : http://www.c-sharpcorner.com/UploadF...SQLServer.aspx

Pour ma part si j'avais un conseil à vous donner, par exemple si je devais auditer une telle application, je serait très négatif sur l'utilisation de ce genre de gadget. Il existe certainement des voies de contournement plus logiques et plus performantes que de consister à singer Oracle...

A +