Atl_Owner

[AKalder]

Добрый день.

Подскажите, пожалуйста, возможно ли программно обойти модификацию данного поля (Atl_Owner) в таблицах Галактики и вместо владельца учетной записи сажать виртуального пользователя ? Это поле есть в каждой таблице,поэтому и рационально было бы его задействовать в несколько иных целях.
Мысль следующая, при автоматической обработке импортируемых данных, запущенным под одним из пользователей, записи в различных таблицах нужны под другими виртуальными пользователями, для облегчения дальнейшего использования импортированных данных.

[Алексей]

а если создать запись, а потом уже модифицировать, записав туда нужное значение?

[edward_K]

Если у вас MSSQL или OrACLE вы легко можете подправить(а лучше добавить) соотв. тригер. Есть одно но- если вы подправите то при проверке целостности базы тригер может вернуться к первоначальному значению - поэтому хотя бы отдокументируйте. При добавлении можно написать скрипт на генерацию тригера в каждой словарной(!) таблице - то есть на то, что сидит в x$files, на служебные незачем.

[AKalder]

а если создать запись, а потом уже модифицировать, записав туда нужное значение?

У меня PervasiveSQL, не дает обмануть из VIP-а.

[Алексей]

ну, может тогда использовать другую таблицу, атрибуты?

[AKalder]

ну, может тогда использовать другую таблицу, атрибуты?

Не вариант, Алексей. Смысла нет.

Сейчас поясню. Предположим есть такой пользователь - Астор. Он время от времени запускает свой интерфейс при работе которого в зависимости от входных данных шлепает в Галактике различные документы, с привязкой к одному из виртуальных пользователей (Любава-1, Любава-2 и т.д.).
Но поставщик данных любит время от времени перепроводить данную операцию в Галактике за тот же период по причине исправления ошибок.
Вот и подумал, раз в каждой таблице Галактики есть Atl_Owner, то с его то помощью точно можно было бы в короткое время произвести нужную выборку документов за период для модификации или удаления.
Пока для тех же целей использую дескриптор пользователя, но данное поле есть не во всех связанных таблицах.
Так что в принципе вопрос можно закрыть, так как если нет простого способа обойти заковырку, то копать глубже смысла нет.

P.S. В идеале в каждой таблице нужно дополнительно всего два поля. Виртуальный пользователь и дата. Тогда перепроведение будет сводиться к удалению всего за период и созданию нового. Оставив только разборки с перемещениями между Любавами так как приходы и расходы формируются раздельно и разнесены во времени.

[Den]

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