Re: Migration SQL Serveur 2008 vers PostgreSQL

Voici un exemple de transactions infaisable sous PG :

CREATE TABLE T1 (C1 INT);
CREATE TABLE T2 (C2 INT CHECK (C2 > 0))
CREATE TABLE T3 (C3 INT);
GO

CREATE PROCEDURE P_INSERT_TRANSACTION
@VAL1 INT
AS
BEGIN
-- demarrage d'une transaction
BEGIN TRANSACTION;
-- test de validité
BEGIN TRY
INSERT INTO T1 VALUES (@VAL1);
INSERT INTO T2 VALUES (@VAL1);
COMMIT TRANSACTION;
END TRY
-- en cas d'erreur
BEGIN CATCH
IF XACT_STATE() <> 0
ROLLBACK TRANSACTION;
INSERT INTO T3 VALUES (@VAL1);
END CATCH
END;
GO

-- permier test réussi :
EXECUTE P_INSERT_TRANSACTION 1;
GO

-- resultats :
SELECT * FROM T1;
SELECT * FROM T2;
SELECT * FROM T3;

C1
-----------
1

C2
-----------
1

C3
-----------

-- second test échec :
EXECUTE P_INSERT_TRANSACTION -1
GO

-- resultats :
SELECT * FROM T1;
SELECT * FROM T2;
SELECT * FROM T3;

C1
-----------

C2
-----------

C3
-----------
-1

La procédure insère dans les tables T1 et T2 dans la cadre d'une
transaction et, en cas de viol de la contrainte CHECK, annule la
transaction et insère dans la table T3...

En sus PG ne permet pas de piloter le niveau d’isolation des
transactions de manière dynamique..

Exemple :

CREATE PROCEDURE P_INSERT_TRANSACTION
@VAL1 INT
AS
BEGIN
-- demarrage d'une transaction
BEGIN TRANSACTION;
-- test de validité
BEGIN TRY
--> modification du niveau d'isolation
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
INSERT INTO T1 VALUES (@VAL1);
INSERT INTO T2 SELECT * FROM T1;
COMMIT TRANSACTION;
--> modification du niveau d'isolation
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
END TRY
-- en cas d'erreur
BEGIN CATCH
IF XACT_STATE() <> 0
ROLLBACK TRANSACTION;
INSERT INTO T3 VALUES (@VAL1);
END CATCH
END;
GO

Les transaction imbriquées, sont une autre difficultés (les sous
transactions cela n'existe pas, car par nature une transaction est
atomique !!!)

A lire :

http://sqlpro.developpez.com/cours/sqlserver/transactions-imbriquees/

Le 04/01/2012 16:36, Dimitri Fontaine a écrit :
> "Jehan-Guillaume (ioguix) de Rorthais"<ioguix(at)free(dot)fr> writes:
>> Bref, une subtilité m'échappe là dedans.
>
> Ton exemple fonctionne parce que tu as pu faire un ROLLBACK à
> l'intérieur de ton traitement tout en faisant un COMMIT global.
>
> Essaye maintenant de faire un ROLLBACK global en ayant pu faire un
> COMMIT du traitement interne… avec une procédure tu peux.
>
> Évidemment du coup une fonction est invoquée de la même manière qu'un
> Utility Statement, avec la syntaxe dédiée CALL. Ce que tu peux très
> bien faire dans un trigger, échouer à faire l'opération qui a déclencher
> le trigger et avoir commité le traitement réalisé dans le CALL.
>
> Il existe peut être d'autres syntaxes et d'autres modes de
> fonctionnements, à vérifier.
>
> Sous PostgreSQL nous n'avons pas de procédures au sens standard SQL,
> nous n'avons que les fonctions, qui sont utilisées au sein de requêtes,
> et auxquelles échappent complètement la notion de transaction.
>
> La raison pour laquelle nous n'avons pas encore de procédures standard
> est à mon avis double : c'est assez compliqué à faire « correctement »
> pour que personne n'y ait encore vu un intérêt (financier, par exemple)

J'aime beaucoup ce genre de commentaires...
Pensez-vous sincèrement que ce que fait oracle, MS SQL Server, IBM DB2
ou Sybase ASE nativement et que ne peut pas faire PG soit un gadget
imbécile et inutile ?

je croyais les gens de 2ndQuadrant un peu plus ouvert... Mais sans doute
me trompais-je !

> assez fort pour se mettre au boulot.
>
> Nous attendons tous avec impatience que ce moment se présente :)

A +

--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************