Ошибка времени выполнения: Буфер записей равен null.

[Logger]

Привет всем.
Кто-нибудь сталкивался с ошибкой "Буфера записей равен NULL" ?
2009-я аксапта.
Код выполняется внутри транзакции, дергается серверный статический метод внутри которого идет большое число вызовов то клиентского, то серверного методов.

В конце идет выход из серверного статического метода. В этот момент аксапта задумывается и выскакивает ошибка "Буфера записей равен NULL". (Похоже на сервере в этот момент идет очистка мусора).
Если статический метод переделать на Called from то все исполнение идет на клиенте и указанной ошибки не возникает. С чем это может быть связано ?

P.S.
Естественно, код надо переписывать на нормальное исполнение, но вопрос связан именно с упомянутой ошибкой. Не должно ее возникать.

[S.Kuskov]

В интернетах нашёл: http://dax-cz.blogspot.ru/2009/08/re...r-is-null.html

Пишут, что это из-за того что возвращается курсор выбранный для обновления.

Попробуйте перед возвратом курсору сделать .SelectForUpdate(false)

[Logger]

Цитата:

Сообщение от S.Kuskov

В интернетах нашёл: http://dax-cz.blogspot.ru/2009/08/re...r-is-null.html

Спасибо за помощь.
Поковырялся - у нас все оказалось немного по другому.
Пример не такой как у чехов а с точностью до наоборот.

У них серверный метод дергает клиентский код, который возвращает forupdate курсор.
У нас клиентский метод дергает серверный код который возвращает forupdate курсор (получен при помощи insert() ).

Ваш способ помог, но не совсем. Вызов .SelectForUpdate(false) после того как курсор вставили и еще и обновили не сбрасывает его свойство selectforupdate - пришлось возвращать дубликат курсора вызовом data()

Потом, посмотрел получше и вообще избавился от предшествующих клиент-серверных вызовов и это тоже помогло !
Т.е. изначально работало так :
Клиентский класс дергает серверный статический метод, который внутри себя создает шапку документа и его строки и по мере заполнения строк делает кучу клиентских вызовов к классу wmsTransportInvoiceReport_RU (он, зараза, клиентским оказался), а в конце возвращает созданную шапку.
Мне показалось странным что глюк от этого возник, т.к. сценарий когда из клиентского кода дергают серверный код, который создает запись и возвращает ее - используется сплошь и рядом. Должна была быть еще какая-то причина возникновения бага.

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

Т.е. нахождение объектов на разных tier однозначное зло. И за классами надо внимательнее смотреть куда они приписаны - called from, client или server

[S.Kuskov]

Цитата:

Сообщение от Logger

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

Уточните, пожалуйста, у вас перед возвращением курсор просто вставлялся или после вставки всё-таки ещё и обновлялся, а потом уже возвращался?

[Logger]

Вставка.
Затем обновление.
И только потом возврат.

[Logger]

Цитата:

Сообщение от S.Kuskov

Уточните, пожалуйста, у вас перед возвращением курсор просто вставлялся или после вставки всё-таки ещё и обновлялся, а потом уже возвращался?

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