PostgreSQL
La base de données la plus sophistiquée au monde.

Ouverture de session

Navigation

Contactez-nous

Administration du site :
"equipe chez postgresqlfr point org"

Contact presse :
"fr chez postgresql point org"

Contact association :
"bureau chez postgresqlfr point org"

Questions PostgreSQL :
 IRC :
  serveur irc.freenode.net
  canal #postgresqlfr

Recherche

Accéder aux archives

« Octobre 2008  
Lun Mar Mer Jeu Ven Sam Dim
  2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  

Syndication

Flux XML

Sondage

Quelle est la version de PostgreSQL la plus répandue sur vos serveurs ?
8.3
10%
8.2
42%
8.1
40%
8.0
2%
7.4
6%
7.3 ou antérieure
0%
Nombre de votes: 48

Transactions imbriquées, odbc

Technique - odbc | Transactions imbriquées, odbc

Par opochon le 31/10/2007 - 10:09

Bonjour,

J'ai réalisé une application qui utilise à plusieurs reprises des transactions imbriquées jusqu'à 3 niveaux.
Pour des raisons pratiques, cette dernière a été testée avec ms access. Les transactions fonctionnaient correctement.

Maintenant que l'application est fonctionnelle, je l'ai migrée sous Postgresql 8.2 (avec le dernier driver odbc). Tout fonctionne, sauf... les transactions imbriquées.
J'ai donc fait quelques essais directement dans pgAdmin III et pour :

BEGIN TRANSACTION ;
CREATE TABLE TEST (a integer) ;
BEGIN TRANSACTION ;
CREATE TABLE TESTB (a integer) ;
COMMIT TRANSACTION ;
ROLLBACK ;
J'obtiens :
WARNING: there is already a transaction in progress
WARNING: there is no transaction in progress
Query returned successfully with no result in 16 ms.

et 2 tables créées...
J'ai testé avec un save point, idem.

J'ai répliqué la chose avec ADO sous Delphi, dans l'application mentionnée plus haut, le résultat est identique.
Si j'utilise adoconnection1.begintrans à plusieurs reprises, je reçois un message m'indiquant que le nombre maximal de transactions pour ma session est atteint.

Voici la chaine de connexion ;
Provider=MSDASQL.1;Password=xxx;Persist Security Info=True;User ID=postgres;Extended Properties="DSN=SYNpgssql;DATABASE=SYN;SERVER=localhost;PORT=5432;UID=postgres;SSLmode=disable;ReadOnly=0;Protocol=7.4-1;FakeOidIndex=0;ShowOidColumn=0;RowVersioning=0;ShowSystemTables=0;ConnSettings=;Fetch=100;Socket=4096;UnknownSizes=0;MaxVarcharSize=255;MaxLongVarcharSize=8190;Debug=1;CommLog=1;Optimizer=1;Ksqo=1;UseDeclareFetch=1;TextAsLongVarchar=1;UnknownsAsLongVarchar=0;BoolsAsChar=1;Parse=0;CancelAsFreeStmt=0;ExtraSysTablePrefixes=dd_;;LFConversion=1;UpdatableCursors=1;DisallowPremature=0;TrueIsMinus1=0;BI=0;ByteaAsLongVarBinary=0;UseServerSidePrepare=1;LowerCaseIdentifier=0;XaOpt=1";Initial Catalog=SYN

J'ai tenté de modifié le fichier de config (max_prepared_transactions), mais sans succès, les transactions imbriquées ne fonctionnent pas.
De plus, après avoir parcourus nombre de forums et explications diverses, j'ai également testé le driver OLE DB, mais sans grand succès.

Merci d'avance pour toute information.

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur "Sauvegarder les paramètres" pour activer vos changements.

Complément

opochon/ = 31 Octobre, 2007 - 13:02

Je tenais encore à préciser qu'afin de permettre au programme de fonctionner malgré la possibilité pour moi de faire fonctionner ce dernier simplement au moyen de begintrans-committrans, j'ai implémenté une procédure qui utilise les SAVEPOINT.
Cela implique, bien entendu, une notion de pile afin de connaître le dernier savepoint "ouvert"...


© PostgreSQLFr, tous droits rĂ©servĂ©s.
Site déclaré à la CNIL sous le numéro 1074678, conformément à la Loi en vigueur.