Here’s a strange problem I’m running into on a production server. It has happened twice in the last two weeks, and this is a server that gets a lot of traffic.
We have some code in a Web Service that executes a BEGIN TRAN
, then runs a few SQL queries (two inserts followed by an update). Then at the end executes a COMMIT
. Twice now we have gotten the message in the logs:
The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION.
Between the first two inserts and the update, we call another web service, so there could be a slight delay between the first two inserts and last update before the COMMIT
is called. Could this be causing our problem? We’re running this on IIS 7 and Server 2008 R2 (all updated applied).
Originally we though it could be the app pools getting recycled, but changed that to recycle in the middle of the night. Now I’m not sure what would be causing SQL server to forget the call to BEGIN TRAN
.
This web service does get called quite a bit. Has anyone seen something like this before? I’m at a total loss at the moment…
Any help or suggestion appreciated greatly!
Jim Aho
10.2k16 gold badges57 silver badges90 bronze badges
asked Apr 11, 2011 at 15:43
1
It looks like your transaction failed, got rolled back and there is nothing to commit
example of such a thing
CREATE TABLE BlaTest(id INT PRIMARY KEY NOT NULL)
GO
Now run this
BEGIN TRAN
INSERT BlaTest VALUES('a')
GO
COMMIT TRAN
Here is the error
Msg 245, Level 16, State 1, Line 3
Conversion failed when converting the varchar value 'a' to data type int.
Msg 3902, Level 16, State 1, Line 2
The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION.
This will run without a problem
BEGIN TRAN
INSERT BlaTest VALUES(5)
GO
COMMIT TRAN
A good article on transactions is Error Handling in SQL 2005 and Later by Erland Sommarskog
answered Apr 11, 2011 at 15:45
SQLMenaceSQLMenace
133k25 gold badges206 silver badges225 bronze badges
3
My issue was I needed a BEGIN and END around my BEGIN TRAN and COMMIT TRAN.
BEGIN
BEGIN TRAN
INSERT BlaTest VALUES(5)
GO
COMMIT TRAN
END
answered May 21, 2019 at 10:21
arush436arush436
1,77820 silver badges21 bronze badges
0
BEGIN TRANS
at the top will help
answered Aug 5, 2022 at 9:28
1
I had this problem as well.
Turned out, in my case, the problem was two commit
s.
The first one worked as intended. The second produced this message. Deleting the second commit
solved the problem.
answered Jul 14 at 5:00
David DuboisDavid Dubois
3,8623 gold badges19 silver badges36 bronze badges
I had the same issue. This is what I did to solve it.
The COMMIT TRANSACTION
request has no corresponding BEGIN TRANSACTION
After I Checked the SQL
Query and Add a BEGIN TRAN
it will executed successfully. Here My sample code. It will work:
ALTER procedure [dbo].[DeactivateUser]
@UserId bigint,
@LoginEmail Nvarchar(100),
@merchantId int
as
Begin
Begin tran
update Users set
LoginEmail='inactive'+CONVERT(VARCHAR(11), getdate(), 106)+'-'+@LoginEmail,
IsActive=0
where LoginEmail=@LoginEmail and MerchantID=@merchantId
if(@@ERROR=0)
begin
commit Tran
select 0
end
else
begin
rollback Tran
select -1
end
end
Greg Viers
3,4833 gold badges20 silver badges36 bronze badges
answered Jul 25, 2013 at 12:11
Praveen04Praveen04
98310 silver badges12 bronze badges
1
Опубликовано в Статьи по 1С 06.11.2019
Приложение на базе платформы «1С:Предприятие 8» отказалось запускаться. Вместо запуска ИБ пользователи получали ошибку «Microsoft SQL Server Native Client 11.0: Запрос COMMIT TRANSACTION не имеет соответствующей инструкции BEGIN TRANSACTION».
Оказалось, похожая проблема случается у многих, но детального и какого-то конкретного решения нет. Наткнулся на похожую тему форумов инфостарта, но решение сводилось к откату на ветку платформы 8.3.8. У нас применяется последняя доступная на сегодня версия 8.3.12.1924. Откатиться на предыдущий версию платформы не предоставляется возожным, т.к. версия конфигурации не позволяется работать на более низких версия 1С Передприятия, это требование применения исходит от поставщиков прикладного решения.
Не сумев найти конкретного решения, начал решать проблему в следующем порядке:
- Тормознул все сервисы (MS SQL, Сервер 1С)
- Почистил весь кэш (на сервере);
- После чистки кэша перезапустил сервисы, конфигуратор стал запускаться, но режим предприятия по-прежнему нет (либо какое то время работает и опять вылетает ошибка).
- Попробовал выгрузить информационную базу. Получилось. Загрузил ее в файловый вариант и запустил тесты в конфигураторе (Проверка логической целостности, реиндексация таблиц).
- Увеличил опцию на SQL-сервере «Network packet size» до 16383 (максимально возможный по заявлению поставщика продукта).
- Выгрузил вариант файловой базы в dt и загрузил в чистую базу на SQL.
- Все заработало.
Увеличение опции на SQL-сервере «Network packet size» помогло решить проблему с вылетом.
Как увеличить размер сетевого пакета:
Параметр network packet size используется для установки размера пакета (в байтах), применяемого во всей сети. Пакеты — это фрагменты данных фиксированного размера, с помощью которых осуществляется передача запросов и ответов между клиентами и серверами. Размер пакетов по умолчанию составляет 4096 байт.
Если приложение осуществляет массовое копирование или отправляет/получает большие объемы данных типа text или image, увеличение размера пакета может повысить эффективность работы системы за счет сокращения числа сетевых операций чтения и записи. Если приложение отправляет и получает небольшие объемы информации, размер пакета можно уменьшить до 512 байт, чего в большинстве случаев достаточно.
Ограничения:
- Максимальный размер сетевого пакета для шифрованных соединений составляет 16 383 байта.
Настройки параметра конфигурации сервера network packet size в SQL Server 2019:
Использование среды SQL Server Management Studio
Настройка параметра network packet size
- В обозревателе объектов щелкните правой кнопкой мыши сервер и выберите пункт Свойства.
- Щелкните узел Дополнительно .
- На вкладке Сетьвыберите значение в поле Размер сетевого пакета .
Параметр вступает в силу немедленно, без перезапуска сервера.
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.
Example of Error
Here’s a simple example to demonstrate the error:
SELECT ProductName, ProductPrice FROM Products;
COMMIT TRANSACTION;
Result:
(7 rows affected) Msg 3902, Level 16, State 1, Line 2 The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION.
This will occur if your SET IMPLICIT_TRANSACTIONS
is OFF
. See below for what happens when SET IMPLICIT_TRANSACTIONS
is ON
.
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.
For example:
BEGIN TRANSACTION
BEGIN TRY
INSERT INTO Orders ( OrderId, OrderDate, CustomerId )
VALUES ( 5006, SYSDATETIME(), 1006 );
INSERT INTO OrderItems ( OrderId, OrderItemId, ProductId, Quantity, ItemPrice )
VALUES ( 5006, 1, 1, 20, 25.99 );
INSERT INTO OrderItems ( OrderId, OrderItemId, ProductId, Quantity, ItemPrice )
VALUES ( 5006, 2, 7, 120, 9.99 );
COMMIT TRANSACTION;
END TRY
BEGIN CATCH
ROLLBACK TRANSACTION;
END CATCH
COMMIT TRANSACTION;
Result:
(1 row affected) (1 row affected) (1 row affected) Msg 3902, Level 16, State 1, Line 20 The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION.
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:
BEGIN TRANSACTION
BEGIN TRY
INSERT INTO Orders ( OrderId, OrderDate, CustomerId )
VALUES ( 5006, SYSDATETIME(), 1006 );
INSERT INTO OrderItems ( OrderId, OrderItemId, ProductId, Quantity, ItemPrice )
VALUES ( 5006, 1, 1, 20, 25.99 );
INSERT INTO OrderItems ( OrderId, OrderItemId, ProductId, Quantity, ItemPrice )
VALUES ( 5006, 2, 7, 120, 9.99 );
COMMIT TRANSACTION;
END TRY
BEGIN CATCH
ROLLBACK TRANSACTION;
END CATCH
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:
SET IMPLICIT_TRANSACTIONS ON;
SELECT ProductName, ProductPrice FROM Products;
COMMIT TRANSACTION;
Result:
+---------------------------------+----------------+ | ProductName | ProductPrice | |---------------------------------+----------------| | Left handed screwdriver | 25.99 | | Long Weight (blue) | 14.75 | | Long Weight (green) | 11.99 | | Sledge Hammer | 33.49 | | Chainsaw | 245.00 | | Straw Dog Box | 55.99 | | Bottomless Coffee Mugs (4 Pack) | 9.99 | +---------------------------------+----------------+ (7 rows affected)
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.
What is the problem with this code.
It is giving this error The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION.
when some exception is coming in the procedure. How can I solve it?
BEGIN
BEGIN TRANSACTION
DECLARE
@Id bigint
,@Month nvarchar(100)
,@Year nvarchar(100)
,@CountryofExport nvarchar(100)
,@CountryofOrigin nvarchar(100)
,@HSCode nvarchar(100)
,@Unit nvarchar(100)
,@Quantity nvarchar(100)
,@CustomValue nvarchar(255)
,@Type nvarchar(100)
,@TypeBit bit
,@CountryofExportID int
,@CountryofOriginID int
,@MeasurementId int
,@Remarks nvarchar(500)
,@CommodityId int
,@SDate nvarchar(100)
,@SameRec int
,@counts int
DECLARE @Cursor_TradeFlow CURSOR
SET @Cursor_TradeFlow = CURSOR FOR
SELECT [Id],[Months],[Years],[CountryofExport],[CountryofOrigin],[HSCode],[Quantity],[Unit],[CustomValue],[Type] FROM [Temp_Trading]
OPEN @Cursor_TradeFlow
FETCH NEXT FROM @Cursor_TradeFlow INTO @Id, @Month, @Year, @CountryofExport, @CountryofOrigin, @HSCode,@Quantity, @Unit, @CustomValue, @Type
WHILE @@FETCH_STATUS = 0
BEGIN
Set @Remarks='';
Declare @EICountry varchar(100),
@Checkbit bit,
@CheckYearIsNumeric bit,
@CheckMonthIsNumeric bit
BEGIN TRY
SET @CheckMonthIsNumeric= convert(INT, @Month);
END TRY
BEGIN CATCH
begin
set @Checkbit=1;
set @Remarks = @Remarks + 'Invalid Month'
set @CheckMonthIsNumeric=1
end
END CATCH
BEGIN TRY
set @CheckYearIsNumeric= convert(INT, @Year);
END TRY
BEGIN CATCH
SET @CheckYearIsNumeric= 1;
set @Checkbit=1;
set @Remarks = @Remarks + 'Invalid Year'
END CATCH
Set @SameRec = (Select COUNT(*) From TradeFlow Where int_Month = @CheckMonthIsNumeric and int_Year = @CheckYearIsNumeric
and int_OriginLocationId = @CountryofExportID and int_DestinationLocationId = @CountryofOriginID and int_CommodityId = @CommodityId
and int_MeasurementId = @MeasurementId)
IF @@ERROR <> 0
BEGIN
ROLLBACK
END
FETCH NEXT FROM @Cursor_TradeFlow INTO @Id, @Month, @Year, @CountryofExport, @CountryofOrigin, @HSCode,@Quantity, @Unit, @CustomValue, @Type
END
CLOSE @Cursor_TradeFlow
DEALLOCATE @Cursor_TradeFlow
COMMIT
END
- Remove From My Forums
-
Question
-
User-1203469223 posted
whats wrong with my stored procedure:
1 ALTER PROCEDURE [dbo].[insert_DagVerslag] 2 -- Add the parameters for the stored procedure here 3 @serverID int, 4 @datum datetime, 5 @ID int OUTPUT, 6 @bestaatReeds varchar(5) = 'true' OUTPUT 7 AS 8 BEGIN 9 -- SET NOCOUNT ON added to prevent extra result sets from 10 -- interfering with SELECT statements. 11 SET NOCOUNT ON; 12 13 -- Insert statements for procedure here 14 IF NOT EXISTS (SELECT * FROM Log where(serverID=@serverID) AND (datum=@datum)) 15 BEGIN TRANSACTION 16 INSERT Log ( serverID, datum) 17 VALUES( @serverID, @datum) 18 COMMIT TRANSACTION 19 SET @ID = SCOPE_IDENTITY() 20 SET @bestaatReeds = 'false' 21 END
The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION.
Answers
-
User955742345 posted
You’re missing the BEGIN tag for your multi-line IF statement:
1 ALTER PROCEDURE [dbo].[insert_DagVerslag] 2 -- Add the parameters for the stored procedure here 3 @serverID int, 4 @datum datetime, 5 @ID int OUTPUT, 6 @bestaatReeds varchar(5) = 'true' OUTPUT 7 AS 8 BEGIN 9 -- SET NOCOUNT ON added to prevent extra result sets from 10 -- interfering with SELECT statements. 11 SET NOCOUNT ON; 12 13 -- Insert statements for procedure here 14 IF NOT EXISTS (SELECT * FROM Log where(serverID=@serverID) AND (datum=@datum)) BEGIN 15 BEGIN TRANSACTION 16 INSERT Log ( serverID, datum) 17 VALUES( @serverID, @datum) 18 COMMIT TRANSACTION 19 SET @ID = SCOPE_IDENTITY() 20 SET @bestaatReeds = 'false' 21 END
-
Marked as answer by
Thursday, October 7, 2021 12:00 AM
-
Marked as answer by
-
User-1506829456 posted
Hi,
This is because the returned @bestaatReeds parameter is a null value. In this case, you will need to check if oCmd.Parameters[«@bestaatReeds»].Value is a DBNull value. You will need to add a breakpoint to check for that.
Also, I suggest you use the bit type instead of a varchar, since it will be better to cast from bit to boolean instead of string to boolean.
-
Marked as answer by
Anonymous
Thursday, October 7, 2021 12:00 AM
-
Marked as answer by
Ошибка СУБД
Модератор: Дмитрий Юхтимовский
Ошибка СУБД
Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Запрос COMMIT TRANSACTION не имеет соответствующей инструкции BEGIN TRANSACTION. HRESULT=80004005, SQLSrvr: SQLSTATE=25000, state=1, Severity=10, native=3902, line=1
Добрый день, не знаю можно ли здесь обращаться с подобными вопросами, но если можно, то столкнулся с такой ошибкой, она возникает при установке ролей пользователю, возникает не всегда, а когда либо много пользователей работает, либо запущены все регламентные задания.
Подскажите пожалуйста куда копать.
- Антон
- Сообщений: 4
- Зарегистрирован: 18 июн 2015, 21:41
Re: Ошибка СУБД
Гилёв Вячеслав » 18 июн 2015, 23:27
откатиться к предыдущей версии конфигурации
- Гилёв Вячеслав
- Сообщений: 2727
- Зарегистрирован: 11 фев 2013, 15:40
- Откуда: Россия, Москва
Re: Ошибка СУБД
Антон » 19 июн 2015, 11:16
Вы не про уровень совместимости?
именно про наши доработки?
- Антон
- Сообщений: 4
- Зарегистрирован: 18 июн 2015, 21:41
Re: Ошибка СУБД
Антон » 19 июн 2015, 11:19
такое ощущение, что перед этим уровень совместимости повысили.
- Антон
- Сообщений: 4
- Зарегистрирован: 18 июн 2015, 21:41
Re: Ошибка СУБД
Антон » 19 июн 2015, 11:55
вообще ради интереса, поставил на локальную машину sql server, взял вчерашний бекап, зашел под 10 пользователями, включил все регламентные задания, стал менять права пользователям, все работает.
(при таких же условия и даже меньших пользователях не всегда дает менять права)
единственные отличия на глаз это операционные системы, на локальной машине 7 стоит, на сервере с проблемами 2008 R2.
И на локальной платформа последняя, на сервере предпоследняя, но не думаю что дело в этом. (хотя этот нюанс проверю в выходные.)
- Антон
- Сообщений: 4
- Зарегистрирован: 18 июн 2015, 21:41
Re: Ошибка СУБД
Гилёв Вячеслав » 19 июн 2015, 12:59
я про предыдущую версию кода конфигурации
- Гилёв Вячеслав
- Сообщений: 2727
- Зарегистрирован: 11 фев 2013, 15:40
- Откуда: Россия, Москва
Вернуться в MS SQL Server для целей 1С:Предприятие
Кто сейчас на форуме
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0