AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 23.03.2010, 21:20   #1  
wojzeh is offline
wojzeh
Участник
Аватар для wojzeh
Соотечественники
 
479 / 226 (8) ++++++
Регистрация: 27.04.2006
Адрес: Montreal
Переписались значения поле Поставщик во всех заказах на закупку
Второй уже раз произошло событие, сравнимое с пролётом кометы Галлея около Земли: после того, как один из пользователей сменил поставщика во вновь созданном заказе на закупку, он почему-то лихо проставился и во всех (!!!) остальных существующих заказах.

Небольшой эксперимент показал, что такой же эффект наблюдался при изменении значения ключевого поля кода поставщика (VendTable.AccountNum). Но к сожалению эффект неустойчив.

Несмотря на изменение всех значений поля PurchTable.OrderNum и PurchTable.InvoiceNum, значения, например, PurchTable.Name на этой таблице не изменились.

Что интересно, несмотря на то, что данный поставщик фигурирует лишь в трёх документах, и в первый и второй раз, именно его значение прописалось во всех заказы.

Никаких "подозрительных" изменений стандартных методов на этих двух таблицах нет.

Какие будут соображения?
Миниатюры
Нажмите на изображение для увеличения
Название: ScreenHunter_121 Mar. 23 14.17.gif
Просмотров: 172
Размер:	23.9 Кб
ID:	5657  
__________________
Felix nihil admirari
-----------------------------------------------------------------------------------------------
AX2012

Последний раз редактировалось wojzeh; 23.03.2010 в 21:25.
Старый 23.03.2010, 21:57   #2  
TasmanianDevil is offline
TasmanianDevil
Мрачный тип
Аватар для TasmanianDevil
Злыдни
 
780 / 307 (12) ++++++
Регистрация: 24.01.2005
Адрес: Томск
Бред какой-то ...
Либо "веселый" триггер живет на серваке, либо таки что-то кастомизировано в таком же "веселом" ключе - кроме таблиц (renamePrimaryKey() переопределен в VendTable ? ), которые вроде как вне подозрений, форму и ее датасорсы с полями инспектировали ? Там ничего в методах перегруженного/дописанного нет ?

P.S. Никого в последнее время не увольняли по-жесткому, кто мог такое оставить в наследство ? ;-)
__________________
Axapta will die, MorphX stay forever
Старый 23.03.2010, 22:09   #3  
ashu is offline
ashu
MCTS
NETI
MCBMSS
 
240 / 75 (3) ++++
Регистрация: 24.06.2008
а случайно компиляция таблиц не производилась?
Старый 23.03.2010, 22:22   #4  
wojzeh is offline
wojzeh
Участник
Аватар для wojzeh
Соотечественники
 
479 / 226 (8) ++++++
Регистрация: 27.04.2006
Адрес: Montreal
автоматическое открытие в методе run формы VendTable и PurchTable может влиять?

"веселый триггер" - отличное название для кабака! - мне два по сто "дебаггера" и кружку "чёрной транзакции"!
Миниатюры
Нажмите на изображение для увеличения
Название: ScreenHunter_125 Mar. 23 15.17.gif
Просмотров: 66
Размер:	34.7 Кб
ID:	5658  
__________________
Felix nihil admirari
-----------------------------------------------------------------------------------------------
AX2012
Старый 23.03.2010, 22:23   #5  
wojzeh is offline
wojzeh
Участник
Аватар для wojzeh
Соотечественники
 
479 / 226 (8) ++++++
Регистрация: 27.04.2006
Адрес: Montreal
поясни, как это?
__________________
Felix nihil admirari
-----------------------------------------------------------------------------------------------
AX2012
Старый 24.03.2010, 07:18   #6  
TasmanianDevil is offline
TasmanianDevil
Мрачный тип
Аватар для TasmanianDevil
Злыдни
 
780 / 307 (12) ++++++
Регистрация: 24.01.2005
Адрес: Томск
Часом Ваш сотрудник не этим воспользовался ?
__________________
Axapta will die, MorphX stay forever
Старый 24.03.2010, 09:03   #7  
raz is offline
raz
NavAx
Аватар для raz
NavAx Club
Лучший по профессии 2014
Лучший по профессии 2009
 
