Синхронизация:Алгоритм действий если не работает синхронизация

Порядок действий

На стороне клиента

• Поискать запись по d$uuid в g$distribute в первой, серверной и второй базах, чтобы определить между какими базами проблема.

select * from g$distribute g where g.uuid="..."

• Посмотреть когда были последние данные, которые пришли по синхронизации:

select * from g$distribute g order by  g.serverpacket desc

• Если запись не ушла из первой базы в серверную, то сравните поле packet, а если она из серверной не дошла до второй базы, то сравните поле serverpacket.
• Проверяем, что на странице [http://192.168.67.30/sinhro/] данный профиль не светится с флагом -1, иначе ошибка на сервере.
• Проверить, что dt клиент включен.
• url адрес который прописан в клиенте, открывается в браузере и выдает no input data
  • если не работает, проверить, что на сервере включен wamp.
  • иначе если URL начинается с 10, проверить, что поднят open vpn.
• dt клиент не выдает ошибок при скачивании.
• dt клиент что-то скачивет, пишется объем траффика.
• если процесс скачивания идет очень долго, запустить dt клиент с ключом +detail и посмотреть на каких запросах тормозит.
• если проблема с таблицей по старой синхронизации, взять максимальное значение поля packet по этой таблице по этому профилю на сервере:

 select max(packet) from :table where g$profile=:profle

и подставить его в генератор поля packet этой таблицы в клиентской базе:

 GEN_%TABLE%_PACKET

• проапдейтить необходимые записи.
• Ошибка "Incomplete Zip File", нужно проверить, что антивирус не блокирует обмен.

На сервере

• сервер доступен
• wamp включен
• служба очереди работает
• Поискать запись по d$uuid в g$distribute в первой, серверной и второй базах, чтобы определить между какими базами проблема.

select * from g$distribute g where g.uuid="..."

• Посмотреть когда были последние данные, которые пришли по синхронизации:

select * from g$distribute g where g.from_profile_id=:profile_id order by g.serverpacket desc

• в таблице docs есть свежие данные

select * from docs d where d.g$profile_id=:profile_id order by d.commitdate desc

• в таблице g$queue есть свежие данные:

select * from g$queue q where q.profile_id=:profile_id order by q.insertdt desc

Посмотрите на поле endflag: если там -1, значит ошибка.

• профиль прописан в g$profiles, status=0, dbsecurekey not null, остальные колонки как у других подобных профилей.
• в таблице G$DISTRIBUTE_VECTORS есть строчка с tablename нужной таблицы, где to_profile_id либо 0, либо номер базы, куда данные должны уйти.
• в таблице G$DISTRIBUTE_X_TABLES по данному профилю настройки такие же как и у других профилей и там верно указано какой таблице на сервере соответствует таблица на клиенте.

 select * from docs order by docdate desc

• если есть таблица g$queue, смотрим когда были последние пакеты и есть ли по ним ошибки.

 select * from g$queue q where q.profile_id=:profile_id

Частые вопросы

Нужно чтобы закрытая аптека не висела бы на sinhro но чтобы данные по ней отображались в своднике

Поставить dbsecurekey в таблицы g$profiles в null.

На sinhro пишется ошибка загрузки пакета и дата очень старая а по docs дата недавняя

На sinhro берется дата по последнему пакету таблицы g$queue, но из этой таблицы очищаются данные по положительным пакетам старше 3х дней. Поэтому, если последние 3 дня вообще не было синхронизации, то из таблицы сотрутся все данные по неошибочным пакетам и самой последней строчкой будет - самый последний ошибочный пакет. Поэтому, если пишется "ошибка загрузки пакета", но дата старше 3х дней, то это совсем не значит, что ошибка при загрузке на сервер.

Частые ошибки

Column unknown

Ошибка, возникающая на сервере. Означает, что у клиента в синхронизируемой таблице есть колонка, которой нет в этой таблице на серверной базе. Нужно либо добавить данную колонку на сервере, либо если она не нужна, или она есть не во всех клиентских базах, то добавить ее в список XFIELDS(xfields, xfields0, xfields1) в declare.php.

Violation of PRIMARY or UNIQUE KEY constraint

Ошибка, возникающая когда на момент вставки записи в таблицу, в ней уже есть строчка с таким же d$uuid, но с другим сочетанием id и g$profile_id. Нужно либо перегенерировать d$uuid у той строчки, которая уже есть, либо удалить запись, у которой совпадают id и g$profile_id.

Foreign key... At trigger DOCS_TREB_BI

Cначала попробуйте удалить старые накладные требования (сделав бэкап).

delete from doc_detail_active_treb ddat where ddat.insertdt <= current_date-7;

delete from docs_treb dt where dt.insertdt <= current_date-7;

Проверьте в таблицы docs нет ли документов с rguid той записи, на которую ругается. Если такой документ уже есть, то измените ему rguid.

update docs d set d.rguid=replace(UUID_TO_CHAR( GEN_UUID()),'-','') where d.rguid=:rguid;

Multiple rows... PR_SETPARTREALQUANT... DOC_DETAIL_AI_WB

Ошибка на сервере. Возможно в таблице warebase_g две строчки с part_id той записи, на которую ругается синхронизация. Удалите одну из них.

Что можно удалить если синхронизация много весит?

• В папке queue можно чистить все кроме последних 2х дней.
• В папке users можно чистить все.

Querypackets2013 Не найдена запись

Ошибка на клиенте, говорит о том, что на сервере в g$distribute запись есть, а в соответствующей таблице на сервере такой записи нет. Возможны два случая:

• Данную запись ктото случайно удалил. В этом случае нужно посмотреть на сервере с какого профиля она пришла (поле from_profile_id в g$distribute), подключиться к этой базе (также можно поискать в других сводных базах), найти эту запись, проапдейтить. В результате она должна придти на сервер и синхронизация снова пойдет.
• Данной записи нигде нет. Возможно она очень старая и поэтому ее удалили специально. Вопрос: почему наша база пытается ее скачать? Возможно в нашей базе сбилось поле serverpacket, точнее ктото неправильно почистил g$distribute, и теперь эта база пытается скачать вообще все с нуля. Надо проверить: это новая база? Нужно определить актуальность данных проблемной базы. Выполняем запрос на сервере:

select * from g$distribute where from_profile_id=:profile_id order by serverpacket desc

Проверяем максимальное значение serverpacket в проблемной базе:

select max(g.serverpacket) from g$distribute g;

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