andron81Как известно транзакция задает последовательность инструкций языка Transact-SQL, применяемую для объединения в один пакет операций чтения и записи для того, чтобы система базы данных могла обеспечить согласованность данных. (откопипастил первое попавшееся определение)
сразу вопрос что подрумянивается под инструкциями ?Под инструкцией подразумевается любая команда доступа к данным.

Транзакцию можно задатьь на блок инструкций, например, явно начав её командой begin tran, либо на каждую отдельную инструкцию, тогда она начнётся сама - инструкция без транзакции выполнена быть не может.

andron81к примеру есть несколько инсертов.

insert
insert
insert


Вопрос: тут что будет являться транзакцией каждый такой insert или же весь блок с инсертами или что иное Если этот блок выполнялся в общей транзакции, то весь блок, и даже инструкции потом (время и объём транзакции не ограничены), а если общий транзакции нет, и если не задан режим автоначала транзакции, то каждая инструкция будет выполняться в своей транзакции.

L_argoтакой блок будет одной транзакцией:

begin tran
insert
insert
insert
commit tranИли такой:
insert
insert
insert

Yasha123alexeyvgпропущено...
Или такой:
insert
insert
insert
это 3 транзакции, а не 1С чего это, если установлена опция автоначала транзакции?

andron81да нет. я всё это почитаю , конечно . спасибо.
как правильно сделать я догадываюсь
Я хочу прояснить это для себя.Предыдущие ответы как раз описывают, что произойдёт, т.к. это зависит от настроек сервера и коннекта.
andron81просто я не пойму : вот есть определение транзакции, атомарности.
четко и ясно написано : набор команд который рассматривается как единое целое кот. может выполнится , а может нет - в последнем случае откат.
но почему я должен в этом случае юзать всякие велосипеды типа @@ERROR или вот catch ??Потому что разные варианты обработки не нарушают эту целостность и атомарность.

Понимаете, "транзакция" - это не декларативное понятие, типа как трай-кэтч в разных ЯП, типа "указание рассматривать этот блок как единое целое", это некая команда серверу, потому что для идеологии существующих СУБД декларативно сделать транзакцию принципиально невозможно.

Если же вы рассмотрите транзакцию как команду перевода сервера (коннекта) в некий статус, то всё встанет на свои места.

andron81определение транзакции это набор инструкций которые совершают модификацию с б.д. (insert, update, delete). какие там проверки на @@ERROR ? :)Нет, это не так, и важно, что сделать так принципиально неосуществимо.

Потому что нет "набора инструкций" для сервера, если команды, которые по очереди передаются по сети в сервер.
А вы при этом управляете статусом.

Например, в вашем примере


Скажем, BOOK_SALES2 завершилось неудачно, с ошибкой.

Помня о том, что транзакция - это некое состояние, можем ли мы продолжить обновлять BOOK_SALES3 и 4 в той же транзакции? Да, можем, почему бы и нет, если нам это нужно.

Но если не хотим такого поведения, то режим SET XACT_ABORT ON может откатить транзакцию и завершить весь батч.

В общем, всё достаточно гибко и управляемо.

Yasha123alexeyvgпропущено...
С чего это, если установлена опция автоначала транзакции?
авто_кто установлен?
---
наверное с того, что если кто-то использует что-то, отличное от общепринятых умолчаний,
то об этом надо сообщать?Наверное, не надо обобщённо утверждать, что если нет стейтмента BEGIN TRANSACTION, то три инсёрта будут тремя разными транзакциями

Yasha123alexeyvgНаверное, не надо обобщённо утверждать, что если нет стейтмента BEGIN TRANSACTION, то три инсёрта будут тремя разными транзакциями
а я где-то такое утверждаю?Да, вот тут:
Yasha123я утверждаю, что написанный вами код, это 3 транзакции.
Ибо если включён SET IMPLICIT_TRANSACTIONS ON, то после первого инсёрта начнётся общая транзакция, в которой будет выполняться в том числе и третий инсёрт.
И вот тут не прокатывает "а если это лишь кусок кода, то уж простите, ваши проблемы", потому что это не кусок кода, а весь код, а статус IMPLICIT_TRANSACTIONS ON - это не код, а установка коннекта; возможно, все коннекты в системе имеют такую установку.

