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

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

==На стороне клиента==
* Поискать запись по d$uuid в g$distribute в первой, серверной и второй базах, чтобы определить между какими базами проблема.
* Если запись не ушла из первой базы в серверную, то сравните поле packet, а если она из серверной не дошла до второй базы, то сравните поле serverpacket.
* Проверяем, что на странице [[http://192.168.67.30/sinhro/| http://192.168.67.30/sinhro/]] данный профиль не светится с флагом -1, иначе ошибка на сервере.
* Проверить, что dt клиент включен. 
* url адрес который прописан в клиенте, открывается в браузере и выдает '''no input data'''
** если не работает, проверить, что на сервере включен wamp. 
** иначе если URL начинается с 10, проверить, что поднят open vpn.
* dt клиент не выдает ошибок при скачивании. 
* dt клиент что-то скачивет, пишется объем траффика. 
* если процесс скачивания идет '''очень долго''', запустить dt клиент с ключом +detail и посмотреть на каких запросах тормозит.
* если проблема с таблицей по старой синхронизации, взять максимальное значение поля '''packet''' по этой таблице по этому профилю '''на сервере''':
<pre>
 select max(packet) from :table where g$profile=:profle
</pre>
и подставить его в генератор поля '''packet''' этой таблицы '''в клиентской базе''':
<pre>
 GEN_%TABLE%_PACKET
</pre>
* проапдейтить необходимые записи.
* Ошибка "Incomplete Zip File", нужно проверить, что антивирус не блокирует обмен.

==На сервере==
* сервер доступен
* wamp включен 
* служба очереди работает 
* в таблице '''docs''' есть свежие данные 
* в таблице '''g$queue''' есть свежие данные 
* профиль прописан в '''g$profiles''', '''status=0''', '''dbsecurekey not null''', остальные колонки как у других '''подобных''' профилей. 
* в таблице '''G$DISTRIBUTE_VECTORS''' есть строчка с '''tablename''' нужной таблицы, где '''to_profile_id''' либо '''0''', либо '''номер базы''', куда данные должны уйти.
* в таблице '''G$DISTRIBUTE_X_TABLES''' по данному профилю настройки такие же как и у других профилей и там верно указано какой таблице на сервере соответствует таблица на клиенте.
<pre>
 select * from docs order by docdate desc
</pre>
* если есть таблица g$queue, смотрим когда были последние пакеты и есть ли по ним ошибки.
<pre>
 select * from g$queue q where q.profile_id=:profile_id
</pre>


=Частые вопросы=
==Нужно чтобы закрытая аптека не висела бы на 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начала попробуйте удалить старые накладные требования (сделав бэкап). 
<pre>
delete from doc_detail_active_treb ddat where ddat.insertdt <= current_date-7;
</pre>
<pre>
delete from docs_treb dt where dt.insertdt <= current_date-7;
</pre>
Проверьте в таблицы docs нет ли документов с rguid той записи, на которую ругается. Если такой документ уже есть, то измените ему rguid. 
<pre>
update docs d set d.rguid=replace(UUID_TO_CHAR( GEN_UUID()),'-','') where d.rguid=:rguid;
</pre>

==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, и теперь эта база пытается скачать вообще все с нуля. Надо проверить: это новая база? Нужно определить актуальность данных проблемной базы. Выполняем запрос на сервере: 
<pre>
select * from g$distribute where from_profile_id=:profile_id order by serverpacket desc
</pre>
После этого чистим g$distribute в проблемной базе: 
<pre>
delete from g$distribute d where d.serverpacket<(select max(g.serverpacket) from g$distribute g);
</pre>
У нас останется только одна запись у которой поле '''serverpacket''' not null. Заполняем у этой записи это поле значением, которое мы получили на сервере. Снова запускаем синхронизацию.