1,361 / 877 (32) +++++++
Регистрация: 22.07.2003
Адрес: МО
Статус "Отменено" в строках заказа
За это сообщение автора поблагодарили: wojzeh (1).
Старый 24.03.2010, 09:09   #8  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,550 / 5050 (176) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Цитата:
Сообщение от wojzeh Посмотреть сообщение
Что интересно, несмотря на то, что данный поставщик фигурирует лишь в трёх документах, и в первый и второй раз, именно его значение прописалось во всех заказы.
Никаких "подозрительных" изменений стандартных методов на этих двух таблицах нет.
А какие-нить update_recordset'ы в кастомизациях используются? Или временные таблицы на базе PurchTable? С временными таблицами на базе постоянных бывают иногда "недоразумения".

PS. Коллега накатил проект с очень полезной модификацией: возможность настройки того, писать ли в SysDatabaseLog еще и стек вызовов. В подобных "странных" случаях эта модификация не раз уже помогала выйти на соответствующий код.

Последний раз редактировалось gl00mie; 24.03.2010 в 09:13.
За это сообщение автора поблагодарили: wojzeh (1).
Старый 24.03.2010, 10:53   #9  
vanokh is offline
vanokh
Участник
 
108 / 63 (3) ++++
Регистрация: 23.10.2008
Был аналогичный случай, когда пользователь переименовал Клиента - в результате переименовались поля в InventTrans и некоторых настроечных таблицах (например, профили разноски), заказы не были изменены. Во время переименования все намертво подвисло, перегружали сервер БД - видимо, поэтому никаких следов переименования в логе не осталось

Воспроизвести не удалось... Все что удалось выяснить - это почти наверняка переименование первичного ключа, делается стандартным методом таблицы renamePrimaryKey, который нигде не был перекрыт.

Все испорченные данные восстанавливали из бэкапа...

З.Ы. Ах, да! Пробовали переименовать с включенным профайлером - очень интересные запросы идут... По идее должны переименовываться поля во всех (!) таблицах с типом CustVendAC, но естественно с условием по старому значению.

Последний раз редактировалось vanokh; 24.03.2010 в 11:05.
Старый 24.03.2010, 15:55   #10  
wojzeh is offline
wojzeh
Участник
Аватар для wojzeh
Соотечественники
 
479 / 226 (8) ++++++
Регистрация: 27.04.2006
Адрес: Montreal
Цитата:
Сообщение от TasmanianDevil Посмотреть сообщение
Часом Ваш сотрудник не этим воспользовался ?
ха-ха-ха!!! отличное замечание!

проблема в том, что я даже не могу наверняка узнать, кто и что именно сделал в этой ситуации.
__________________
Felix nihil admirari
-----------------------------------------------------------------------------------------------
AX2012
Старый 24.03.2010, 16:10   #11  
wojzeh is offline
wojzeh
Участник
Аватар для wojzeh
Соотечественники
 
479 / 226 (8) ++++++
Регистрация: 27.04.2006
Адрес: Montreal
Цитата:
да, я уже тоже задумался о включении лога на определённых таблицах. но тут есть два момента:

1) непонятна природа происхождения этого явления (какие именно таблицы отслеживать);

2) как повлияет логгирование на производительность рабочей базы.

что можете по опыту сказать-посоветовать?
__________________
Felix nihil admirari
-----------------------------------------------------------------------------------------------
AX2012
Старый 24.03.2010, 16:11   #12  
wojzeh is offline
wojzeh
Участник
Аватар для wojzeh
Соотечественники
 
479 / 226 (8) ++++++
Регистрация: 27.04.2006
Адрес: Montreal
Цитата:
Сообщение от gl00mie Посмотреть сообщение
А какие-нить update_recordset'ы в кастомизациях используются? Или временные таблицы на базе PurchTable? С временными таблицами на базе постоянных бывают иногда "недоразумения".