И более того, корректно будет считать это "полным кодом" при запуске такого батча из клиента, при том, что из клиента до этого выполнялись другие батчи,и, в частности, была начата транзакция.

andron81Но в этом случае дойдя до конца, мы всё равно должны сделать откат. иначе нарушается условие атомарности.Я же вам говорю, условие атомарности не нарушится, потому что транзакция не декларативна.

Она не охватывает те операции, которые написаны программистом между begin и commit.

Те операции, которые были включены в транзакцию, можно подтвердить или откатить. А те, которые не были включены в транзакцию, не поменяли данные, и в транзакцию не включились, на неё не повлияли.

andron81Как известно транзакция задает последовательность инструкций языка Transact-SQL, применяемую для объединения в один пакет операций чтения и записи для того, чтобы система базы данных могла обеспечить согласованность данных. (откопипастил первое попавшееся определение)Из этого можно понять, что транзакция есть нечто декларативное, как указание, что эти стейтменты должны выполнится как единое целое.

Но это неправильное определение.

Вы лучше представьте, что это некое последовательность бакапов диска.
Вы сделали бакап, потом на диск пишете, читаете, какие то записи завершаются с ошибкой... Потом опять пишите...
А потом принимаете решение - сделать очередной бакап, или восстановить последний. Вот это есть подтвердить или откатить транзакцию.

Yasha123и буду на этом настаивать.
ваш код НЕ содержит SET IMPLICIT_TRANSACTIONS ON.Да он вообще никаких SET не содержит, а они есть, потому что есть коннект, и при нём всегда есть SET-ы

andron81ну если я не прав, так не прав. почитайте как называется моя тема - я разбираюсь.Вроде тема называется я разбираюсь, но вы яростно спорите с объяснениями, причём не находите какие то нестыковки в объясн5е6ниях, или не переспрашиваете непонятное, а отстаиваете своё понимание транзакций :-)

andron81тем не менее это не логично ! интересно что ж в этом случае пишется в журнал транзакций ?Да ничего не пишется.
Ещё раз - транзакция - это определённое состояние сервера/коннекта.
Вот, при SELECT сервер перешёл в это состояние, это где то отметилось в памяти, создался идентификатор транзакции, к нему привязались записи о блокировках (возможно - очень много записей, это тоже зависит от разного) и т.д.
andron81ну вот и где тут логика ? поэтому любой селект этонедотранзакция, если его нельзя откатить и нечего писать в журнал .Ну, можно назвать "недотранзакцией".
Но т.к. в документации сиквела разработчики не используют этот термин, а используют слово "транзакция", то мы это так и называем.

andron81Не противоречит ли оно тому, что пишет парень про бэкапы и что включается в транзакцию.

Вот он пишет :
Те операции, которые были включены в транзакцию, можно подтвердить или откатить. А те, которые не были включены в транзакцию, не поменяли данные, и в транзакцию не включились, на неё не повлияли. Не хотите ему ссылку эту дать?Ну, я рассказывал про механизм транзакций в MSSQL.
Не буду спорить с теоретиками, по монографиям которых о теоретических транзакциях в ваакуме написали статью в энциклопедии, у менгя не хватит квалификации, да и желания нет.
Механизмы в других СУБД работают подобно механизмам MSSQL, так что для практического применения прислушайтесь к моим советам.
Но если вы должны сдать курсовик, или написать научную статью, то лучше изучать научные работы, а не механизмы MSSQL.
В общем, смотря какая цель.

Гавриленко Сергей Алексеевичandron81ну вот и где тут логика ? поэтому любой селект этонедотранзакция, если его нельзя откатить и нечего писать в журнал .Вы не поверите, но delete, который ничего не удалил, в журнал тоже ничего не запишет. Как вам такая логика?Тогда "транзакция" волшебным образом превращается в "недотранзакцию" :-)