none
SQL Server 2008 - problema con transazioni innestate RRS feed

  • Domanda

  • Ciao a tutti,

    un programma (VB6 via ADO) esegue i seguenti comandi in ordine:

    - BeginTransaction

    - UPDATE TB1

    - UPDATE TB2

    - Se tutto bene COMMIT, altrimenti ROLLBACK

     

    La situazione strana è che il commit viene eseguito ma a volte i dati non sono memorizzati nel db.

    Analizzando le istruzioni SQL con il Profiler ho potuto notare che in caso di anomalia le istruzioni registrate sono queste:

    - BEGIN TRANSACTION -> CORRISPONDE ALL'ISTRUZIONE DI VB

    - UPDATE TB1 -> CORRISPONDE ALL'ISTRUZIONE DI VB

    - UPDATE TB2 -> CORRISPONDE ALL'ISTRUZIONE DI VB

    - BEGIN TRANSACTION -> NON CORRISPONDE

    - UPDATE TB2 -> VIENE RIPETUTO L'ULTIMO UPDATE

    - COMMIT TRANSACTION -> CORRISPONDE ALL'ISTRUZIONE DI VB

    A questo punto però il programma chiude la connessione senza errori, ma in verità nel db i dati non sono aggiornati in quanto la transazione principale non ha nessun COMMIT che confermi i dati nel db.

    Il problema compare solo a volte, ho controllato il cursore (adUseServer), il livello di isolamento (READ COMMITTED), ho disattivato anche il database Mirroring, la versione di SQL Server è la 2008 SP2 (10.0.4000) Standard Ed. x64, tra i parametri di connessione il parametro SET IMPLICIT_TRANSACTION è a OFF.

     

    Ho consigliato al programmatore di eseguire un ciclo nel programma in base al valore di @@TRANCOUNT ed eseguire tutte le COMMIT o ROLLBACK necessarie fino alla chiusura di tutte le transazioni.

    Avete mai notato di questo tipo?

     

    Grazie,

    Manuel

    mercoledì 15 giugno 2011 14:02

Tutte le risposte

  • Ciao Manuel,

    >> BEGIN TRANSACTION -> NON CORRISPONDE

    >> UPDATE TB2 -> VIENE RIPETUTO L'ULTIMO UPDATE

    il codice T-SQL (colonna Text in SQL Profiler) relativo all'update che trovi ripetuto è esattamente uguale al primo update ? Il tipo di evento è uguale ? Hai verificato la presenza di eventuali trigger ?

    Ciao!


    Sergio Govoni
    SQL Server MVP
    MVP Profile: https://mvp.support.microsoft.com/profile/Sergio.Govoni
    Blog: http://community.ugiss.org/blogs/sgovoni
    lunedì 20 giugno 2011 22:03
    Moderatore
  • Ciao,

    la colonna TextData del Profiler ha esattamente lo stesso T-SQL, idem per la colonna EventClass, cambia solo l'orario di esecuzione. Non ci sono trigger nella tabella.

    Il sospetto che sto maturando è che sia il programma a rifare l'update riaprendo erroneamente la transazione per un timeout dell'update precedente, ma il programmatore mi esclude questa possibilità. Sinceramente non vedo altre possibilità...

    Ho consigliato di eseguire un COMMIT fino a che il valore @@TRANCOUNT è a 0 in modo da essere sicuro di chiudere tutte le transazioni per la sessione dell'utente, magari registrando in un log il fatto che le transazioni aperte erano > 1.

    Questa tuttavia non è la soluzione, ma solo una pezza.

    Per il momento grazie.

    Manuel

    martedì 21 giugno 2011 15:57
  • Ciao Manuel,

      >> la colonna TextData del Profiler ha esattamente lo stesso T-SQL, idem per la colonna EventClass, cambia solo l'orario di esecuzione.

      >> Non ci sono trigger nella tabella.

    Se cambia solo l'istante di esecuzione e non ci sono trigger sulla tabella, anch'io sospetto che sia il programma a rifare l'update; sarebbe interessante scoprire il perchè :-) ah questi DEV...

    Ciao!


    Sergio Govoni
    SQL Server MVP
    MVP Profile: https://mvp.support.microsoft.com/profile/Sergio.Govoni
    Blog: http://community.ugiss.org/blogs/sgovoni
    martedì 28 giugno 2011 22:00
    Moderatore