White OwlTransact SQL в вариации для MS SQL 2008. А, ну да, забыл @ у переменной поставить, прошу прощения.
Так лучше?

Одна команда упадет, другая выполнится.

Да, только пальцем в небо. Ибо обе эти строки выполнятся абсолютно одинаково и безошибочно.
a=b+с
a=(b+c)
Вот примерно это ты и написал. Как Си-шник ты должен прекрасно понимать, что такое операторные скобки (это в VB их нет)

White OwlДа, если begin tran просто так послать то первый раз она будет проигнорирована, на второй и дальше начнется вложеность. Насколько ты уверен что где-то выше по коду или вообще в другом окне ты уже не послал однажды begin tran?
White OwlShocker.Probegin tran - это любые транзакции, а не только вложенные.Это только вложенные.

Вложенность - это когда нечто одно вложено в нечто другое. Если begin tran встречается только один раз, то ничего ни во что вложено не будет.
Про то, что она будет проигнорирована - ты уже какую-то глупость несешь. После begin tran с первой операции с таблицами пойдут блокировки на эти таблицы (в зависимости от уровня изоляции). При rollback будет откат всех операций, начиная с begin. Сделать rollback для неявной транзакции (в MSSQL) невозможно (кроме триггера).

Почитай про @@TRANCOUNT, поэкспериментируй.

White OwlМногопользовательская работа не требует явного начала транзакции.
Откат всегда будет делаться на начало автоматической транзакции а не на begin tran.

Бред. Откатить транзакцию нельзя без ее явного начала. Автоматическая (неявная) транзакция коммитится/откатывается там же, где и началась и повлиять на нее вручную можно только в триггере.
А если ты хочешь, чтобы несколько пользователей попытавшись сохраниить несколько связанных таблиц одновременно, разрушили логическую структуру - то пожалуйста, можешь не использовать.

White OwlА без точки сохранения ты всегда будешь откатывать до самого внешнего begin tran в случае вложенных транзакций либо до begin tran который совпадает с началом автоматической транзакции.

Разумеется, для того он и нужен. И у автора выполнится откат транзакции из трех операций на начало пакета.

White OwlShocker.ProАвтор грамотно поступает, выполняя последовательность взаимосвязанных команд внутри транзакции, обеспечивая тем самым целостность данных даже в случае сбоев.
Нет. Он поступает глупо.
а) Никто не гарантирует что в другом окне пользователь не пошлет другую begin tran (и кстати TC об этой проблеме догадывается, смотри самый первый пост).

Опять бред. Когда в другом окне пользователь пошлет другой begin tran, он сможет это сделать только в другом соединении. Он НИКАК не сможет допустить вложения в тот пакет, который в этот момент выполняется, ибо пакет цел и неделим от begin до commit и отправляется целиком на сервер (в варианте ТС-а).

Если же ты рассматриваешь ADO -шный метод .BeginTrans - то я тоже против его использования по примерно тем причинам, про которые говоришь ты, об этом я писал выше ТС-у.

Shocker.Proб) Целостность гарантируется тем что в случае сбоя сервер откатит все что не было подтверждено.

Верно. У ТС-са такой порядок:
begin tran
insert
delete
update
commit tran
Если на update произойдет сбой, то откатится и insert и delete. Если же убрать транзакцию, то insert и delete закоммиттятся, а update откатится/


Shocker.ProДа. Это самый надежный и простой метод работы. А что, кто-то еще пользуется DBGrid'ами?

Лично я - нет. Про ТС - не знаю.
Надежный и простой для простых случаев типа приведенного ТС-сом примера с телефонами. Но он и сам говорит, что на самом деле у него более сложная задача, и я про свои задачи имел ввиду более сложные вещи. Но я дополню себя - это удобно, когда бизнес-логика реализована на стороне сервера. Тогда в процессе редактирования возможен пересчет текущих связанных значений из базы, выдача результатов запросов с джойнами, упрощение сохранения и загрузки данных и т.п.

White OwlShocker.ProЕсли же ты против временной таблицы для редактирования многострочного контента, то я поддерживаю автора, ибо сам к этому пришел после 14-ти лет проектирования клиент-серверных приложений. Я испльзую, правда, не временную таблицу, а единую таблицу для временных данных редактирования для всех пользователей. но сути дела это не меняет.ээээ.... в 14 лет уже надо бы понимать как работают транзакции... Впрочем, юноша, у вас еще все впереди :)

без перехода на личности обойдемся

По поводу двух соединений: возможно драйвер SyBase-а и позволяет открыть параллельную транзакцию (не вложенную) и ADO этим пользуется. Но в SQL для открытия параллельной транзакции он вынужден открывать и параллельное соединение.

White OwlВо вторых, я попытался намекнуть что коннекты к серверу устанавливает не ADO, а интерфейсный драйвер и если он считает что надо открывать второй коннект, к ADO это никоим образом не относится.

Гм. На таком уровне спорить не готов.
Тогда я пас, а свое утверждение переформулирую в:
При использовании ADO возможно возникновение дополнительных соединений с сервером без явного желания программиста

Именно это расстраивает ТС

White OwlShocker.ProДа, только пальцем в небо. Ибо обе эти строки выполнятся абсолютно одинаково и безошибочно.Ок. Признаю, этот test-case излишне упрощенный. Завтра я тебе сделаю программку выдающую 111-ую ошибку если не использовать операторные скобки.

А зачем ты передергиваешь? Речь шла о том, что твой совет ТС-у поставить операторные скобки вокруг двух его инсертов не имеет смысла.
Впрочем, очень интересно увидеть 111-ю ошибку для begin (кроме, разумеется, тех мест, где это положено по синтаксису, например в неинлайновой процедуре)

White OwlShocker.ProПочитай про @@TRANCOUNT, поэкспериментируй.Вот-вот. Почитай, поэкспериментируй.

пожалуйста

результат
0
1
0
никакой вложенности не наблюдаю.

White OwlА что, у автоматической транзакции нету явного начала? Она расплывчато начинается?

Нету явного оператора начала. Она начинается перед командой и заканчивается сразу после нее.

White OwlА уж влиять на транзакции из триггеров это вообще приглашать в гости большого и жирного песца.

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

White OwlВ пакет - не сможет, в несколько следующих друг за другом команд - сможет запросто.

У ТС-а был именно пакет. Зачем передергивать.

White OwlShocker.ProВерно. У ТС-са такой порядок:
begin tran
insert
delete
update
commit tran
Если на update произойдет сбой, то откатится и insert и delete. Если же убрать транзакцию, то insert и delete закоммиттятся, а update откатится/Ээээ... чего-чего? С чего это вдруг insert и delete будут откатываться???

Ибо не коммитили.

White OwlНе я первый попытался давить годами. И кстати, у меня все равно больше :)

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

White OwlСкандирую: ADO здесь ни при чем! ADO здесь ни при чем! ADO здесь ни при чем!
Не обвиняйте враппер в грех драйвера.

Тихо-тихо. Уши заложило. Я ведь уже согласился.

orunbekдела были, отходил
по поводу скрытых подключений, я на своей практике видел такое
тема по этому поводу
Аудит изменений через CONTEXT_INFO

Да, придется White Owl-у спорить с GreenSunrise - а это сложнее

Konst_Oneскрытые подключения - это результат вашего кода

В моем коде таких конструкций нет:

Konst_Oneвы с чем боретесь то? deadlocks у вас в базе при многопользовательской работе или что?

Борется за красоту кода