Shocker.ProWhite OwlShocker.Pro, сделай лучше это:
А потом рассматривай результаты

разумеется я получаю
Server: Msg 3903, Level 16, State 1, Line 14
The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION.

ибо ты пытаешься откатить несуществующую транзакцию
Замечательно. А теперь расскажи мне какой транзакции принадлежит какой из insert'ов?

orunbekСама задача несколько другая, я просто описал как бы прототип
в форме редактирования записи есть несколько гридов, в которых редактируются подчиненные данные основной записи, подобной таблице телефоновИ что это меняет? Или ты привязываешь гриды напрямую к курсорам? Если да, то срочно отвязывать. Пользователь должен иметь прямой доступ только к массивам в памяти клиентской машины.

orunbekнет, такого нет, в каждой записи есть дополнительное поле, которое указывает на то, что определенный пользователь уже открыл для редактирования, пока значение этого поля не сбросится никто другой не может редактировать запись
сброс происходит в двух случаях:
1. завершение редактирования
2. сброс администратором системы поля открытости записи

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

То есть схема в идеале будет такой:
- Открываем окно. Открываем курсоры. Читаем в собственные массивы все данные которые возможно редактировать. Читаешь дату последнего обновления записи. Закрываем курсоры.
- Пользователь редактирует все что ему угодно.
- Пользователь командует "Сохранить". Читаешь дату последнего обновления записи, если она совпадает с той которую ты прочитал в начале работы - просто сохраняешь все и обновляешь дату. Если не совпадает - выдаешь окно типа "КТО-ТО уже изменил эту запись! Прочитать изменения и вернуться в редактирование, игнорировать чужие изменения или отменить все и закрыть окно?"

Shocker.Proпервый и последний инсерт выполняются внутри собственных implicit-транзакций (счетчиком мы этого не увидим)
второй выполняется в явно открытой транзакции, счетчиком мы увидим 1.Угу. А кто интересно закоммитил последнюю вставку? Я же ее отменять пытался? Я же там явно rollback написал! Какая сволочь последнюю вставку утвердила?
Мой хрустальный шар утверждает что у тебя включен AutoCommit. То есть изменения которые ты не предварял командой begin tran ты уже в принципе не сможешь откатить... Замечательно.

Shocker.ProИ что? Пользователь внес кучу изменений. При сохранении выяснилось, что другой пользователь (или даже несколько других пользователей) внесли другую кучу изменений. Дальше МашаА дальше Маша смотрит на дополнительный диалог и видит в нем новые текущие значения и изменные ею значения.

Shocker.ProПравильный ответ - блокировка карточки. Один раз Маша карточку не закроет в режиме редактирования, уйдя на обед, получит пиз$#лей и в следующий раз не забудет.Проще предусмотреть заранее, чем потом наказывать людей и надеятся что это наказание пойдет впрок.

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

Shocker.ProWhite Owl - возвращайся! Ты еще не показал пример с ошибкой 111 И не покажу. Это уже я погорячился слегка. 111-ая возникает при отправке DDL команд которые не любят быть в пакете, операторными скобками оно не лечится.