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 +

[cmako]

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 +

Merci pour l'article. Sinon quelle serait la meilleure solution, selon vous, pour faire des logs dans une table quelquesoit l'issue de la transaction?
Vous comprenez ce que je veux?

[SQLpro]

Une table étant un objet SQL; toute insertion dans la table fait partie de la transaction.
De plus vous ne nous indiqué pas ce que vous voulez tracer...
INSERT ? UPDATE ??, DELETE ???, utilisateur ? Code SQL ???

Soyez clair et précis, cela vous évitera de perdre du temps et surtout d'en faire perdre aux autres.

A +

[cmako]

Une table étant un objet SQL; toute insertion dans la table fait partie de la transaction.
De plus vous ne nous indiqué pas ce que vous voulez tracer...
INSERT ? UPDATE ??, DELETE ???, utilisateur ? Code SQL ???

Soyez clair et précis, cela vous évitera de perdre du temps et surtout d'en faire perdre aux autres.

A +

Je dois créer des connecteurs d'une base sans historisation vers une autre qui va contenir l'historisation.
Grosso modo je vais faire des procedures qui vont faire ca:

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
CREATE PROCEDURE copie_table1
AS
BEGIN TRY
	BEGIN TRAN copie_table1
		INSERT INTO LOGS VALUES ('Début transfert table1')
 
 
		-- cet insert peut etre très complèxe fesant appel à l'utilisation de curseurs voir d'autres procedures stockés
		-- les curseurs et les autres procedures stockés peuvent également faire des logs de début, de fin et intermédiaires
		INSERT INTO DB_HIST.dbo.table1 
		SELECT * FROM DB_SANS_HIST.dbo.table1
 
 
		INSERT INTO LOGS VALUES ('Transfert table1 Success')
	COMMIT TRAN copie_table1
END TRY
BEGIN CATCH
	ROLLBACK TRAN matransaction
	INSERT INTO LOGS VALUES ('Transfert table1 Failed')
 
END CATCH

Ce que je vais loger c'est juste des messages. Est ce que je suis plus clair?

[SQLpro]

J'ai du mal à comprendre que vous vouliez suivre l'évolution de chose qui n'ont pas eut lieu !

Si la transaction est annulée, alors la mise à jour n'est pas faites... Donc vous n'avez pas à journaliser une mise à jour non effectuée... Mais sans doute suis-je idiot !

A +

[cmako]

J'ai du mal à comprendre que vous vouliez suivre l'évolution de chose qui n'ont pas eut lieu !

Si la transaction est annulée, alors la mise à jour n'est pas faites... Donc vous n'avez pas à journaliser une mise à jour non effectuée... Mais sans doute suis-je idiot !

A +

Je veux savoir ce qui pose problème dans ma transaction (quelle étape et quels paramètres eventuels).
Je vais avoir une procedure de migration principale qui va faire des appels à des sous-procedures du genre copie_table1. Si un problème survient à la procedure copie_table1 (procedure rollbackée) en fonction de la sévérité et les réglès définis, on va continuer ou rollbacker toute la migration. Dans tous les cas de figure je veux logger des messages.


Autre chose, j'ai lu l'article Autonomous Transactions: a Poor Mis-Understood Feature. Franchement l'Autonomous Transaction n'est pas un problème. C'est une transaction concurrente et les exemples donnés montrent un problème "classique" de concurrence entre les transactions. Pour ma part je ne m'amuserai jamais de faire ce qui est dans l'exemple.

[SQLpro]

Dans ce cas vous pouvez écrire dans un fichier (par l'intermédiaire d'appel OLE via procédure sp_OA...), voire dans le journal d'événement xp_logevent.
Vous pouvez aussi utiliser le profiler SQL pour voir ce qui se passe.
Enfin en version 2008 un débogueur vous permet de lancer ligne à ligne.

A +

[cmako]

Dans ce cas vous pouvez écrire dans un fichier (par l'intermédiaire d'appel OLE via procédure sp_OA...), voire dans le journal d'événement xp_logevent.
A +

Et dans une table ce n'est pas possible?

[SQLpro]

ÊTES VOUS SOURD OU AVEUGLE ? RELISEZ !

[cmako]

Alors c'est nul !

J'ai lu également l'article Simulating autonomous transactions in Microsoft SQL Server. Je n'ai pas réussi à faire ce que je veux.
La seule solution de bidouillage que je vois c'est de créer une variable avant le rollback final, faire un insert into @logtab select * from LOGS where les dernières modif, faire le rollback et seulement ensuite faire insert into LOGS select * from @logtab. Car seules les variables résistent au rollback.

A+

[SQLpro]

Alors c'est nul !

Au risque de vous choquer je dirais que c'est vous qui l'êtes puisque vous refuser de comprendre ce qu'est une transaction !

Mais vous pouvez toujours inventer votre propre pseudo SGBD non relationnel qui fait ce qu'il veut dans son coin !

Il n'y a pas de pire aveugle que celui qui refuse de voir !

A +

[cmako]

Au risque de vous choquer je dirais que c'est vous qui l'êtes puisque vous refuser de comprendre ce qu'est une transaction !

Mais vous pouvez toujours inventer votre propre pseudo SGBD non relationnel qui fait ce qu'il veut dans son coin !

Moi je dirait que Oracle réponds parfaitement à mes attentes. J'aurais bien choisi Oracle, mais pour des raisons budgetaires le client a préféré SQL Server. Alors je suis obligé de faire le même travail avec le moyens du bord.

Merci pour votre aide.
A+.

P.S. Je sais parfaitement ce que c'est qu'une transaction.