Репликация в будущем

[Akupaka]

Всем привет!
Кто-нить сталкивался с подобной проблемой, знает решение?..
Есть две реплики на серверах С1 и С2.
На С2 (по непонятным причинам) изменилось время на 14.12.09. С С2 на С1 произошла репликация базы с неправильным временем.
Соотв. в истории на С1 появилась запись "принято от С2 14.12.09".
Почистил историю на обоих серверах. После репликации запись восстановилась в том же виде!
Откуда он берет эту дату?..
В базе есть несколько документов, которые были изменены в эту дату. Репликатор берет дату из документов?..
Будет ли корректно поле $Revisions почистить?.. Исправит ли это ситуацию?

Заранее спасибо.

 

[hosm]

а updall здесь не поможет?
P.S. Он вроде исправляет работу с доками, у которых дата "too far in future".
И ты уверен, что здесь не значение Modified влияет?

 

[Akupaka]

я доки модифицировал, последняя дата у них "нормальная"...
хм... updall надо посмотреть...

 

[hosm]

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

 

[Akupaka]

Короче, возникла снова эта ситуация, удалось применить updall. Но че-то проблема не ушла.
Запускал fixup -F -O - матюгается time is too far in the future.
Потом запустил updall -R - матюгается time is too far in the future.
Потом запустил compact -c -D - матюгается time is too far in the future.
Т.е. после updall ошибка осталась.

Есть идеи как избавиться?

 

[Мыш]

Есть идеи как избавиться?

Реплику пересоздать с нуля?

 

[Akupaka]

Реплику пересоздать с нуля?

Если бы реплику... одну... тут полетело куча системных БД, проект из десятка баз... и админ с "той" стороны не очень опытный, приходится тратить много времени на консультации по телефону...
Короче, реплики я на "десерт" оставил. Грустно, блин...

 

[Akupaka]

Кто-нить знает можно ли сбросить свойство БД Activity Modified в нужное значение?

 

[Мыш]

Если бы реплику... одну... тут полетело куча системных БД, проект из десятка баз...

А если там программно создать локальные реплики? Куда-нить вне директории DATA? А потом админ их перепишет поверх... Как вариант - создать КОПИИ, потом заменить ReplicaID (где-то было описано, как это делать).

 

[Akupaka]

А если там программно создать локальные реплики?

Да, идея написать такую утилиту бродит в голове. Но куча недомино задач и лень делают свое гадкое дело

К стати, интересно, что мне удалось понять, извините, если баян, я для себя только сейчас понял.
Свойство БД Activity Modified - это гадкое свойство, которое устанавливает дату модификации документа в будущем даже, если время на сервере и клиенте верно.
Т.е. достаточно чтобы единожды это свойство прописалось в будущем и все новые (а возможно и изменяемые старые) документы получают датой модификации именно значение этого свойства!

Еще пробовал выгрузить БД в dxl и загрузить. Так таким способом можно вылечить эту проблему, но изменить лишь это свойство БД не удалось. Т.е. необходимо выгружать полностью БД и загружать полностью. Но использовать этот способ не захотел, т.к. не удалось провести качественные проверки и сопоставить данные выгруженной и загруженной БД. Но свойство БД можно таким образом сбросить на текущее. Поэтому в некоторых случаях вполне применимо.