|
16.01.2017, 18:18 | #1 |
Участник
|
Цитата:
Сообщение от 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, Использовано повторно=Нет]
8. Создаем в табличке новое строковое поле TEST2. 9. Синхронизируемся. 10. Открываем обозреватель табличек. Создаем запись, заполняя какое-то значение для поля TEST2. С большой вероятностью уйдет запрос такого вида Цитата:
Оператор SQL: (AAA) INSERT INTO AAA (TEST,MODIFIEDDATETIME,MODIFIEDBY,CREATEDDATETIME,CREATEDBY,RECVERSION,PARTITION,RECID) VALUES (?,?,?,?,?,?,?,?) [Идентификатор=33086, Использовано повторно=Да]
Если все же ушел корректный перечень полей на вставке, то можно открыть еще 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 будет написано "Не извлечено" - как раз тот случай который 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, Использовано повторно=Да]
В общем, складывается ощущение что в Аосе для каждой таблички есть пул объектов содержащий перечень ее полей (перечень курсоров ?) И при выполнении запроса ядро хватает первую попавшийся элемент из этого пула и использует для формирования запроса. Поэтому с некоторой вероятностью как для чтения так и для вставки запрос может получиться нормальным, а может содержать неверный набор полей. Почему то, когда я тестировал, то у меня вероятность воспроизведения глюка при вставке записи была на порядок выше чем при чтении. При этом во всех случаях когда в запроса было написано "Использовано повторно=Нет" - то глюка не было. А когда был глюк то для него было "Использовано повторно=Да" Мое предположение про пул объектов это только догадка, основанная на наблюдениях за системой. (Когда игрался с воспроизведениям бага и создавал еще и поле 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; 16.01.2017 в 18:39. Причина: опечатки |
|
25.01.2017, 19:02 | #2 |
Участник
|
Цитата:
Это оказывается вообще 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 (2), gl00mie (5). |
Теги |
ax2012, command line parameters, internal, nocursorreuse, баг, не извлечено, параметры командной строки, поле не извлечено |
|
|