A (ritka kivételektől eltekintve, mint például a naplózás nélküli tömeges beillesztések, vagy a táblázat csonkítása) minden SQL utasítást tartalmaz a tranzakciós napló, mert a nyílt deklarációtól függetlenül minden SQL utasítás automatikusan tranzakcióba kerül.
Úgy tűnik, hogy a tranzakció orientált DBMS-ek tranzakciós naplót is szoktak vezetni, továbbá az eseménynapló a tranzakcióba nem foglalt eseményeket is tárolja. Vagyis a tranzakciós naplónál többféle adatot tárol az eseménynapló. (https://hu.wikipedia.org/wiki/Napl%C3%B3f%C3%A1jl_(informatika))
Ezzel együtt az is tudható, hogy a tranzakciók naplózása sokkal elterjedtebb az események naplózásánál. Ezért ha olyan DBMS-t használunk, amely csak a tranzakciókba foglalt eseményeket naplózza, akkor felmerülhet annak az igénye, hogy minden naplózandó SQL utasítást tranzakcióba foglalunk. Ezek után felmerül a kérdés: "Van-e olyan SQL utasítás, amely nem foglalható tranzakcióba?".
A szerző két lehetséges megoldást javasol, a Single-Level Modelt és a Multi-Level Modelt, és röviden össze is hasonlítja őket. Én arra lennék kíváncsi, hogy azon túl, amit ő mond, ti milyen érveket tudnátok egyik vagy másik modell mellett felhozni.
Egyáltalán, azon kívül, hogy a constraintek a wait_for_commit = ON beállítás mellett, vagy ha CHECK ON COMMIT opcióval vannak definiálva, csak a commit parancs során vannak ellenőrizve, mi értelme van egy beágyazott commit parancsnak? (A cikk szerint a változásokat csak a legkülső tranzakció commit-ja véglegesíti.)
Beágyazott rollback meg nincs is. Szóval mi értelme a tranzakciók egymásba ágyazásának Transact-SQL-ben?
