Превышено количество открытых курсоров

[sukhanchik]

Всем привет!
Никто не сталкивался с subj-ем?
В 4.0 (по сравнению с 2.5) сообщение почти не изменилось: "Превышен верхний предел Microsoft Dynamics по количеству открытых курсоров (90). Измените параметр -OPENCURSORS или измените код X++".

Поиск по форуму дал 2 похожих ссылки:
Измените параметр -OPENCURSORS
Как закрыть Query (курсор)? Axa2.5

В одном случае был лишний код, в другом - лишний join (=лишний код).

Сие сообщение у меня возникает при резервировании определенных товаров при выборе их в заказе на перемещение. Никто сталкивался с возникновением ошибки в похожем месте?

Общего ответа не жду (система с модификациями) - в общем-то только лишь интересно - если кто сталкивался с этим именно в этом функционале.
Заранее спасибо.

4.0 SP2

[Sada]

Посмотрите где происходит резервирование. Вроде должно на сервере резервироватся. Тогда этого сообщения не будет. Или я чтото путаю

[glibs]

Я так и не понял, параметр Maximum open cursors в конфигурационной утилите АОСа вы увеличивали или нет?

Что написано в Eventlog?

[Sada]

Увеличение открытых курсоров мне ктото говорил не есть хорошо. Можно и тыщщу поставить.

[glibs]

Ну... жить, например, опасно, вредно и дорого. Вы же не приняли решение не жить из-за этого?

Так и тут.

Ясное дело, что количество нужно увеличивать с умом, а не вляпать там бездумно слишком большое число.

[Sada]

Цитата:

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

Ну... жить, например, опасно, вредно и дорого. Вы же не приняли решение не жить из-за этого?

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

[sukhanchik]

Увеличение кол-ва открытых курсоров на АОСе до 1000 не спасало ... Поэтому и написал.

Резервирование вроде происходит на сервере (по кр. мере в стеке вызовов нет клиентских вызовов). Но я детальнее покопаюсь в коде - спасибо за наводку.
С другой стороны из почти 18 тыс позиций - проблемными являются только 2 пока. Поэтому и думаю - с чем бы могло это быть связано.

[Sada]

Если запускатеся класс с этой обработкой, то поставьте у него в совйствах ран он сервер и посмотрите что получится. Вообще такую ошибку видел только раз и то 3 года назад. Как исправили не помню (:

[ZVV]

Цитата:

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

Посмотрите где происходит резервирование. Вроде должно на сервере резервироватся. Тогда этого сообщения не будет. Или я чтото путаю

А какая связь?
В случае тонкого клиента все запросы делаются с сервера, и курсоры соответсвенно там же открываются?
Или я что-то я не понимаю?

[Sada]

В случае тонкого - да. Но думаю тут не тот случай.

[sukhanchik]

Случайно наткнувшись на ветку - решил написать - "чем дело кончилось".
А кончилось оно тем, что я наткнулся на:
1. Грабли со складскими аналитиками в заказах на пермещение (Что я был не первым - об этом я узнал здесь).
2. Собсно - складская аналитика была не абы какая - а ГТД - т.е. наша российская. Причем с галкой "Физический" (т.е. остатки считать в разрезе ГТД)
3. Неоткомпилированность (глобальная) рабочего приложения (ошибки исчислялись десятками) . Да, увы - и на эти грабли случайно приходится наступать - особенно когда только только знакомишься с приложением, которое модифицировали до меня.

Т.е. резюмируя:
Система пыталась зарезервировать товар не по той ГТД, но т.к. приложение было некомпиленое - то вместо ошибки - типа "Облом" - система уходила в даун. Повторюсь - приложение с модификациями.
Т.е. начинать надо с глобальной компиляции

Соответственно, я откомпилировал приложение, получил ошибку - разобрался с ГТД и все встало на свои места.

[Omeo]

столкнулись с такой же ошибкой в коде примерно такого вида:

void main()
{
 ttsbegin;
 updateCompany(mainCompany);
 ttscommit;
}
void updateCompany(CompanyNo _companyNo)
{
 ;
 while select ChildNo from companyTree
  group by ChildNo
  where companyTree.ParentNo = _companyNo
 {
  this.updateCompany(companyTree.ChildNo);
 }
}

решение: вынесли из тела селекта рекурсию

[Deepoint]

У нас так же случилась такая беда при разноске приходника. Оказалось, что в журнале прихода в ручную изменили дату оприходывания. При этом оприходуемая номенклатура перед этим уже разбежалась по заказы на продажу. И висела там в статусе "Зарезервировано в заказанных". Аксапта отчаянно не понимая такого изврата валилась с ошибкой "Превышен верхний предел Microsoft Dynamics по количеству открытых курсоров (90). Измените параметр -OPENCURSORS или измените код X++". Решилось снятием этого резерва по заказам, разноской приходника и, соответственно, возвратом резервов.