Maximum buffer size

[S.Kuskov]

AX 4.0 SP2

Не выполняется SELECT.

static void JobMainresponsibleWhithOpenSales(Args _args)
{
    ContactPerson ContactPerson;
    CustTable CustTable;
    SalesTable SalesTable;
    
    while select Mainresponsible from ContactPerson
    group by Mainresponsible
    exists join CustTable
    where
        CustTable.ContactPersonId == ContactPerson.ContactPersonId
    exists join SalesTable
    where
        SalesTable.CustAccount == CustTable.AccountNum &&
        SalesTable.SalesStatus == SalesStatus::Backorder
    {
        info(ContactPerson.Mainresponsible);
    }
}

Выдаёт ошибку:
Суммарный внутренний размер записей в вашем объединенном операторе SELECT равен 28054 байтам, но система Microsoft Dynamics по умолчанию настроена так, что он не должен превосходить 24576 байтов.


В чём криминал? Откуда превышение? Запрос возвращает только ответственных Mainresponsible. По факту их двое, т.е. две строки в результате (проверял в query analyzer)

P.S.: Собирал Query в AOT таже история

В настройке AOS вот тут поставь 28 или больше:

[S.Kuskov]

Это всё понятно. Хочется понять из-за чего происходит превышение именно в этом конкретном запросе?

Слишкий длинный запрос получается - куча таблиц со всеми полями наджойнена

[S.Kuskov]

Но физически же поля выбираются только из одной. Все остальные присоединены exists join.
Что именно ограничивает этот параметр?

Ну х3, видимо при проверке аксапта не смотрит, какой там джойн, а тупо суммирует все поля из таблиц, и, естественно, она не проверяет количество реальных записей в таблице. Если получается, что больше, чем размер буфера - она стремается и вываливается в ошибку.

[S.Kuskov]

Т.е. правильно ли я понимаю, что на самом деле этот код не подходит под определение тяжёлых запросов, способных положить систему? И на самом деле это просто ложное срабатывание не совсем корректной проверки?

Смущает меня то, что весь стандартный функцианал, ведь как-то умещается в рамки стандартного буфера (встречаются запросики на первый взгляд помощнее этого). Что же такого страшного в джойне этих 3-х таблиц? Возможно размеры самих записей? Сейчас посмотрел: в каждой таблице порядка 100 полей. Выходит роковое стечение обстоятельств?

Видимо так.
Я глубоко в этот вопрос не вникал, т.к. симптомы и решение всегда были очевидны.

Но если ты все-таки найдешь истину - напиши потом здесь, думаю всем будет интересно.

[glibs]

Цитата:

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

...
правильно ли я понимаю, что на самом деле этот код не подходит под определение тяжёлых запросов, способных положить систему?
...

А при чем тут вообще тяжелый запрос? Буфер имеет отношение к коммуникации АОСа и клиента Аксапты.

Что-то у меня нигде не воспроизводится. Может вы каких полей в таблицы понадобавляли. А если писать что-то вроде

exists join TableId from CustTable

тоже ругается?

[S.Kuskov]

Цитата:

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

Буфер имеет отношение к коммуникации АОСа и клиента Аксапты.

Тогда тем более не понятно, чем результирующая выборка (ведь только она и будет передаваться между AOC и клиентом) неугадила?

Цитата:

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

Что-то у меня нигде не воспроизводится. Может вы каких полей в таблицы понадобавляли.

Нет, все поля стандартные.

У меня значение буфера не указано (по умолчанию)
количество строк в таблицах ~
ContactPerson = 30,
CustTable = 3000
SalesTable = 30000
В результате превышение буфера на 4 кб

Цитата:

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

А если писать что-то вроде exists join TableId from CustTable тоже ругается?

Да, так тоже пробовал. Не помогает

[glibs]

Цитата:

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

...
Тогда тем более не понятно, чем результирующая выборка (ведь только она и будет передаваться между AOC и клиентом) неугадила?
...

Тут дело не в выборке, насколько я знаю, а в том, что при обмене данных между АОСом и клиентом производится таким образом, что данные для источников данных для форм передаются не все сразу, а пакетами. Размер такого пакета не будет превышать максимальную величину буфера в настройке. В зависимости от запроса в пакет может попасть много, несколько или одна запись. А если результирующая запись не влазит в буфер, то должна быть ошибка как у вас. Это нужно для того, чтобы увеличить скорость отклика системы на действия пользователя на каналах с невысокой пропускной способностью.

AX2009 вам пишет, что Аксапта ошибается при расчете длины результирующей записи. Похоже на то, хотя я лично не могу быть уверен. Попробуйте поискать про буфер. Кажется, уже было достаточно.

[S.Kuskov]

Ага. Значит это величина одной записи не влезает в буфер. Тогда действительно если посчитать все поля(Параметр Maximum buffer size в настройках AOS) всех трёх таблиц , то получается что

    info(int2str(SysDictTable::newTableId(tableNum(ContactPerson)).recordSize()));
    info(int2str(SysDictTable::newTableId(tableNum(CustTable)).recordSize()));
    info(int2str(SysDictTable::newTableId(tableNum(SalesTable)).recordSize()));

9396
3813
8669

Такая сумма в полне сравнима с размером буфера.

Ну что ж, ситуация немного прояснилась. Остаётся только ждать и надеятся на её изменение в будущих версиях.

[Андре]

Добавлю, что этот параметр следует увеличивать крайне аккуратно, так как память указанного размере выделяется на AOS каждый раз при открытии нового соединения с БД (например, при работе с номерными сериями). Пару раз наблюдал, что чрезмерно завышенное значение данного параметра приводило к перерасходу памяти на AOS, а в предельном случае и к ее утечкам.