PS. Коллега накатил проект с очень полезной модификацией: возможность настройки того, писать ли в SysDatabaseLog еще и стек вызовов. В подобных "странных" случаях эта модификация не раз уже помогала выйти на соответствующий код.
да, я уже ставлю его на отладочную базу. сейчас посмотрю, как работает.
__________________
Felix nihil admirari
-----------------------------------------------------------------------------------------------
AX2012
Старый 24.03.2010, 16:15   #13  
wojzeh is offline
wojzeh
Участник
Аватар для wojzeh
Соотечественники
 
479 / 226 (8) ++++++
Регистрация: 27.04.2006
Адрес: Montreal
Цитата:
Сообщение от vanokh Посмотреть сообщение
Был аналогичный случай, когда пользователь переименовал Клиента ...
очень похоже на мою ситуацию. так что же выходит, что это какой-то невоспроизводимый баг аксапты?

что-то мне это совсем не нравится... если такая "блуждающая" пуля может прибить многолетнюю работу многих людей, такая система ненадёжна.

закрыть функциональность переименования первичного ключа?
__________________
Felix nihil admirari
-----------------------------------------------------------------------------------------------
AX2012
Старый 12.05.2010, 10:06   #14  
vanokh is offline
vanokh
Участник
 
108 / 63 (3) ++++
Регистрация: 23.10.2008
В очередной раз повторилось - после переименования Клиента все (!) складские проводки переименовались во всех компаниях... Уже известно, что это переименование первичного ключа, но всплывает изредка и не воспроизводится. Аудит не помогает, поскольку показывает только вставку и изменение - переименование первичного ключа видимо идет в обход аудита. По аудиту можно только косвенно выяснить время - обычно изменяют и полное наименование.

Воистину баг аксапты... Может кто видел что-нибудь подобное в хотфиксах-роллапах?
Старый 12.05.2010, 10:12   #15  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,136 / 1545 (58) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от vanokh Посмотреть сообщение
Аудит не помогает, поскольку показывает только вставку и изменение - переименование первичного ключа видимо идет в обход аудита.
В настройка журнала базы данных есть специальный тип логируемых событий - "Переименование первичного ключа"
Старый 13.05.2010, 02:58   #16  
vanokh is offline
vanokh
Участник
 
108 / 63 (3) ++++
Регистрация: 23.10.2008
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
В настройка журнала базы данных есть специальный тип логируемых событий - "Переименование первичного ключа"
Хм, я думал у нас на него настроен аудит - оказывается нет... Поставим.

Пробовал создавать некорректные условия запуска переименования, максимум что удалось - это замена всех пустых ссылок на таблицу клиентов переименованным значением. Алгоритм следующий:
1. создать запись в таблице Клиенты
2. ввести Счет клиента
3. сохранить (запись не сохраняется, требует ввести адрес)
4. теперь появляется Переименовать в Паспорте записи
5. переименовать

Аудит показывает изменение 0 -> введенное значение.

Результат - во всех таблицах, где есть ссылка на таблица Клиенты и ссылка пустая, она заменится введенным значением (например, пустой Счет на во всех клиентах, Счет и Корр.счет в Наименованиях журналов ГК). Но это все равно не объясняет почему могут заменится все (!) значения в таблице...
За это сообщение автора поблагодарили: wojzeh (1).
Теги
renameprimarykey

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
сопоставление оплат клиента, переносов сальдо-поле накладная в общем журнале? Aquarius DAX: Функционал 3 28.01.2009 12:51
Автоматическая генерация значения в поле CreatedDate Eldar9x DAX: Программирование 3 06.08.2008 13:10
Поле "Оплатить до" в строке общего журнала longson DAX: Функционал 7 29.03.2008 14:38
Запрос. Отрицание значения при добавлении range'а на поле! IvanS DAX: Программирование 3 11.10.2006 09:41
Перебор всех таблиц, имеющих поле определенного типа AKIS-Falcon DAX: Программирование 8 11.02.2005 17:07
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 00:10.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.