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

[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++". Решилось снятием этого резерва по заказам, разноской приходника и, соответственно, возвратом резервов.