2008-12-23 11 views
2

J'utilise .NET 2.0 et SQL Server 2005. Pour des raisons historiques, le code de l'application utilise SQLTransaction mais certaines procédures stockées utilisent également des instructions TAN SQL begin/commit/rollback. L'idée est que DBTransaction peut s'étendre sur de nombreuses procédures stockées, que chaque sproc contrôle ce qui se passe dans sa portée - en fait ce sont des transactions imbriquées.Transactions SQLTransaction et T-SQL

L'ancien comportement du code était que si l'un des sprocs échouait, la logique de l'application provoquait également l'annulation de la transaction SQLTransaction externe. Mais maintenant nous voulons changer la logique pour que, même s'il y a un échec, la transaction externe continue à exécuter les sprocs restants dans sa séquence, puis à la fin, puisque nous savons qu'il y a eu des échecs, nous restaurons l'intégralité de SQLTransaction. Le problème est que, au moins tel qu'il est actuellement codé, c'est que si l'un des sprocs effectue un ROLLBACK, la SQLTransaction externe semble perdre sa connexion, de sorte que toute tentative ultérieure de réutilisation de la transaction échoue. Y at-il un moyen que je peux restaurer dans T-SQL mais toujours maintenir le SQLTransaction externe? Je pensais que peut-être des points de sauvegarde pourraient être utiles ici, mais je ne les comprends pas encore très bien.

Ce qui complique cette situation est qu'il n'y a pas toujours une transaction externe, donc je ne peux pas simplement supprimer les rollbacks T-SQL, c'est-à-dire. parfois un sproc est exécuté seul; parfois dans le contexte d'une transaction.

Le passage à TransactionScope faciliterait-il les choses?

Merci pour toutes suggestions ... Mike

Répondre

0

Jetez un oeil à cette entrée de base de connaissances:

An unexpected exception may occur when a transaction is committed or rolled back after a data source error has occurred

roulant une transaction dans un proc stocké provoquera une opération "extérieure" dans votre Client ADO.NET à disparaître La seule solution consiste à envelopper votre appel Rollback() dans un bloc try/catch. Je ne crois pas qu'il soit possible de maintenir la transaction externe si cela se produit.

0

Je suggérerais que vous envisagiez de placer votre transaction externe dans une procédure stockée afin que vous conserviez tous vos imbrications dans TSQL (utilisez EXEC pour appeler d'autres procs stockés). SQL Server est un environnement de développement/de gestion des données étonnamment riche et vous permettra de gérer vos transactions de manière qu'ADO gère maladroitement. Gardez à l'esprit, aussi, qu'il est presque toujours plus efficace de rassembler un tas de SQL ensemble dans un proc stocké que de faire plusieurs appels via une connexion ADO.

0

Il peut vous intéresser de regarder IMPLICIT_TRANSACTION Fondamentalement avec cela, vous pouvez changer le mode dépendant de la transaction de votre procédure stockée. C'est une solution plus facile dans de nombreux cas.