Список таблиц для журнализации

[gavrilyukmg]

Скажите пожалуйста, почему таблица 16030 (ZAR_UZERS) не видна в списке таблиц для журнализации?

[stix]

скорей всего, это связано с ее описанием:

Код: Выделить всё

Create table D_NASTR.ZAR_USER "Настройка пользователя"
  Using "Zar_User.dat"
  With Table_Code = 16030
  With replace
  (
    NREC       : Comp         "Номер записи",
<..>
  )
  with index
  (
    ZAR_USER01 = OWNNAME(Unique)
  );

отсутствует атрибут journal

[cruger]

Потому что она не объявлена как журналируемая.

[m0p3e]

Потому как у нее не стоит признак "Таблица может журналироваться".
На свой страх и риск можно добавить:
update x$files Where (('ZAR_USER' == x$files.xf$name )) set x$files.xf$flags := ( x$files.xf$flags + 0800h );

[gavrilyukmg]

Почему спрашиваю - не могу отследить, кто внес изменения. Админов 10 человек. А править ее должны 5. Крыжики исчезают и появляются - знаю, что не я их поставила. А надо бы знать, кто наследил.

[m0p3e]

Битом промахнулся... :)

update x$files Where (('ZAR_USER' == x$files.xf$name )) set x$files.xf$flags := ( x$files.xf$flags + 0400h );

[gavrilyukmg]

спасибо.

Интересно, из каких соображений она не журналируется?

Забыли или смысл в этом какой-то?

[cruger]

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

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

[Seybukan]

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

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

[gavrilyukmg]

Должна журналироваться - это настройка прав доступа к подразделениям по ЗП.
А это конфиденциальная информация. И я не могу сказать , почему мои настройки последнее время меняются. Это приводит к ошибкам. Люди формируют отчеты по всему заводу, а итоги не идут.
Начинаем смотреть - там стоит крыж, хотя он был убран.


Разборки замучили.

А почему она должна работать некорректно?

[m0p3e]

Посмотрел подробнее. На оракле таблицу после апдейта можно будет добавить в журнализацию, но журналироваться она не будет, т.к. отсутствует соответствующий триггер. Видимо такая же ситуация и на MSSQL. Подозреваю, что на первасиве для журналирования будет этого достаточно (Там другая схема журналирования).
Если очень критично, то (Оракл, Сиквел) можно сделать полную докомпиляцию на тесторой БД (дропнуть и создать заново с ключем journal). После этого перенести триггер на журналирование к таблице ZAR_USER и таблицу J$16030 в рабочую БД.
Некорректность вижу только одну - ругань утилиты проверки БД.

[gavrilyukmg]

Дропнуть - таблица останется, только пустая. Она не удалится. Я по этой команде очищаю обычно таблицы.

Если можно подробно:)

[gavrilyukmg]

И у нас Оракл

[gavrilyukmg]

Нет, я ошиблась - это про truncate

[vadim]

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

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