Запрос commit transaction не имеет соответствующей инструкции begin transaction

Опубликовано в Статьи по 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С Передприятия, это требование применения исходит от поставщиков прикладного решения.

Не сумев найти конкретного решения, начал решать проблему в следующем порядке:

  1. Тормознул все сервисы (MS SQL, Сервер 1С)
  2. Почистил весь кэш (на сервере);
  3. После чистки кэша перезапустил сервисы, конфигуратор стал запускаться, но режим предприятия по-прежнему нет (либо какое то время работает и опять вылетает ошибка).
  4. Попробовал выгрузить информационную базу. Получилось. Загрузил ее в файловый вариант и запустил тесты в конфигураторе (Проверка логической целостности, реиндексация таблиц).
  5. Увеличил опцию на SQL-сервере «Network packet size» до 16383 (максимально возможный по заявлению поставщика продукта).
  6. Выгрузил вариант файловой базы в dt и загрузил в чистую базу на SQL.
  7. Все заработало.

Увеличение опции на 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

  1. В обозревателе объектов щелкните правой кнопкой мыши сервер и выберите пункт Свойства.
  2. Щелкните узел Дополнительно .
  3. На вкладке Сетьвыберите значение в поле Размер сетевого пакета .

Параметр вступает в силу немедленно, без перезапуска сервера.

Источник

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!

Источник

Решение проблемы "Microsoft SQL Server Native Client 11.0: Запрос COMMIT TRANSACTION не имеет соответствующей инструкции BEGIN TRANSACTION"

Сегодняшний день на работе начался особенно жарко. Новое корпоративное приложение на базе платформы «1С:Предприятие 8» напрочь отказывалось запускаться. Вместо запуска ИБ пользователи получали ошибку «Microsoft SQL Server Native Client 11.0: Запрос COMMIT TRANSACTION не имеет соответствующей инструкции BEGIN TRANSACTION».

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

Оказалось, похожая проблема случается у многих, но детального и какого-то конкретного решения нет. Наткнулся на похожую тему форумов инфостарта, но решение сводилось к откату на ветку платформы 8.3.8. У нас применяется последняя доступная на сегодня версия 8.3.9.2170. Я бы рад откатиться, но требование применения 8.3.9 исходит от поставщиков прикладного решения, поэтому в моем случае даунгрейд не подходит.

Не сумев найти конкретного решения, начал решать проблему в следующем порядке:

  1. Тормознул все сервисы (MS SQL, Сервер 1С)
  2. Почистил весь кэш (на сервере);
  3. После чистки кэша перезапустил сервисы, конфигуратор стал запускаться, но режим предприятия по-прежнему нет.
  4. Попробовал выгрузить информационную базу. Получилось. Загрузил ее в файловый вариант и запустил тесты в конфигураторе (Проверка логической целостности, реиндексация таблиц).
  5. Увеличил опцию на SQL-сервере «Network packet size» до до 32767.
  6. Выгрузил вариант файловой базы в dt и загрузил в чистую базу на SQL.
  7. Все заработало.

После возвращения информационной базы к работе, наткнулся на упоминание, что действительно такая проблема имеет место быть (зарегистрирована в багтрекере 1С) и ее вроде как планировалось исправить в версии 8.3.10.

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

Источник

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

Источник

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.

Источник

Понравилась статья? Поделить с друзьями:
  • Запись ребенка в 1 класс московская область инструкция
  • Запечатыватель ржавчины мипа инструкция и способ применения
  • Записаться в гаи на регистрацию автомобиля через госуслуги инструкция
  • Записать виндовс на флешку через ultraiso пошаговая инструкция как
  • Запидин инструкция по применению цена отзывы аналоги