IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement SQL Server Discussion :

Problème de transaction


Sujet :

Développement SQL Server

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Inscrit en
    Octobre 2009
    Messages
    59
    Détails du profil
    Informations forums :
    Inscription : Octobre 2009
    Messages : 59
    Par défaut Problème de transaction
    Bonjour tout le monde
    Lorsque, sous sql server 2008 (pas R2) je fais:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
                    BEGIN TRY
    					BEGIN TRANSACTION q_ar_new_MajESale_fr_Articles
    						EXEC [dbo].[q_MajESale_fr_Articles] @ForetagKod, @SprakKod;
    					COMMIT TRANSACTION q_ar_new_MajESale_fr_Articles
                    END TRY
                    BEGIN CATCH
                                   ROLLBACK TRANSACTION q_ar_new_MajESale_fr_Articles
                                   --Blah blah des tests pour trouver l'erreur
                    END CATCH
    J'ai le droit à un superbe :
    Msg*3903, Niveau*16, État*1, Ligne*216
    La requête ROLLBACK TRANSACTION n'a pas de BEGIN TRANSACTION correspondante.
    Je sais que les erreurs peuvent invalider une transaction en fonction du niveau de gravité, mais est ce qu'elles peuvent carrément la faire disparaître ?
    J'ai fait quelques tests avec des SELECT @@TRANCOUNT; et a priori c'est le cas, j'ai placé un select avant le exec, un après et un au début du catch, résultat : 1 avant le exec, 0 dans le catch (???!) et pas de message après le exec (normal)

    Du coup je veux bien vérifier qu'il il y a une transaction en cours (IF @@TRANCOUNT > 0) mais qu'en est-il des données traitées dans la procédure seront-elles enregistrées ou non ?

  2. #2
    Membre expérimenté
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Par défaut
    J'suis justement en formation et on voit les transactions ^^.

    Tu mets ton bloc transaction dans ton bloc try. C'est l'inverse, mets ton bloc try dans ton bloc transaction.

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 002
    Billets dans le blog
    6
    Par défaut
    Non, sa solution est bonne.
    mais
    1) la proc [dbo].[q_MajESale_fr_Articles] peut elle même faire une transactions. Vois comment sont gérées les transactions imbriquées dans l'article que j'ai écrit : http://sqlpro.developpez.com/cours/s...ns-imbriquees/
    2) dans le CATCH, utilisez la fonction XACT_STATE pour tester l'état de validité transactionnel.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  4. #4
    Membre expérimenté
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Par défaut
    Au temps pour moi alors.

    Pourtant, j'aurais cru que vu que sa transaction est déclaré au sein du bloc try, elle ne serait visible qu'à l'intérieur de ce bloc.

    La visibilité des objets ne fonctionne pas de cette façon en sql server ? J'avoue avoir extrapolé cela à partir de mes connaissances en programmation.

  5. #5
    Membre éprouvé

    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 448
    Par défaut
    "SET XACT_ABORT ON" peut aider.

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 002
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par griftou Voir le message
    Pourtant, j'aurais cru que vu que sa transaction est déclaré au sein du bloc try, elle ne serait visible qu'à l'intérieur de ce bloc.

    La visibilité des objets ne fonctionne pas de cette façon en sql server ? J'avoue avoir extrapolé cela à partir de mes connaissances en programmation.
    Le fonctionnement d'un SGBDR n'a rien en commun avec le codage d'un langage L4G... Les transactions sont des objets de niveau cession et sont donc persistant entre procédures requêtes ad-hoc et tutti quanti !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  7. #7
    Membre expérimenté
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Par défaut
    Merci pour ces éclaircissements.

Discussions similaires

  1. [delphi][interbase]problème de transaction
    Par daheda dans le forum Bases de données
    Réponses: 4
    Dernier message: 26/10/2006, 09h12
  2. Problème de Transactions
    Par blaspalles dans le forum Access
    Réponses: 4
    Dernier message: 18/09/2006, 17h05
  3. problème de transaction et load data
    Par jccanut dans le forum Installation
    Réponses: 6
    Dernier message: 14/09/2006, 11h38
  4. [SQL 2k] Problème de transaction choisie comme victime
    Par Actarion dans le forum MS SQL Server
    Réponses: 7
    Dernier message: 04/07/2006, 17h17
  5. Encore un petit problème de transaction
    Par devdev dans le forum MS SQL Server
    Réponses: 3
    Dernier message: 24/03/2005, 16h13

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo