Переписались значения поле Поставщик во всех заказах на закупку

[wojzeh]

Второй уже раз произошло событие, сравнимое с пролётом кометы Галлея около Земли: после того, как один из пользователей сменил поставщика во вновь созданном заказе на закупку, он почему-то лихо проставился и во всех (!!!) остальных существующих заказах.

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

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

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

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

Какие будут соображения?

[TasmanianDevil]

Бред какой-то ...
Либо "веселый" триггер живет на серваке, либо таки что-то кастомизировано в таком же "веселом" ключе - кроме таблиц (renamePrimaryKey() переопределен в VendTable ? ), которые вроде как вне подозрений, форму и ее датасорсы с полями инспектировали ? Там ничего в методах перегруженного/дописанного нет ?

P.S. Никого в последнее время не увольняли по-жесткому, кто мог такое оставить в наследство ? ;-)

[ashu]

а случайно компиляция таблиц не производилась?

[wojzeh]

автоматическое открытие в методе run формы VendTable и PurchTable может влиять?

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

[wojzeh]

поясни, как это?

[TasmanianDevil]

Часом Ваш сотрудник не этим воспользовался ?

[raz]

Статус "Отменено" в строках заказа

[gl00mie]

Цитата:

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

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

А какие-нить update_recordset'ы в кастомизациях используются? Или временные таблицы на базе PurchTable? С временными таблицами на базе постоянных бывают иногда "недоразумения".

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

[vanokh]

Был аналогичный случай, когда пользователь переименовал Клиента - в результате переименовались поля в InventTrans и некоторых настроечных таблицах (например, профили разноски), заказы не были изменены. Во время переименования все намертво подвисло, перегружали сервер БД - видимо, поэтому никаких следов переименования в логе не осталось

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

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

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

[wojzeh]

Цитата:

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

Часом Ваш сотрудник не этим воспользовался ?

ха-ха-ха!!! отличное замечание!

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

[wojzeh]

Цитата:

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

Статус "Отменено" в строках заказа

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

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

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

что можете по опыту сказать-посоветовать?

[wojzeh]

Цитата:

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

А какие-нить update_recordset'ы в кастомизациях используются? Или временные таблицы на базе PurchTable? С временными таблицами на базе постоянных бывают иногда "недоразумения".

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

да, я уже ставлю его на отладочную базу. сейчас посмотрю, как работает.

[wojzeh]

Цитата:

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

Был аналогичный случай, когда пользователь переименовал Клиента ...

очень похоже на мою ситуацию. так что же выходит, что это какой-то невоспроизводимый баг аксапты?

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

закрыть функциональность переименования первичного ключа?

[vanokh]

В очередной раз повторилось - после переименования Клиента все (!) складские проводки переименовались во всех компаниях... Уже известно, что это переименование первичного ключа, но всплывает изредка и не воспроизводится. Аудит не помогает, поскольку показывает только вставку и изменение - переименование первичного ключа видимо идет в обход аудита. По аудиту можно только косвенно выяснить время - обычно изменяют и полное наименование.

Воистину баг аксапты... Может кто видел что-нибудь подобное в хотфиксах-роллапах?

[S.Kuskov]

Цитата:

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

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

В настройка журнала базы данных есть специальный тип логируемых событий - "Переименование первичного ключа"

[vanokh]

Цитата:

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

В настройка журнала базы данных есть специальный тип логируемых событий - "Переименование первичного ключа"

Хм, я думал у нас на него настроен аудит - оказывается нет... Поставим.

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

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

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