SqlTransaction завершился

Спасибо за всю обратную связь. Я работал с кем-то от MSFT на форумах MSDN для выяснения то, что продолжается. Оказывается, что проблема происходит из-за одной из вставок, переставших работать из-за проблемы преобразования времени даты.

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

у меня есть полный пример программы для тиражирования этой проблемы. Если кто-либо хочет видеть его или обмен с MSFT, можно найти поток на группах новостей MSFT в microsoft.public.dotnet.framework.adonet под SqlTransaction. Ошибочный поток ZombieCheck.

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

, Но оборотная сторона: если вставка перестала работать, любой другой вставляет в текущем пакете N, будет откатываться, когда Вы откатываете транзакцию.

В целом необходимо расположить транзакцию прежде, чем закрыть соединение (который будет откатывать транзакцию, если это не фиксировалось). Обычный шаблон смотрит что-то как следующее:

using(SqlConnection connection = ...)
{
    connection.Open();
    using(SqlTransaction transaction = connection.BeginTransaction())
    {
        ... do stuff ...
        transaction.Commit(); // commit if all is successful
    } // transaction.Dispose will be called here and will rollback if not committed
} // connection.Dispose called here

почтовый индекс, если Вы нуждаетесь в большем количестве помощи.

Следует иметь в виду, что Ваше приложение не является единственным участником транзакции - SQL Server включен также.

ошибка Вы заключаете в кавычки:

Этот SqlTransaction завершился; это больше не применимо. в System. Данные. SqlClient. SqlTransaction. ZombieCheck () в Системе. Данные. SqlClient. SqlTransaction. Фиксация ()

не указывает, что транзакция фиксировала, только что это завершено.

Мое первое предложение - то, что Ваш сервер уничтожил транзакцию, потому что это, любой занял слишком много времени (протек стенное время) или стало слишком большим (слишком много изменений или слишком много блокировок).

Мое второе предложение состоит в том, чтобы проверить чистку соединений и транзакций соответственно. Возможно, что Вы сталкиваетесь с проблемами, потому что Вы иногда исчерпываете пул некоторого ресурса, прежде чем вещи будут автоматически переработаны.

, Например, DbConnection реализации IDisposable, таким образом, необходимо гарантировать Вам, моется соответственно - с использование оператор, если Вы можете, или путем вызова Dispose() непосредственно, если Вы не можете. 'DbCommand' подобен, поскольку он также реализует IDisposable.

Ну, первый IMO, Вы не должны ожидать, что Ваше приложение будет иметь дело с "трудными" ошибками как они. Ваше приложение должно понять то, что эти бизнес-правила и составляют их. Не вынуждайте свою базу данных быть бизнес-правилом или ограничительным полицейским правила. Это должно только быть полицейским правила данных, и в этом, быть корректным о сообщении интерфейса с ВОЗВРАТАМИ и другими методами. Материал схемы не должен быть, повышают это далеко.

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

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

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

Hope это помогает.

Вы доказали, что Ваши данные в порядке вне всего обоснованного сомнения.
FWIW, я предпочел бы перемещать вставку в SPROC и не использую транзакцию вообще.
при необходимости в UI, чтобы быть быстро реагирующими, используйте второстепенного рабочего, чтобы сделать пехотинца базы данных.
мне, транзакция для взаимосвязанных операций, не экономящего время устройства. Стоимость вставки должна быть оплачена где-нибудь вдоль строки.

я недавно использовал профилировщика МУРАВЬЕВ на приложении базы данных и был поражен видеть, что исключения intermittant SQlClient показывают в единогласно работающем коде. Ошибки глубоки в платформе при открытии соединения. Они никогда не добираются до поверхности и не обнаруживаемы клиентским кодом. Так... Точка?
Это не все горное тело там, переместите тяжелую работу от U.I. и примите стоимость. HTH Bob