1c запрос commit transaction не имеет соответствующей инструкции begin transaction
Отмечает успешное завершение явной или неявной транзакции. Если значение @@TRANCOUNT равно 1, то инструкция COMMIT TRANSACTION делает все изменения, произведенные с начала транзакции, постоянной частью базы данных, освобождает ресурсы транзакции и уменьшает значение параметра @@TRANCOUNT до 0. Если значение @@TRANCOUNT больше 1, инструкция COMMIT TRANSACTION уменьшает значение @@TRANCOUNT только на 1 и оставляет транзакцию активной.
Example of Error
Here’s a simple example to demonstrate the error:
This will occur if your SET IMPLICIT_TRANSACTIONS is OFF . See below for what happens when SET IMPLICIT_TRANSACTIONS is ON .
Синтаксис
Ссылки на описание синтаксиса Transact-SQL для SQL Server 2014 и более ранних версий, см. в статье Документация по предыдущим версиям.
Примеры
Remarks
Обязанностью программиста на языке Transact-SQL является вызов инструкции COMMIT TRANSACTION только в том случае, когда все данные, относящиеся к транзакции, логически верны.
Если зафиксированная транзакция является распределенной транзакцией Transact-SQL, инструкция COMMIT TRANSACTION вызывает координатор MS DTC для использования двухфазного протокола фиксации на всех серверах, участвующих в транзакции. Если локальная транзакция охватывает две или более базы данных одного и того же экземпляра компонента Компонент Database Engine, то экземпляр использует встроенную двухфазную фиксацию для всех баз данных, вызванных в транзакции.
При использовании вложенных транзакций фиксация внутренних транзакций не освобождает ресурсы и не делает их изменения постоянными. Изменения данных становятся постоянными и ресурсы освобождаются только при фиксации внешней транзакции. Вызов каждой инструкции COMMIT TRANSACTION приводит к тому, что если значение @@TRANCOUNT больше 1, то значение переменной @@TRANCOUNT просто уменьшается на 1. Когда значение @@TRANCOUNT уменьшится до нуля, вся внешняя транзакция фиксируется. Так как аргумент transaction_name не учитывается компонентом Компонент Database Engine, вызов инструкции COMMIT TRANSACTION, содержащей ссылку на имя внешней транзакции, приводит к тому, что если существуют необработанные внутренние транзакции, то значение @@TRANCOUNT уменьшается только на 1.
Вызов инструкции COMMIT TRANSACTION, когда значение параметра @@TRANCOUNT равно нулю, приводит к ошибке, так как нет соответствующей инструкции BEGIN TRANSACTION.
Нельзя произвести откат транзакции после вызова инструкции COMMIT TRANSACTION, так как измененные данные уже стали частью базы данных.
Компонент Database Engine увеличивает счетчик транзакций внутри выражения, только когда счетчик транзакций равен нулю при запуске инструкции.
Аргументы
transaction_name
ПРИМЕНИМО К: SQL Server и база данных SQL Azure
Не учитывается компонентом Компонент SQL Server Database Engine. transaction_name указывает имя транзакции, присвоенное предыдущей инструкцией BEGIN TRANSACTION. Аргумент transaction_name должен соответствовать правилам для идентификаторов, но его длина не может превышать 32 символа. transaction_name сообщает программистам, с какой вложенной инструкцией BEGIN TRANSACTION связана инструкция COMMIT TRANSACTION.
@tran_name_variable
ПРИМЕНИМО К: SQL Server и база данных SQL Azure
Имя определенной пользователем переменной, содержащей допустимое имя транзакции. Переменная должна быть объявлена с типом данных char, varchar, nchar или nvarchar. Если переменной присваивается значение длиной более 32 символов, используются только первые 32, остальные усекаются.
DELAYED_DURABILITY
ПРИМЕНИМО К: SQL Server и база данных SQL Azure
Параметр, который запрашивает эту транзакцию, должен фиксироваться с задержанной устойчивостью. Этот запрос пропускается, если база данных была изменена с использованием DELAYED_DURABILITY = DISABLED или DELAYED_DURABILITY = FORCED . Дополнительные сведения см. в разделе Управление устойчивостью транзакций.
Implicit Transactions
If you have implicit transactions enabled, you might get different results to the first example.
If we set IMPLICIT_TRANSACTIONS to ON , here’s what we get:
No error occurs.
This is because, certain T-SQL statements automatically start a transaction when they run. It’s as if they were preceded by an invisible BEGIN TRANSACTION statement.
When IMPLICIT_TRANSACTIONS is OFF , these statements are automatically committed. It’s as if they’re succeeded by an invisible COMMIT TRANSACTION statement. In this scenario, the transaction is in autocommit mode.
When IMPLICIT_TRANSACTIONS is ON , there is no invisible COMMIT TRANSACTION statement. These statements are still started by an invisible BEGIN TRANSACTION , but they need to be ended explicitly.
An implicit transaction remains in progress until it is either explicitly committed or explicitly rolled back.
Therefore, in this example, our stray COMMIT TRANSACTION statement was actually needed to end the implicit transaction.
Б. Фиксация вложенной транзакции
ПРИМЕНИМО К: SQL Server и база данных SQL Azure
В следующем примере создается таблица и формируется три уровня вложенных транзакций, которые затем фиксируются. Хотя каждая инструкция COMMIT TRANSACTION имеет параметр transaction_name, связи между инструкциями COMMIT TRANSACTION и BEGIN TRANSACTION не существует. Параметры transaction_name позволяют программисту удостовериться в том, что закодировано правильное количество фиксаций, необходимое для того, чтобы уменьшить значение @@TRANCOUNT до 0 и таким образом зафиксировать внешнюю транзакцию.
Возникает у всех пользователей.
Кеш, tempdb чистили. Полное тестирование и исправление делали. Выгрузка базы в файл .dt. Создание новой БД и загрузка из .dt была
Ошибка осталась, появляется с разной периодичностью.
При использовании платформы 8.3.6.2390 и версии Бухгалтерия 3.0.44.115 таких проблем не было
На этом же оборудовании используется ЗУП 2.5 (1С 8.2) и самописная конфигурации (1С 8.3) с большой нагрузкой проблем нет
Вопрос к тем, кто поставил новый релиз.
По истечении недели использования, ничего страшного не вылезло? Каких-то новых ошибок?
(101)
(104)
Windows Server 2008 R2
SQL Server 2008 R2
Платформа 8.3.9.2170 ошибка замечена на УТ 10.3 (в режиме совместимости с 8.1) через 2 недели после обновления платформы. Замечена пока всего у 2-х пользователей.
Пользователи пожаловались, что базы стали медленней крутиться на платформе 8.3.9.2170 (до этого была 8.3.8.2054). Работают в БП 3.0. Не говорю что им не может казаться. У кого-нибудь производительность изменилась?
Поставили новую платформу.
Появилась проблема. Теперь при запуске внешних обработок спрашивает о разрешении запуска внешней обработки. И об использовании внешних приложений, типа Excel (если он используется в этой обработке). И запоминает ответ. Особо одаренные пользователи, не читая, отвечают - нет.
И все, второго шанса не дает.
Печалька.:(
Кто знает, где хранятся эти настройки?
Чистка кэша не помогла.
Платформа 8.3.9.1818. Ошибка появлялась только 2 раза. Помогала чистка серверного кэша. Сейчас опять вылезла, будем обновляться.
(114) Подтверждаю. В бухии было 4-7 в день павдений . Самописка на УФ валилась каждые 15-30 минут. два месяца полёт нормальный.
То же самое
8.3.10.2561, ERP 2.4, расширения, MS SQL 17
После первичного возникновения в процессе работы, начинает проявляется при входе в 1С
в техжурнале следующее:
(118) Похоже вы перезапустили SQL сервер, а 1С сервер продолжал работать в это время. Ошибка уйдет после перезапуска 1С сервера.
Поддерживаю, та же фигня.
Версии конфигурации, платформы и SQL такие же.
Другие базы работают нормально.
было что то похожее
Сегодня появилась с утра! Не у всех пользователей. Трое отписались с приложением скрина.
Первый раз за полгода вылез этот баг на 8.3.10.2466 + Native Client 11.0.
Надеюсь, в 8.3.11 этого бага уже нет.
Сегодня такая же ошибка в БИТ.ФИНАНС 3.1 (3.0.58.41/3.1.36.2/3.0.1.131).
Платформа 8.3.10.2580.
Тоже появилась с утра.
1С:Предприятие 8.3 (8.3.12.1440)
1С:Комплексная автоматизация 2 (2.4.3.160)
Ведомость на счета - увольнение
1С:Предприятие 8.3 (8.3.12.1412)
Зарплата и кадры государственного учреждения, редакция 3.1 (3.1.6.54)
Выходит при попытке проведения вновь созданного кассового ордера.
перешли на платформу 1С:Предприятие 8.3 (8.3.12.1529)
на пятый день возникла ошибка у некоторых пользователей и в логах Фоновое задание. Ошибка выполнения:
Соединение с сервером баз данных непригодно для использования после разрыва соединения администратором и будет переустановлено.
Microsoft SQL Server Native Client 11.0: Запрос COMMIT TRANSACTION не имеет соответствующей инструкции BEGIN TRANSACTION.
HRESULT=80004005, SQLSrvr: SQLSTATE=25000, state=1, Severity=10, native=3902, line=1
Добрый день всем! Платформа 8.3.10.2567 клиент серверная версия 1с и sql на разных серверах у пользователей возникает ошибка Соединение с сервером баз данных непригодно для использования после разрыва соединения администратором и будет переустановлено. Подскажите в чем может быть дело?
: Ошибка при получении значения атрибута контекста (ТекущийПользователь)
Запрос.УстановитьПараметр("ТекущийПользователь", ПараметрыСеанса.ТекущийПользователь);
по причине:
Соединение с сервером баз данных непригодно для использования после разрыва соединения администратором и будет переустановлено.
Microsoft SQL Server Native Client 11.0: Запрос COMMIT TRANSACTION не имеет соответствующей инструкции BEGIN TRANSACTION.
HRESULT=80004005, SQLSrvr: SQLSTATE=25000, state=1, Severity=10, native=3902, line=1
Платформа 8.3.10.2505 (не меняли полгода), последних 3 дня периодически выскакивает ошибка:
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
по причине:
Соединение с сервером баз данных непригодно для использования после разрыва соединения администратором и будет переустановлено.
Microsoft SQL Server Native Client 11.0: Запрос COMMIT TRANSACTION не имеет соответствующей инструкции BEGIN TRANSACTION.
HRESULT=80004005, SQLSrvr: SQLSTATE=25000, state=1, Severity=10, native=3902, line=1
Нашлось решение этой проблемы или опять ждать милости 1С?
платформа 8.3.11.3034 , фоновые задания по выходным выбивают такую ошибку : Сеанс. Ошибка применения расширения конфигурации; Критичная: Уже существует объект с именем скИспользованиеРабочегоСтола.ШаблоныОграничений.скПоЗначениямУдалить . помогает перезапуск службы, но это не выход. режим совместимости 8.3.10
Коллеги,
появилась такая же ошибка.
Соединение с сервером баз данных непригодно для использования после разрыва соединения администратором и будет переустановлено.
Microsoft SQL Server Native Client 11.0: Запрос COMMIT TRANSACTION не имеет соответствующей инструкции BEGIN TRANSACTION.
HRESULT=80004005, SQLSrvr: SQLSTATE=25000, state=1, Severity=10, native=3902, line=1
Платформа - 8.3.10
Конфа - Документооборот.
Всё работало полтора года исправно.
Мне помогло установка Драйвера "Драйвер Microsoft® ODBC 11 для SQL Server".
(установка вместе с "Собственный клиент Microsoft SQL Server 12").
Всем привет!
У нас сейчас платформа 8.3.6.2076, более менее стабильная, но пора идти дальше, потому как некоторые решения ой как требуют платформу поновее.
В связи с этим нужна стабильная платформа из 8.3.8, в том числе и серверная часть.
для себя выработал правило считать стабильным последний подрелиз, как только более старший релиз выходит в продакшн.
8.3.8 - тестовый, считаем 8.3.7 в продакшене, пользуем последний 8.3.6
8.3.9 - тестовый, считаем 8.3.8 в продакшене, пользуем последний 8.3.7
(15) тоже так считаю, жду 8.3.9 в продакшн, чтоб обновится до 8.3.8., нравятся некоторые фишки. Обновляю не каждый релиз, а через 2-3, сейчас стоит 8.3.6
(17) я тоже на 8.3.6. Есть список внутренний ошибок, которые нам актуальны. Тестил и 8.3.7 и 8.3.8 - нифига из того что нужно не исправили. Остаемся на 8.3.6
(15)(17) Мне проще. Думать особо не надо. Мы ставим ту платформу, релиз которой указан в требованиях к конфе поставщика.
к/с-вариант, бухня3, ~10 пользователей, скуль 2008, 32 гиг, сервер 64
память не жрет, процессов не плодит, зависших сеансов _пока_ нет.
на глаз быстрее чем 8.3.6, создание форм, общий отклик.
ну и рыжий котик в наличии на длительных операциях, ок.
(9) "Стабильно нашел" - это:
1. Сохраняет конфу без вылетов.
3. Пользователи не вылетают и не зависают
и пр.
(26) "ошибка формата потока", мне кажецца что-то с базой. дело не в платформах.
все отлично на 1964, кроме:
- Несколько раз попадал на "Ошибка потока"
- Выкидывает из платформы, когда пытаешься применить изменения конфигурации базы данных в случае когда конфа находится на отладке.
А есть ли какие то особенности в работе бухгалтерии 2.0 на 8.3 сервере? Щас на 8.2 в сервере работает, появилась необходимость перенести УТ 11 и ЖКХ на 8.3 сервер, два сервера одновременно или все-таки один 8.3.
(55) Вернуть 8.2, при условии что конфа может работать на 8.2, дело 10 минут, так что держать обе платформы нафиг не нужно. А переходят скорее всего затем, что новые релизы только под 8.3 (УТ 11 под 8.2 была ооочень давно)
(77) Нельзя основную таблицу Дин списка помещать в ВТ.
Теряется вообще всякий смысл использовать ВТ в дин. списках.
(80) +1 Тоже очень интересен этот вопрос!
Могу с уверенностью сказать не ставьте 8.3.8.1964 на ней периодически вылетает конфигуратор.
Пришлось вернуться на стабильный релиз - 8.3.6.2390. Но увы ЗУПу поддавай платформу 8.3.8, так что поисках.
Если неизвестно про надежность 8.3.8.2054, то скажите - легко ли можно будет обратно откатиться на 8.3.7 ?
Странно, что еще никто не сказал ни в коем случае не ставить 8.3.8.1933-1964, которые ломают РИБ и планы обмена напрочь. На партнерском там нехилый срач разгорался на более чем 100 постов. Релизы так и не отозвали, пользуйтесь на здоровье.
(81) сегодня скачали этот дистр - при установке вылетает с какой то ошибкой ДЛЛ.
скачали предыдущий релиз - нормально встал.
Запустил 3 запрос на обновление 3-ех разных таблиц и обернул в Begin Tran и Commit Tran.
На втором запросе получил ошибку, но данные в первой таблице не откатились.
Разве не должен был быть откат?
UPD
Как я понимаю, я должен был использовать вместо
Вводит в заблуждение, так не показан пример с проверкой на ошибки.
Еще не понял вот такого поведения:
Делал такой эксперимент: Сначала делаю N раз вот этот запрос:
--Транзакцию специально не закомитил
Затем отдельно делаю:
У меня откатились все мои N инсертов, хотя я сделал COMMIT TRAN, а лишь потом ROLLBACK tran. По идее транзакция должна была завершиться и на откат ничего не должно было пойти.
Если три обновления в одной общей транзакции - должен, каждое в своей транзакции - нет. Хмм. а rollback то вызвали? Откат при rollback происходит, либо если не было commit - при завершении соединения.
Да, если нужен откат, то нужно явно вызвать rollback . Однако, если если не было commit и rollback не был вызван, то откат произойдёт автоматически при закрытии соединения.
@i-one,А можно в ответ пример правильного использования? Мне всегда казалось, что BEGIN TRAN серия запросов COMMIN TRAN гарантируют, что если будет косяк, то будет откат.
@iluxa1810 вам стоит задавать новые вопросы в виде новых вопросов. "Еще не понял вот такого поведения:" имеет довольно слабое отношение к первой части вопроса.
Example of Error due to Error Handling
You could be getting this due to implementing error handling, and forgetting that you’ve already committed or rolled back the transaction elsewhere in your code.
In this case, I already had COMMIT TRANSACTION in the TRY block. So by the time the second COMMIT TRANSACTION was encountered, the transaction had already been committed.
We would see the same even if the transaction had encountered an error, and was rolled back. A rollback will end the transaction, and therefore, no further COMMIT statements are required.
So to fix this issue, we’d simply remove the last COMMIT TRANSACTION , and the transaction code would look like this:
A. Фиксация транзакции
ПРИМЕНИМО К: SQL Server, База данных SQL Azure, Azure Synapse Analytics и Система платформы аналитики (PDW)
В следующем примере удаляется кандидат на вакансию. В нем используется база данных AdventureWorks.
1 ответ 1
В случае конструкции
(при выполнении команд не в блоке TRY . CATCH . ) если на втором UPDATE возникнет ошибка, исполнение команд может продолжиться и дойти до COMMIT .
не будет правильным, т.к. глобальная переменная @@ERROR содержит номер ошибки для последней исполненной команды. Это означает следующее: если UPDATE 1 или UPDATE 2 завершится с обшибкой, а UPDATE 3 - без ошибки, то после UPDATE 3 значение переменной @@ERROR станет равно 0 , что сделает ложным вывод об успешности всей транзакции.
Если нужно при ошибке делать откат, то тут могут быть два варианта.
Первый - это исполнение команд в блоке TRY . CATCH .
В этом случае, при возникновении ошибки на 2м шаге, исполнение не продолжится, а по-возможности перейдёт в блок CATCH , где можно принудительно вызвать ROLLBACK .
Второй вариант - включение опции XACT_ABORT перед входом в транзакцию.
В этом случае при возникновении ошибок (определённого рода, не любых) на 2-м UPDATE выполнение команд будет прервано и произойдёт автоматический откат изменений. (Может быть даже не стоит считать этот вариант самостоятельным, на мой взгляд включение XACT_ABORT - это некое дополнительное средство; не припомню случая, когда бы я для отката транзакции пользовался этой опцией обособленно).
В некоторых случаях используется и то и другое.
Ниже чуть подробнее об автоматическом и управляемом откате.
Автоматический ROLLBACK
ROLLBACK может происходить автоматически, при закрытии соединения, если для данного соединения есть незавершенные транзакции. Т.е. создали, например, таблицу
Открываем соединение и в нём выполняем
закрываем соединение, не завершив транзакцию (ни COMMIT , ни ROLLBACK не сделали). SqlServer сделает откат такой транзакции, при разрыве соединения. Запросив затем данные из таблицы в новом соединении, мы увидим, что она пустая.
Также автоматический ROLLBACK может происходить при возникновении ошибок (таких как, например, нарушение PK, FK ограничений при вставке или удалении данных), если включена опция XACT_ABORT (по умолчанию OFF ). Например:
в этом случае до второго select и до commit дело не дойдёт, и откат произойдёт автоматически. Теперь при выключенном xact_abort (то что по умолчанию):
Несмотря на ошибку дело дойдёт и до commit (соответственно отката не будет) и до select после него.
К сожалению опция set xact_abort on полезна далеко не всегда. В частности она не откатывает транзакцию при генерации пользовательских исключений (в том числе сгенерированных в DML-триггерах). Например:
Несмотря на set xact_abort on и сгенерированное исключение дело дойдёт и до commit и до select после него. Поэтому полезнее может быть целенаправленный вызов rollback .
Управляемый ROLLBACK
Часто применяется в catch блоке, при оборачивании транзакции в try . catch . конструкцию:
При xact_abort off (т.е. по умолчанию) ROLLBACK не происходит автоматически, если транзакция была открыта, но из-за ошибки не достигла COMMIT . В этом случае SqlServer позволяет программисту самому решить будет ли откат полезен при той или иной ошибке, или нет. Далее пара примеров, когда откат может быть полезен в catch и когда вреден.
Пример 1: Изменение данных в транзакции.
Пусть есть процедура, которая в транзакции делает вставку данных в две связанных таблицы:
Допустим теперь, что произошёл вызов процедуры и началась вставка данных. Предположим, что вставка в Users прошла успешно, а при вставке в UserContacts произошел конфликт с уникальным индексом (UserID, ContactTypeID) (из-за того, например, что в @info один и тот же затесался дважды).
Если логикой приложения продиктовано, что либо сущность вставляется целиком, либо вообще не вставляется - тогда в catch делается rollback (как в данном примере).
Но возможны ситуации, когда ошибки, возникшие в результате выполнения каких-то отдельных запросов, не являются серьёзным основанием для отката всех совершенных действий. Например, если у нас не две связанных таблицы, а импорт данных в несколько независимых таблиц, и мы не хотим откатывать ту часть данных, что была уже успешно внесена. Тогда в catch можно попытаться сделать commit (не любая ошибка сделает это возможным, о том как это сделать корректно - в следующем примере).
Т.е. rollback не обязан происходить при возникновении любой ошибки. Делать откат, или нет - зависит от семантики данных и логики приложения.
Пример 2: Чтение данных в транзакции.
Транзакции для изменения данных достаточно привычны, но иногда в транзакции нуждается и чтение. Для таких транзакций необдуманно вызванный rollback может оказать медвежью услугу.
Пусть есть процедура, которая в repeatable read или snapshot транзакции читает данные:
If you’re receiving error Msg 3902, Level 16, which reads “The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION”, it’s probably because you’ve got a stray COMMIT statement.
You could be getting this due to implementing error handling, and forgetting that you’ve already committed or rolled back the transaction elsewhere in your code.
Разрешения
Необходимо быть членом роли public.
Читайте также: