Размер буфера записи превышен. Как так может быть?

[kitty]

На форму поставщика попросили добавить три поля - ссылки на Работника компании (как в стандарте уже сделана ссылка на контактное лицо)
Добавила. В таблице все ок, на форме же при открытии выпадает сразу "
The total, internal size of the records in your joined SELECT statement is 71176 bytes, but Microsoft Dynamics is by default performance-tuned not to exceed 49152 bytes."
Проблема в том, что reference group добавляет джойн к HcmWorker и еще до кучи DirParty. А таких группы нужно целых три....
Что делать - приблизительно понятно: либо увеличивать размер допустимый буфера или же убирать поля из VendTable и создавать новую таблицу с новыми полями...

Вопросы:
1) Если я помещу поля в отдельную новую таблицу, то все равно, чтобы их показывать форме поставщика, надо будет этй таблицу джойнить с VendTable на форме и то размер буфера останется приблизительно таким же. То есть, та же ошибка будет

2) Я не понимаю вот что. Я вижу, что размер буфера при удалении каждого из новых полей уменьшается на 7198 байтов. То есть, удалила поле и получила сообщение "SELECT statement is 63978 bytes ...." , удалила второе - уже " is 56780 bytes" , потом " 49582 bytes" (то же самое происходит, если удаляю стандартую сслку на контакное лицо. То есть, проблема не в том, что я что-то криво делаю). Смотрю формируемый запрос и вижу. что да, две таблицы HcmWorker и DirParty присоединяются, но из них берутся только следующие поля:


T12.PERSON,
T12.RECVERSION,
T12.RECID,
T16.NAME,
T16.RECID,
T16.RECVERSION,
T16.INSTANCERELATIONTYPE,
T16.RECVERSION,
T16.RECID

Тут все поля int64, кроме имени, что в базе хранится как nvarchar(100) и поэтому максимум может быть 200 байтов. Это все хозяйтво заведомо меньше даже 300 .

Вопрос - откуда берется разница в 7198 байтов (что видно из вышеприведенных собщений от ошибках) при добавлении каждого поля ??????

[ax_mct]

Столкнулся неделю назад с таким же на этой же форме. Когда 23 датасоурса форма рано или поздно сойдет с ума.

Как я понял при подсчете буфера считается не текущий размер а максимально возможный.

Лучше обойтись вообще сторонней таблицей и без join. Не уверее насчет влияния типа join. Например будет ли считаться passive.

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

А тяжесть форм что CustTable что SalesTable какая-то беспредельная в AX2012.

То есть я бы не пытался понять почему, а просто сделал бы тупое решение на display/edit методах даже без датасоурс.
Недавно даже сделал на голых несвязанных контролах в SalesTable заполняя их на run() и на смене CustAccount так как display методы не подошли.

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

P.S. Как вариант можно очищать автомический join и указывать свою собсвенную связь на уровне методов датасоурса.
В системе много таких примеров. Но это может быть overkill если речь о показе трех полей. Даже edit методы будут дешевле так как полностью сбоку.

PPS
Но если вдруг то можно даже искать не по RecID, а скажем по имени или номеру etc. Эти RecId они очень вражеские.
qbdsLocation.clearLinks();
qbdsLocation.addLink(fieldNum(InventSite, SiteId ), fieldNum(InventLocation, InventSiteId));
qbdsLocation.addRange(fieldNum(InventLocation, InventLocationType)).value(queryValue(_inventLocationType));

[Alexius]

Скорее всего это : Maximum buffer size

[ax_mct]

Цитата:

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

Скорее всего это : Maximum buffer size

Цитата:

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

Возьму на вооружение .recordSize().

Автору. Думаю что стоит учитавать всякие CU которые скорее будут увеличивать размер и не считать байты, а как-то сделать сбоку. Если не строки грида, то вариантов много.

[kitty]

Цитата:

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

То есть я бы не пытался понять почему, а просто сделал бы тупое решение на display/edit методах даже без датасоурс.

