Во первых, количество транзакций надо проверять через select @@trancount
Во вторых, ручное управление транзакциями может быть полезно ЧРЕЗВЫЧАЙНО редко. В 99.(9)% ручной вызов begin tran абсолютно не нужен и более того - вреден. И это ВСЕГДА является признаком кривого проектирования приложения.

orunbekпо поводу ручного вызова ADOConnection.BeginTrans
мне оно нужно для того чтобы обновление нескольких таблиц выполнилось или не выполнилось грубо говоря, т.е. выполняются несколько SQL-инструкций на обновление и на получение определенных значений, если одна из них не выполняется, откатываются все,
т.е. в первую очередь транзакции для чего нужны, чтобы блок операций выполнились целиком
как еще по другому сделать?Ну в принципе, можно и по другому - почти всегда можно заранее узнать сработает обновление базы или не сработает.
Твое решение (откатить все если упала одна из команд) проще и надежнее, но для этого вручную открывать транзакцию совсем не нужно. Твоя первая команда к базе автоматически открывает транзакцию, которую потом и надо закрывать. Автоматических транзакций за глаза хватает для практически любых задач.

orunbekдля интереса я попробовал создать пустой проект, где выполняется такое же подключение к SQL-серверу, к той же базе, и попробовал BeginTrans сделать - работаетВ приведенном примере ничто не мешает убрать cnnMain.BeginTrans совсем. Здесь он точно не нужен.
А причина проблемы скорее всего в том, что у тебя в других функциях/окнах/модулях тоже есть cnnMain.BeginTrans , но в каких-то из этих модулей ты забыл сделать cnnMain.CommitTrans ...

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

Shocker.Proorunbek,

выполни пакет в один прием:

то бишь засунь все это в одну строковую переменную и выполни разом

а по хорошему сделай процедуру на сервереЭто неверный совет.
Во первых, begin tran внутри пакета ничем не отличается от ADODB.Connection.BeginTran. Во вторых, сервеные процедуры это всего-лишь группирование команд и запуск их в отдельной сессии... а это значит что проблема будет замаскирована областью видимости, но не решена.

orunbekно про это я то в первую очередь посмотрел, в других местах нету, поэтому я и удивляюсь как оно может превысить лимит транзакций, если до BeginTrans вообще не открывались транзакции :-)Кроме BeginTrans есть много других способов открыть транзакцию. Начиная от простых insert/update/delete и до рекурсивных триггеров. Баг может быть где угодно и это еще одна из причин почему я сам никогда не использую begin tran и другим запрещаю.
orunbekпоходу буду с админом базы "драться" чтобы на хранимки перевести :-)Как я уже сказал Shocker.Pro, это только спрячет проблему, но не решит ее.

orunbekкоманд обновления или вставки или же удаления до BeginTrans нету, в том числе триггеров
ладно попробую еще покопатьЧто, совсем-совсем нету? :) Ты же пробовал уже свой набор команд на микро-проекте. И он работал, верно? Значит в основном проекте где-то при старте есть открытие паразитных транзакций.

Когда ты запускаешь программу и открываешь коннект к базе - транзакций нету. Любая команда после открытия коннекта начинает неявную транзакцию. Любая, в любом окне или даже вообще без окна. Как только ты чихнул в сторону открытого коннекта - в нем завелась неявная автоматическая транзакция. А еще есть такая вещь как DDL и смена сессионых настроек которые могут играться с транзакциями совершенно самостоятельно без твоего явного участия. Это обязательно будет указано в документации, но кто-ж ее читает?...
Запускаешь на неявную транзакцию BeginTran один раз - неявная превращается в явную, запускаешь второй раз - получаешь вложеные транзакции со всеми их плюшками и подводными камнями. Откроешь два окна в каждом из которых есть BeginTran получишь двойную вложенность. Закроешь одно окно с commit, а второе с rollback - откатишь изменения сделаные в первом окне. Причем порядок закрытия не важен - что первым закрыл, то и потерял.
В идеале, ты с клиента должен посылать атомарные пакеты запросов всегда заканчивающиеся commit или rollback. Чем ближе к атомарности ты подберешься тем лучше. Из окон вообще старайся работать с базой только два раза - при открытии окна прочитать данные и при закрытии записать изменения. различные *Grid работающие с долгоиграющими курсорами должны быть под абсолютным запретом.

Shocker.Proпакет либо начнет выполняться, либо повиснет в ожидании снятия блокировок,Эээээ.... нет.
К сожалению, это не верно. Блокировка работает на уровне отдельных команд а не целого пакета. До реальной атомарности пакетов MS SQL еще расти и расти.

Shocker.Proи блокировки можно спокойно разглядывать и искать причинуУ orunbek к тому же проблема не в блокировках, а в "множественных транзакциях" которые на самом деле скорее всего множественные курсоры. Скорее всего DBGrid какой-нибудь или запросы с перемежающимся указанием adUseClient и adUseServer, которые способны сожрать все ресурсы.

Shocker.Proа если весь не будет содержать этих адошных стартов транзакций
то и такие проблемы перестанут возникать при таких простых операцияхADODB.Connection.BeginTrans делает всего одну вещь - посылает в открытый коннект команду " begin tran ". А посылка нескольких команд по отдельности почти ничем не отличается от посылки пакета (только множественными резалтсетами).