Ax 2012 R2. Поле "не извлечено"

[ice]

Коллеги,
Столкнулся с такой проблемой, создаю новое поле на стандартной таблице, добавляю его на форму, открываю форму и вижу на месте где должно находиться новое поля надпись "не извлечено". если открыть таблицу через браузер таблиц, то поле есть и редактируется. проделывал разные танцы с бубном, помогают через раз, точного алгоритма не выявил. Есть ли способ решения?

[kashperuk]

А если включить эту галочку (см тут http://kashperuk.blogspot.com/2011/1...ld-access.html), может увидите ошибку какую?

[ice]

включил. никаких ошибок нет. поле все в том же состоянии(

[kashperuk]

Ну, я такое видел только если синхронизация на таблице не была сделана после добавления поля.
А так - ничего другого в голову не приходит. Очистка пользовательского кэша формы? и т.п.

[ice]

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

[kashperuk]

Ааа, ну что ж сразу не сказали, что иерархия. Но да, получается лечение такое же, как и обычно - просто синхронизация таблицы.

[MikeR]

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

[ice]

Цитата:

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

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

лучше бы автоматом синхронизировались все таблицы в иерархии, по типу инкрементной компиляции

[ice]

Все таки проблема не в синхронизации. Только что добавил поле в дочернюю таблицу, синхронизировал обе таблицы, добавил поле на форму. открываю форму через рабочую область, поле отображается как "не извлечено", открываю таблицу браузером таблиц, редактирую поле в нескольких записях, все сохранилось. открываю форму, картина все та же. открываю форму через АОТ, поле отобразилось правильно

ПС мне вот интересно, у меня у одного такая проблема или еще никто не пробовал добавлять поля в Ax2012?

[Logger]

Цитата:

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

Все таки проблема не в синхронизации. Только что добавил поле в дочернюю таблицу, синхронизировал обе таблицы, добавил поле на форму. открываю форму через рабочую область, поле отображается как "не извлечено", открываю таблицу браузером таблиц, редактирую поле в нескольких записях, все сохранилось. открываю форму, картина все та же. открываю форму через АОТ, поле отобразилось правильно

ПС мне вот интересно, у меня у одного такая проблема или еще никто не пробовал добавлять поля в Ax2012?

Привет. Мы поймали багу на обычной табличке (без наследования).
Наследование ни при чем.

Как воспроизводить :
1. Берем, создаем табличку (для определенности AAA).
2. Cоздаем в ней строковое поле TEST.
(Если кому-то лень, то можно импортировать прилагаемый XPO. Только тогда надо удалить в импортированной табличке поле TEST2 и перестартовать аос)
3. Синхронизируем табличку.
4. (опциональный пункт и на воспроизводимость бага не влияет) - настраиваем логирование SysDataBaseLog по табличке AAA
5. Включаем логирование всех SQL запросов (этот пункт опять же не влияет на воспроизводимость бага, но позволяет увидеть проблему со всей очевидностью)
6. Открываем обозреватель таблички. Создаем запись. На SQL уйдет запрос примерно такого вида :

Цитата:

Оператор SQL: (AAA) INSERT INTO AAA (TEST,MODIFIEDDATETIME,MODIFIEDBY,CREATEDDATETIME,CREATEDBY,RECVERSION,PARTITION,RECID) VALUES (?,?,?,?,?,?,?,?) [Идентификатор=105315, Использовано повторно=Нет]

7. Открываем еще примерно 5 штук обозревателей таблицы и в каждом создаем запись (достаточно и одного, но для надежности лучше 5. У меня получалось воспроизвести баг с одним дополнительно открытым обозревателем. Так что всего было 2 обозревателя открыто)
8. Создаем в табличке новое строковое поле TEST2.
9. Синхронизируемся.
10. Открываем обозреватель табличек. Создаем запись, заполняя какое-то значение для поля TEST2.
С большой вероятностью уйдет запрос такого вида

Цитата:

Оператор SQL: (AAA) INSERT INTO AAA (TEST,MODIFIEDDATETIME,MODIFIEDBY,CREATEDDATETIME,CREATEDBY,RECVERSION,PARTITION,RECID) VALUES (?,?,?,?,?,?,?,?) [Идентификатор=33086, Использовано повторно=Да]

т.е. в нем совсем не будет упомянуто поле TEST2 !!!

Если все же ушел корректный перечень полей на вставке, то можно открыть еще 1-2 обозревателя и повторить в нем действия п.10
Должен уйти кривой запрос на вставку в котором поле TEST2 не упомянуто.
Соответственно, в базе будет создана запись с пустым (дефолтным) значением.

Пробуем перехитрить аксапту.
Закрываем клиента.
Заходим снова.
Открываем обозреватель таблички AAA.
Все ок.
Создаем запись - тоже все ок. На вставку уходит оба поля (TEST и TEST2)

Все хорошо ?
Как бы не так!

Открываем еще один обозреватель таблицы.
Теперь внимательнее. С вероятностью примерно 10 % - в БД уйдет кривой запрос на выборку, без поля TEST2. Например такой :

Цитата:

Оператор SQL: (AAA) SELECT T1.TEST,T1.MODIFIEDDATETIME,T1.MODIFIEDBY,T1.CREATEDDATETIME,T1.CREATEDBY,T1.RECVERSION,T1.PARTITION,T1.RECID FROM AAA T1 WHERE (PARTITION=?) ORDER BY T1.RECID OPTION(FAST 19) [Идентификатор=33638, Использовано повторно=Да]

(в запросе нет поля TEST2)

При этом в обозревателе в столбце для TEST2 будет написано "Не извлечено" - как раз тот случай который ICE описал. Если попробовать наложить какой нибудь фильтр или отсортировать записи то с вероятностью 99 % уйдет запрос с полей TEST2 в перечне полей и все будет ок.

Далее. Создаем в новом обозревателе таблиц новую запись. Заполняем поля непустыми значениями и видим в логе запросов что с вероятностью 99 % в перечне полей на вставку нет поля TEST2.
Открываем еще один обозреватель таблиц - повторяем наши действия - то же самое.
С очень высокой вероятностью идет запрос

Цитата:

Оператор SQL: (AAA) INSERT INTO AAA (TEST,MODIFIEDDATETIME,MODIFIEDBY,CREATEDDATETIME,CREATEDBY,RECVERSION,PARTITION,RECID) VALUES (?,?,?,?,?,?,?,?) [Идентификатор=33086, Использовано повторно=Да]

вместо запроса

Цитата:

Оператор SQL: (AAA) INSERT INTO AAA (TEST,TEST2,MODIFIEDDATETIME,MODIFIEDBY,CREATEDDATETIME,CREATEDBY,RECVERSION,PARTITION,RECID) VALUES (?,?,?,?,?,?,?,?) [Идентификатор=XXXX, Использовано повторно=Да]

При этом после вставки обозреватель таблички отображает введенное нами значение в поле TEST2 как будто оно вставлено в табличку. Но реально в SQL оно имеет пустое, дефолтное значение. В этом легко убедиться если посмотреть в базу средствами SQL или в том же обозревателе перечитать запись. Если посмотреть историю изменения таблички (для этого мы и включали логирование SysDataBaseLog), то видно что там на вставке ядро думало что поле TEST2 существует в базе и мы его заполняем, т.е. в метод Application.logInsert() ядро прислало корректный перечень значений, а поломка идет где-то дальше - уже на этапе формирования SQL запроса.

В общем, складывается ощущение что в Аосе для каждой таблички есть пул объектов содержащий перечень ее полей (перечень курсоров ?) И при выполнении запроса ядро хватает первую попавшийся элемент из этого пула и использует для формирования запроса. Поэтому с некоторой вероятностью как для чтения так и для вставки запрос может получиться нормальным, а может содержать неверный набор полей. Почему то, когда я тестировал, то у меня вероятность воспроизведения глюка при вставке записи была на порядок выше чем при чтении. При этом во всех случаях когда в запроса было написано "Использовано повторно=Нет" - то глюка не было. А когда был глюк то для него было "Использовано повторно=Да"
Мое предположение про пул объектов это только догадка, основанная на наблюдениях за системой.
(Когда игрался с воспроизведениям бага и создавал еще и поле TEST3, удалось достичь смешной ситуации когда из под одной сессии было открыто 3 обозревателя таблички. У всех в гриде были видны и доступны все поля, а на вставку у первого обозревателя уходили поля TEST, TEST2, TEST3
у второго TEST, TEST2,
а у третьего только TEST. В общем полный расколбас был)
Отдельно обращаю внимание на то, что не только обозреватели таблиц переоткрывались, но сам клиент аксапты перестартовывался после добавления полей ! Причем пакость еще в том что первый обозреватель может нормально открыться и ты уже думаешь что все ок и все кеши прочистились. А открываешь второй, третий и там лезет баг.
------------------------------------------------


В чем основной вопрос поста:
1. Как лечить указанный баг ?

Мне пока удалось только перестартом АОСа. Но это очень неудобно в случае когда еще кто-то сидит и кодирует на аосе.
Да даже если никого нет на аосе - неудобно все закрывать ради перестарта аоса. (Ведь как обычно пишем - покодировали, сразу потестили немного - проверили все ли ок - и не хочется все закрывать и рестартовать аос - это неудобно)
Пробовал также (ничего не помогло):
а. делать синхронизацию.
б. сбрасывать кеши на клиенте и аосе
в. Стандартный финт compile node, refresh node, compile node, который успешно помогал прочищать кеш аоса в 2009-й - здесь не помогает.

Есть ли какой то способ прочистить пул объектов с перечнем полей, не перезагружая аос ?


2. Может быть баг уже исправлен в каком то очередном релизе и нужно просто поставить свежий билд ? Кто-нибудь в курсе, с какой версии исправлено ?
У нас версия ax 2009 R3 ( билд 6.3.2000.4755 Axapta 2012 R3 Cumulative Update 9+)


3. Как дальше жить ?

[Logger]

Цитата:

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

Привет. Мы поймали багу на обычной табличке (без наследования).
Наследование ни при чем....

Катастрофа.
Это оказывается вообще by design
https://msdn.microsoft.com/EN-US/library/aa882181.aspx

Цитата:

Restart the AOS after Adding Fields to Tables

When you insert data in a table during development, the SQL statement you use to insert the data is cached in the AOS. Next you might add a new field to the table and persist the change to the database. This causes the SQL statement in the cache to become stale, because the statement is not updated to include the new field. If you reuse the stale statement, the new field is ignored, or an error might occur.

To avoid this problem, restart the AOS after you persist table schema changes to the database. The cache is empty when the AOS restarts.

Интересно, как они сами-то программируют при этом ? А команда прикладных разработчиков им руки до сих пор не вырвала ?

[trud]

а у вас чистая R2 или CU1 ?

[ice]

скорее всего чистая R2
версия приложения 6.2.1000.156

[MikeR]

У меня работает изменением свойства источника данных OnlyFetchActive

       ,     , ,  ,    .  ,       ,           ,      ,      .

[gl00mie]

AX 2012 R2 CU7 (6.2.1000.4501), в настройках (Администрирование системы/Настройка/Лицензирование/Конфигурация лицензии) выключен конф. ключ Главная книга - дополнительно/Консолидация (LedgerAdvConsolidations), потому что на проекте не предполагалось использовать консолидацию. После этого были созданы компании (записи в CompanyInfo), затем на тестовой разноске журнала ГК получается ошибка:

Поле "IsConsolidationCompany" в таблице "CompanyInfo" не было явным образом выбрано.
(S)\Data Dictionary\Tables\CompanyInfo\Methods\isConsolidationCompany - line 17
(S)\Classes\LedgerJournalTransUpdate\checkConsolidation - line 35
(S)\Classes\LedgerJournalTransUpdate\check - line 17
(S)\Classes\LedgerJournalTransUpdateCust\check - line 84
(S)\Classes\LedgerJournalTransUpdate\ledgerVoucherCheck - line 77
(S)\Classes\LedgerJournalCheckPost\checkJournal - line 405
(S)\Classes\LedgerJournalCheckPost\run - line 144
(C)\Classes\LedgerJournalCheck\main - line 49
(C)\Classes\FormFunctionButtonControl\Clicked

Круто, стандартный код не был переделан под то, чтобы проверять включенность конфигурационного ключа или хотя бы то, что значение поля было-таки выбрано из базы. Включаю конфигурационный ключ, синхронизируюсь, проверяю - ошибка сохраняется, в обозревателе продолжаю видеть в значении поля "Не извлечено". Это оказалось вполне логично с учетом того, что поля, привязанные к включенному конфигурационному ключу, были добавлены со значением по умолчанию null

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

[Ivanhoe]

Мне казалось, что в 2012 при отключении ключей не "отключаются" поля в SQL, нет? Может быть, что у вас АОС просто не увидел изменения? Например, снимая какой-то ключ у поля обычно приходится кроме синхронизации / компиляции (в т.ч. CIL) еще и перезайти парочку раз, а в запущенных случаях еще и AOS перегрузить.

[gl00mie]

Точно, я неверно сформулировал исходную проблему: поля создались изначально при синхронизации в рамках контрольного списка установки со значением по умолчанию null, но когда создавались записи компаний, конфигурационный ключ LedgerAdvConsolidations уже был выключен, поэтому поля, связанные с консолидацией, не были заполнены значением по умолчанию для соответствующего базового типа (enum) и так и остались null. Проблем обнаружилось три:

• включение конфигурационного ключа не привело к заполнению связанных с ним полей в существующих записях значением по умолчанию для их базового типа в приложении
• ядро ожидает, что всегда получит значение поля, отличное от null, если оно явно указало поле в списке выборки select
• стандартный код, без проверки состояния конфигурационного ключа обращающийся к полям, привязанным к этому ключу, до включения ключа закономерно валился с ошибкой, потому что ядро даже не пыталось выбрать значения полей из базы, а после включения ключа валился с ошибкой, потому что ядро явно пыталось выбрать значения, но получало null и считало, что значения полей явно не были выбраны.

По сути, ошибка «Поле "%1" в таблице "%2" не было явным образом выбрано» в данном случае вводит в заблуждение, потому что путает понятия явного указания поля в select и получения null в качестве значения этого поля. Последнее может быть как следствием того, что поле не выбиралось, так и следствием того, что оно выбиралось, но в БД оно имеет значение null.

[Товарищ ♂uatr]

Добрый день!
Мой вопрос про DAX 2012 R2 и определенные поля в таблице:
Есть таблица с рядом полей, через обозреватель, все поля замечательно редактируются (соответственно в свойствах полей выставлен allowedit == true).
Однако, в гриде на форме доступна для редактирования только часть полей (форму всю облазил, везде allowedit && enabled == true).
Создал новую форму, создал грид ссылающийся на эту же таблицу и вижу ту же самую картину - редактировать поля возможно только на момент создания записи(в свойствах датасорса, как неудивительно, allowedit == true).
Что это такое?

Таблица не Valid Time State Table случайно?
Ну и с правами не игрались?

[Товарищ ♂uatr]

Цитата:

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

Таблица не Valid Time State Table случайно?
Ну и с правами не игрались?

Да, именно в этом дело.
Правда, с правами доступа обыгрался (в дополнение к роли системного администратора, создал роль содержащую привилегию на данную таблицу и в саму роль добавил доступ к форме "PastDataAccess" по умолчанию Delete) результата на форме не вижу.
Неверно роль настроил?