Галактика в вопросах и ответах

При включенной журнализации часто (1-2 раза в день) возникает ошибка №5 "Дублированное значение при уникальном ключе в таблице \\GalSrv\Data\D_dict\Journal.adf". Кто-нибудь знает как это победить?

Все уникальные ключи в журнале содержат Nrec, отсюда можно сделать вывод, что ошибка состоит именно в их генерации.
Способов изменить методику генерации ключей очень немного, можно попробовать установить параметр RandomSurrKeys в секции DataBase cfg-файла, если он установлен в True, то можно исключить журнал с помощью параметра RandomSurrKeysExcludeList этой же секции. Кстати, по умолчанию, сразу после установки, там стоят две таблицы x$journal; ServerConflicts, скорее всего - они оказались стерты из этого параметра в результате каких-либо экспериментов.

Я думаю RabdomSurrKeys желательно обязательно прописать в [DataBase]

Только вот RandomSurrKeys работает только на Pervasive ...

и в журнале не только индекс по NRec уникален ...

TABLECODE+TABLENREC+NREC
STATUS+NREC
TRANSNO+NREC

тоже уникальные

Живем 5-й год с последовательной генерацией суррогатных ключей и не маемся

Только что попробовал включить RandomSurrKeysExcludeList=X$JOURNAL при включенной опции RandomSurrKeys=On и знаете, не помогло Ошибки стали повторятся чаще.

2 Туманов О.В. Там было сказано, что все уникальные индексы содержат Nrec , а отсюда можно сделать вывод что если возникает такая ошика, то повторяется и Nrec в том числе. По постановке вопроса и так было ясно, что БД на Pervasive(\\GalSrv\Data\D_dict\Journal.adf).......

А если попробовать вообще сделать RandomSurrKeys=Off и не маятся?

А табличку то отлечили/удалили? Ибо раз дубликаты уже есть то никуда они не денутся...

Дублированное значение появляется только в journal.adf в других таблицах их нет, уже несколько раз лечили подозрительные таблички. Такая же ситуация возникает при включенном Корпо-обмене.

Кстати, RandomSurrKeys=Off тоже никак не решает эту проблему. Такая же ошибка в journal.adf.

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

Jornal можно и грохнуть (сохранив его предварительно) - проверь так.

При включенной корпе его можно грохать только сразу после сеанса репликации, когда все отправилось или грохнуть частично, оставив записи у которых статус стоит "Не рассылалась" x$Journal.Status=0

Так и делал, пока не надоело, а сейчас хочется до конца разобраться почему такая ошибка возникает. Не очень хорошо постоянно следить за работой системы. Иногда в отпуск хочется или еще что-нибудь. Гроханье журнала помогает временно, через 3-4 часа такая проблема возникает снова

А как появление проблемы по времени ложится на сеансы репликации?

Репликация раз в сутки в 23-00 ошибки возникают днем на серверной БД, клиентская БД только в режиме просмотра, поэтому сказать о проблеме там не могу.