probleme transaction distribuée de sql server vers oracle

[funboard]

Bonjour à tous,

je souhaite traiter des insertion dans une table dans une base distante oracle de manière transactionnel.

Les insertions se feront a partir de sql server 2000 vers oracle.
Je passe par une serveur lié qui utilise le provider ole db d'oracle.

Le serveur lié marche bien pour toutes les opérations simple (insert, select etc ...)

Lorsque j'execute une procédure stocké qui contient :

Code :

1
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
 
 
CREATE PROCEDURE MA_PROCSTOCK
AS
BEGIN
DECLARE @ERREUR	INT
 
SET XACT_ABORT ON
 
BEGIN DISTRIBUTED TRANSACTION
 
INSERT INTO LINKED_SERVER..SCHEMA.TABLE_DISTANTE (...)
SELECT  ... FROM table_local
 
SET @ERREUR=@@ERROR
 
IF (@ERREUR=0)
BEGIN
	COMMIT TRANSACTION
	END
ELSE
BEGIN
	ROLLBACK TRANSACTION
END
 
SET XACT_ABORT OFF
 
 
END
GO

j'ai le message d'erreur suivant :

Serveur : Msg 7391, Niveau 16, État 1, Procédure MA_PROCSTOCK, Ligne 10
L'opération demandée ne peut pas être effectuée car le fournisseur OLE DB 'OraOLEDB.Oracle' n'a pas réussi à démarrer de transaction distribuée.
[OLE/DB provider returned message: La nouvelle transaction ne peut pas s'inscrire dans le coordinateur de transactions spécifié. ]
Trace de l'erreur OLE DB [OLE/DB Provider 'OraOLEDB.Oracle' ITransactionJoin::JoinTransaction returned 0x8004d00a].



si quelqun peut m'aider dans ma résolution du problème je l'en remercie d'avance.

ps : d'autres transactions distribuées sur un autre serveur liée fonctionnent parfaitement. (ce n'est donc pas a mon avis un problème de parefeu mais plus peut etre la config du serveur lié (les options a cocher))

Merci.

[orafrance]

j'imagine qu'est c'est dû à la gestion des transactions qui est différente sous Oracle. Tu es obligé de démarrer toi-même la transaction ?

[funboard]

Salut,
c'est peut etre ça le problème.

oui je suis obligé de démarrer moi même la transaction.
que puis-je faire ?

Dans le fichier readme.txt du provider oracle for ole db il y a :

Transaction
-----------
* During a Local or Global Transaction, do not execute SQLs COMMIT, ROLLBACK or
SAVEPOINT using the Command interface as they may affect the data consistency
in the Rowsets. The same holds for executing DDLs (CREATE TABLE, ALTER VIEW,
etc.) in this explicit transaction mode, as DDLs in Oracle perform an implicit
Commit to the database. Execute DDLs only in the Auto-Commit mode.

* To enable Autonomous Transaction support, the connection string attribute,
DistribTx, should be disabled. Using this feature, consumers can execute
Stored Procedures having COMMITs and/or ROLLBACKs.

Note that Commit/Rollback in a stored procedure should be performed with
caution. As OraOLEDB provides transactional capability on rowsets, whose data
is cached locally on the client-side, performing an explicit commit/rollback
in a stored procedure, with an open rowset, could cause the rowset to be out
of sync with the database. In these cases, all commits and rollbacks (aborts)
should be performed from the client-side (con.Commit or con.Abort). The
exception is if the user is making use of Autonomous Transactions in the stored
procedure. By using this, the transaction in the stored procedure is isolated
from the main one; thus allowing for localized commits/aborts. Autonomous
Transactions have been introduced only in Oracle8i (8.1.5) and are not
available in the earlier releases of the RDBMS.

For more information on Autonomous Transactions, refer to Oracle9i "Application
Developer's Guide - Fundamentals" and "PL/SQL User's Guide and Reference".


Si vous voyez dans ce texte un declic, dites le moi, moi je n'en vois pas.

Mille merci.

[funboard]

Re,
Juste une tite question :

étant donnée que sql server est par defaut en mode aucommit et que ma procstock contient qu'une seule instruction( insert into ... select ...), ça revient au même de ne pas faire de transactions du tout non ???

car si c'est le cas je n'ai meme pas besoin de faire de transaction

qu'en pensez vous ?

Merci.

[orafrance]

probablement mais il faut tester... éventuellement, tentes ta chance dans le forum SQL Server