Программа написана на VFP 9 SP1 с использованием ADO, провайдер используется SQLOLEDB (впрочем проблема сохраняется и с SQL Native Client), сервер SQL 2005 SP2.
На клиенте выдается несколько последовательных команд 'begin tran' через метод Execute объекта Connection, считываю с сервера с помощью хранимой процедуры @@trancount, значение правильное, но если повторно считываю в следующей строке кода то @@trancount уже 0. То есть все транзакции закрыты, хотя команд rollback не было, а команда commit была только одна.
Под SQL 2000 все работало прекрасно. Сравниваю трассы из профайлера для 2005 и 2000, полностью совпадают. То ли мистика, то ли трасса записывает не все события.

Если трассу выполняю в Management Studio то все работает как положено.

Что бы еще посмотреть, проверить?
Может кто-нибудь сталкивался при переходе с 2000 на 2005?
Искал ответ в конференции по SQL Server, попалась ссылка на то, что так делать можно
http://support.microsoft.com/default.aspx?scid=kb;en-us;238163.

А почему не работает с 2005?

Aleksey-K1. В принципе, можно транзакцию растянуть на несколько пакетов, но главное, интерфейс с пользователем не должен быть вовлечен в транзакцию и при каждой SQLEXEC надо не забывать проверять на ошибку, а при ее наличии, посылать на сервер пакет вида: IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION, но лучше от этой практике отказаться. (как вам и советовал Sergey Ch)
2. Проверьте, не установлена ли у вас на уровне сессии (или в одном из пакетов) опция SET XACT_ABORT ON. Тогда при любой ошибки будет откат транзакции. Может у вас где-то в одном из пакетов получается ошибка и по SET XACT_ABORT ON откатывается вся транзакция.

С уважением, Алексей

Сейчас склоняюсь к варианту 2. Только похоже ошибка не моя, а то ли ADO, то ли Fox'a.
При втором запуске хранимой процедуры метод Execute объекта Command генерит следующий код
SET FMTONLY ON EXEC SET FMTONLY OFF
который при повторе в Managed Studio вызывает ошибку, именно после этой строки номер транзакции в профайлере становится нулевым

на SQL 2000 генерится
SET FMTONLY ON EXEC spGetTranCount 0 SET FMTONLY OFF

Aleksey-KУстановка SET FMTONLY ON просто заменяет вывод данных запроса на вывод пустого набора данных. Может это генерит сам ADO для определения кол-ва и типа колонок.
С уважением, Алексей

Проверил еще раз под 2000-ым там то же генерит неправильно, есть вообще три случая, первый
не генерится ничего кроме вызова самой процедуры, генерится с 'SET FMTONLY' и с указанием EXEC 'процедура', генерится с 'SET FMTONLY ON EXEC SET FMTONLY OFF'. Клиент ведет себя абсолютно одинаково, что под 2000, что под 2005, но под 2000 2-ой вариант прокатывает без последствий, а в 2005 откатывается транзакция, хотя настройки соединения, в том числе xact_abort одинаковы.