Извините, а как Вы делали на edit-методе ? То есть, вот есть у меня поле recID, на форме нужно показывать Name. Имя не уникально. Получается, что мы можем по хранящемуся RecID вывести Name, а вот обратно, когда Set = true, то по Name однозначно оперделить recid уже не можем... Можно в из lookup доставать recid и на modified() контрола прописывать его, наверное, но как-то некрасиво ....

[ax_mct]

Цитата:

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

Извините, а как Вы делали на edit-методе ? То есть, вот есть у меня поле recID, на форме нужно показывать Name. Имя не уникально. Получается, что мы можем по хранящемуся RecID вывести Name, а вот обратно, когда Set = true, то по Name однозначно оперделить recid уже не можем... Можно в из lookup доставать recid и на modified() контрола прописывать его, наверное, но как-то некрасиво ....

Получается задача в том чтобы хранить пару значений на форме, RecID и Name.
Поодиночке они нам неинтересны.

В случае строк грида это скорее всего свой X++ map на уровне формы. Достаточно общий в AX подход.

В случае просто одиноких полей, можно и так. А можно просто иметь отдельный контрол для RecId и отдельный контрол для Name. Lookup по контролу RecId, display Name. То что пользователь будет видеть 777777777 и рядом Name, ему все равно.

[kitty]

Ну вот еще в dirPartyLookup, там перехватывается закрытие формы и прописываются recid значения в вызывающий контрол... По сути , та же идея, что и с modified(), кот я имела ввиду, но нужно еще отдельную lookup форму делать ....
В любом случае, просто edit-методом не понимаю, как можно отделаться ....

[kitty]

Спасибо
Вроде, мне повезло.
Посмотрела на HcmWorker таблицу попристальней, там есть уникальное string поле PersonnelNumber . Многие стандартные таблицы вообще по нему связаны...а не по recId .... с ней.
Я так понимаю, что не супер идеально, но вполне можно мне тоже просто PersonnelNumber добавить на VendTable и обойтись стандартным лукапом.... без referenceGroup, раз в стандарте себе такое позволяют ?

[ax_mct]

Цитата:

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

Спасибо
Вроде, мне повезло.
Посмотрела на HcmWorker таблицу попристальней, там есть уникальное string поле PersonnelNumber . Многие стандартные таблицы вообще по нему связаны...а не по recId .... с ней.
Я так понимаю, что не супер идеально, но вполне можно мне тоже просто PersonnelNumber добавить на VendTable и обойтись стандартным лукапом.... без referenceGroup, раз в стандарте себе такое позволяют ?

У Retail Affiliate тоже RecID, referenceGroup, alternative key... А потом бац и уникальный Name. И чего ради тогда все эти пляски?

Если есть рабочий пример в системе то быстрее сделать так же, чем придумывать как идеально. Идеально оно было в 3.0

[Alexius]

Цитата:

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

У Retail Affiliate тоже RecID, referenceGroup, alternative key... А потом бац и уникальный Name. И чего ради тогда все эти пляски?

Может ради Alternate Key и возможности изменять Name без перелопачивания всей базы ?

[kitty]

Понятно, что нормализация в теории красиво выглядит, но реализация - какое-то маркобесие.
А когда еще и в стандарте видишь, что сами предпочитают связываться по полю из alternate key, а не по навязываемым суррогатным, то так и хочется предать этих проповедников анафеме....

Осталось вот еще консультанту объясить, почему добавление трех полей занимает не обещанные 5 минут, а чертисколько....рррррр

[ax_mct]

Цитата:

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

Осталось вот еще консультанту объясить, почему добавление трех полей занимает не обещанные 5 минут, а чертисколько....рррррр

А это как раз то чем отличается опытный программист Отсутствием оптимизма

Обьяснить в данном случае легко так все упирается на размер дозволенного буфера и надо искать workaround - это понятное обьяснение. Типа авария на дороге.

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