Текущая версия на 15:56, 18 мая 2022

Внимание!!! Статья устаревшая, cм. новую "Синхронизация:Общие вопросы по синхронизации"

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

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

• Обновить Distribute Client.
• Убрать настройку перезапуск раз в n циклов.
• Убрать галку хранить историю в g$distribute.
• Проверить таймауты, ограничения пакетов.
• Удалить все лишнее из папки с dtclient'ом (*.zip и *.rcvd файлы).
• Выключить брэндмауэр и антивирус.
• Запустить exe с ключом +detail
• Запустить программу от имени администратора
• Проверить, что дата/время на компьютере установлена верно.
• Поискать запись по 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

• проапдейтить необходимые записи.
• Посмотреть за какое число сейчас пытается скачать даннные клиент. Берем uuid последней записи:

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

Затем выполняем на сервере:

select g.insertdt, g.updatedt from g$distribute g where g.uuid="..."

Если даты старые (больше недели), то проверяем актуален ли serverpacket на клиенте. Выполняем на сервере:

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

Выполняем на клиенте:

select serverpacket from g$distribute where 1=1 order by serverpacket desc

Сравниваем. Если на сервере значение меньше, то обновляем на клиенте:

update g$distribute set serverpacket=:serverpacket where serverpacket=(select max(g.serverpacket) from g$distribute g)

• Проверить базу на ошибки.

Снова запускаем синхронизацию.

На сервере

Основное

• Сервер доступен
• База ZTRADE_G.FDB доступна
• WAMP запущен
• Служба StandartNDistributeQueueService запущена;

Дополнительно

• Поискать запись по 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

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

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

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

select * from docs d where d.g$profile_id=:profile_id order by d.commitdate 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

• Firebird работает. Если linux, то

/etc/init.d/firebird<Tab> status

если нужно перезапустить:

/etc/init.d/firebird<Tab> restart

• Wamp включен. Если linux, то

/etc/init.d/apache<Tab> status

если нужно перезапустить

/etc/init.d/apache<Tab> stop
/etc/init.d/apache<Tab> start

• Удалить все содержимое каталогов users и queue. Если linux, то

cd ... <путь до скриптов>
cd users
<убедитесь, что вы точно зашли в папку users>
rm -R ./* -v
cd ../queue
<убедитесь, что вы зашли в папку queue>
rm -R ./* -v

• Проверить, что дата/время на компьютере установлено верно. Если linux, то

date

если нужно установить время:

date +%T -s "11:14:00"

• Проверить настройки в declare.php. Если linux, то

cd ... <путь до скриптов>
nano declare.php

• Служба очереди работает.

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

Distribute Client не запускается, выходит ошибка "программа уже запущена"

Перезагрузите firebird или сделайте базу в даун и снова онлайн.

Как синхронизировать таблицу

В скриптах ниже нужно исправить MY_TABLE на название вашей таблицы.

В клиентской базе которую хотим распространить

• Добавляем поля D$UUID и D$SRVUPDDT

ALTER TABLE MY_TABLE 
ADD D$UUID DM_UUID;
ALTER TABLE MY_TABLE 
ADD D$SRVUPDDT DM_DATETIME;

• Делаем первичный ключ на поле d$uuid:

ALTER TABLE MY_TABLE
ADD CONSTRAINT PK_MY_TABLE
PRIMARY KEY (D$UUID);

или уникальный

ALTER TABLE MY_TABLE
ADD CONSTRAINT UNQ1_MY_TABLE
UNIQUE (D$UUID);

• Генерируем значения поля d$uuid:

update MY_TABLE set d$uuid=UUID_TO_CHAR(GEN_UUID()), d$srvupddt='2000-01-01';

• Создаем триггеры:

SET SQL DIALECT 3;
SET TERM ^ ;

CREATE OR ALTER TRIGGER MY_TABLE_BI_DISTR FOR MY_TABLE
ACTIVE BEFORE INSERT POSITION 0
AS
begin
   if (new.d$uuid is null) then
  begin
    /*Запрещаем менять данные, если централизованное управление*/
    /*
    if (cast((select param_value from params where param_id = 'CODE_PROFILE') as dm_id) <> 2) then
      exception ex_wrong_db;
    */
    new.d$uuid=UUID_TO_CHAR(GEN_UUID());
    update or insert into g$distribute (TABLENAME,UUID,SOPER,FROM_PROFILE_ID) values ('MY_TABLE,new.d$uuid,0,null) matching (TABLENAME,UUID);
  end
  if (new.d$srvupddt is null) then
    new.d$srvupddt='2000-01-01';
end
^

CREATE OR ALTER TRIGGER MY_TABLE_BU_DISTR FOR MY_TABLE
ACTIVE BEFORE UPDATE POSITION 0
AS
begin
  if (new.D$SRVUPDDT=old.D$SRVUPDDT) then
    begin
     /*Запрещаем менять данные, если централизованное управление*/
     /*
     if (cast((select param_value from params where param_id = 'CODE_PROFILE') as dm_id) <> 2) then
      exception ex_wrong_db
     */
     update or insert into g$distribute (TABLENAME,UUID,SOPER,FROM_PROFILE_ID) values ('MY_TABLE',new.d$uuid,1,null) matching (TABLENAME,UUID);
    end
end
^

CREATE OR ALTER TRIGGER MY_TABLE_AD_DISTR FOR MY_TABLE
ACTIVE AFTER DELETE POSITION 0
AS
begin
    /*Запрещаем менять данные, если централизованное управление*/
     /*
    if (cast((select param_value from params where param_id = 'CODE_PROFILE') as dm_id) <> 2) then
      exception ex_wrong_db;
    */
    update or insert into g$distribute (TABLENAME,UUID,SOPER,FROM_PROFILE_ID) values ('MY_TABLE',old.d$uuid,2,null) matching (TABLENAME,UUID);
end
^

SET TERM ; ^

• Делаем update, чтобы отправить данные на сервер:

update MY_TABLE set id=id

• Для того, что бы не было конфликтов ID на точках при двух сторонней синхронизации необходимо отправить по сети чистку данных в точках, если они есть:

delete from MY_TABLE

Настраиваем одностороннюю синхронизацию на сервере

• Создаем таблицу с той структурой, которую сделали в клиентских базах (переносим только структуру).
• Не забываем сделать поле d$uuid уникальным:

ALTER TABLE DOCS ADD CONSTRAINT PK_MY_TABLE PRIMARY KEY (D$UUID);

• Добавляем поле G$PROFILE_ID

ALTER TABLE MY_TABLE
ADD G$PROFILE_ID DM_ID;

• Создаем триггеры:

SET SQL DIALECT 3;
SET TERM ^ ;

CREATE OR ALTER TRIGGER MY_TABLE_BI_SRVSYNC FOR MY_TABLE
ACTIVE BEFORE INSERT POSITION 0
AS
begin
  select from_profile_id from g$distribute where uuid=new.d$uuid into new.g$profile_id;
end
^

CREATE OR ALTER TRIGGER MY_TABLE_BU_SRVSYNC FOR MY_TABLE
ACTIVE BEFORE UPDATE POSITION 0
AS
begin
  select from_profile_id from g$distribute where uuid=new.d$uuid into new.g$profile_id;
end
^

SET TERM ; ^

Настраиваем двухстороннюю синхронизацию на сервере

• Создаем таблицу с той структурой, которую сделали в клиентских базах (переносим только структуру).
• Если в таблице первоначально сделано уникальное поле G$PROFILE_ID, то нужно его удалить

ALTER TABLE MY_TABLE DROP CONSTRAINT FK_MY_TABLE_1;
ALTER TABLE MY_TABLES DROP G$PROFILE_ID;

• Не забываем сделать поле d$uuid уникальным:

ALTER TABLE MY_TABLE ADD CONSTRAINT PK_MY_TABLE PRIMARY KEY (D$UUID);

• Добавляем триггеры:

SET SQL DIALECT 3;
SET TERM ^ ;

CREATE OR ALTER TRIGGER MY_TABLE_AD0_DISTR FOR MY_TABLE
ACTIVE AFTER DELETE POSITION 0
AS
begin
  update or insert into g$distribute (TABLENAME,UUID,SOPER,FROM_PROFILE_ID) values ('MY_TABLE',old.d$uuid,2,0) matching (TABLENAME,UUID);
end
^

CREATE OR ALTER TRIGGER MY_TABLE_BI_DISTR FOR MY_TABLE
ACTIVE BEFORE INSERT POSITION 0
AS
begin
  if (new.d$uuid is null) then
  begin
    new.d$uuid=UUID_TO_CHAR(GEN_UUID());
    update or insert into g$distribute (TABLENAME,UUID,SOPER,FROM_PROFILE_ID) values ('MY_TABLE',new.d$uuid,0,0) matching (TABLENAME,UUID);
  end
  if (new.d$srvupddt is null) then
    new.d$srvupddt='2000-01-01';
end
^

CREATE OR ALTER TRIGGER MY_TABLE_BU0_DISTR FOR MY_TABLE
ACTIVE BEFORE UPDATE POSITION 0
AS
begin
  if (new.D$SRVUPDDT=old.D$SRVUPDDT) then
    update or insert into g$distribute (TABLENAME,UUID,SOPER,FROM_PROFILE_ID) values ('MY_TABLE',new.d$uuid,1,0) matching (TABLENAME,UUID);
end
^

SET TERM ; ^

• Добавляем информацию о нашей таблице в G$DISTRIBUTE_VECTORS

INSERT INTO G$DISTRIBUTE_VECTORS (FROM_PROFILE_ID, TO_PROFILE_ID, TABLENAME, PERMISSION) VALUES (0, 0, 'MY_TABLE', 0);

• Добавляем информацию о нашей таблице в G$DISTRIBUTE_X_TABLES, если профилей уже много в базе можно применить выполнение блока:

execute block
as
declare variable PROFILE_ID type of DM_ID;
begin
for select md.id from g$profiles md
where status =0 and md.dbsecurekey is not null and  relationtype=1 into :profile_id do
INSERT INTO G$DISTRIBUTE_X_TABLES (PROFILE_ID, TABLENAME, CLIENTTABLENAME)
                           VALUES (:profile_id, 'MY_TABLE', 'MY_TABLE');
end

Проверяем не исключена ли наша таблица на сервере wamp в getrelationtype.php выполняем поиск нашей таблицы. Данные отправляются если они попадают под условия return 0;

Дополнительно проверить что было отправлено при необходимости:

• Для того, что бы не было конфликтов ID на точках необходимо отправить по сети чистку данных в точках:

delete from MY_TABLE

Добавить запись к частично-двусторонней синхронизации

• Для чего нужно: требуется для настройки групп (GROUPS) где часть записей существует самостоятельно в клиентской базе, а часть нужно поддерживать в едином варианте по всей сети.
• Допустим нужно запись ID=:ID таблицы MY_TABLE настроить так, что бы изменения "ходили" по двусторонней синхронизации.
• Внести исправления в getrelationtype.php
• Удалить все следы записи в серверной и сводных базах.

delete from MY_TABLE where ID=:ID; 
delete from g$distribute where tablename='MY_TABLE' where uuid=(select t.d$uuid from my_table t where t.ID=:ID);

• Обеспечить идентичные d$uuid у нужной записи во всех клиентских базах, только аккуратно, что бы при установке новых d$uuid запись не пошла по синхронизации, для этого в запросе добавим Update d$srvupddt. Данные sql-запросы можно разослать с помощью g$tasks.

delete from g$distribute where tablename='MY_TABLE' where uuid=(select t.d$uuid from my_table t where t.ID=:ID);
update MY_TABLE set d$uuid=:new_d$uuid, d$srvupddt=current_timestamp where ID=:ID;

• Теперь можно вносить изменения в записи и она разойдется по всей сети без ошибок.

Можно ли вручную перенести записи если они не приходят по синхронизации?

Теоретически если записи по непонятным причинам не доходят по синхронизации, а нужно, чтобы эти данные срочно появились в нужной базе, то теоретически можно вручную скопировать эти записи и вставить их в базу вручную через ibexpert. Главное перед этим посмотреть: данная таблица синхронизируется в одну сторону, или в обе стороны, т.е. в клиентской базе данные только этой базы, или вообще всей сети?

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

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

Пустые наименования

• Сначала нужно определиться чего именно не хватает. Партия цепляет варес, варес цепляет валс. Обычно не хватает или вареса или валса. Бывает, что все есть, но в валсе пустое значение (в этом случае нужно в менеджере два раза нажать на наименование и вставить оригинальное значение товара).

выполняем запрос

select * from warebase_g w where w.ware_id=:ware_id 

берем ware_id и выполняем следующий, смотрим есть ли значение наименование sname

select * from wares where wares.id=:ware_id

берем ware_id и выполняем следующий, смотрим есть ли значение наименование sname

select * from vals v where v.id=:name_id

Если все есть выполняем:

select * from
warebase_g w
where w.sname is null

/*Если значения наименования в wares и vals есть, но в warebase_g наименование пустое, выполнить update*/ select сохранен для предварительного просмотра значений

update
warebase_g w
set w.part_id=part_id
where w.sname is null

/*Если пустые наименования в wares а в vals значение есть, выполнить update*/ select сохранен для предварительного просмотра значений

--select * from
update
wares w
set w.sname=(select v.svalue from vals v where v.id=w.name_id)
where w.sname is null

• Бывают случаи, когда наименование привелось к пустому значению, т.е. проблема в приведении. Попробуйте поискать связки:

select 'WARES', V.SVALUE
from WARES WL
left join VALS V on WL.NAME_ID = V.ID
where WL.ID = :ware_id
union
select 'WARES_LOG', V.SVALUE
from WARES_LOG WL
left join VALS V on WL.NAME_ID = V.ID
where WL.ID = :ware_id

• Когда определись чего не хватает в текущей базе, попробовать поискать этот валс или варес в другой серверной, сводной или клиентской базе по его id.
• Если проблема была в варесе, то скорей всего он есть где то в другой базе и его достаточно проапдейтить:

update wares w where w.id=:id

• Если проблема с валсом, то нужно перепривязать данное поле вареса, которое на него ссылается, на другое значение (другой валс). Если, например, проблема с наименованием, а оригинальное наименование ссылается на другое значение, то возьмите его и вставьте в название.

update wares w set w.name_id=(select wa.orig_name_id from wares wa where wa.id=:ID) where w.id=:ID

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

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

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

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

Что можно удалить если синхронизация много весит (каталог wamp занимаем очень много места, больше 1гб)?

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

Как переотправить накладную требования/перемещение/переоценки по синхронизации

• Нужно подключиться к базе, с которой была отправлена накладная.
• Найти doc_id нужного документа по его номеру:

select * from docs d where d.caption containing :docnum

• Переотправить накладную спомощью процедуры:

execute procedure GM$PR_PRIHOD_DOC_TREB(:doc_id);

Как отправить (выполнить) большой SQL на клиенте

Для этого используется процедура UTPR_MASTERDETAIL_CF. Если ее нет ниже SQL:

SET TERM ^ ;
create or alter procedure UTPR_MASTERDETAIL_CF
as
declare variable PROFILE_ID type of DM_ID;
declare variable S DM_TEXT1024;
declare variable STR DM_BLOBTEXT;
begin
 for select md.id from g$profiles md
where md.dbsecurekey is not null and md.relationtype=1 and status=0
--and  md.id in (100)
into :profile_id do
 begin
   str='file:D:\sql\файл для отправки';
--    select data from g$tasks where id=546430 into str;
   insert into g$tasks (PROFILE_ID,TASK_TYPE,CAPTION,data,checkprevtask) values (:profile_id,0, 'Описание task',:str,null);
 end
end^
SET TERM ; ^
GRANT SELECT ON G$PROFILES TO PROCEDURE UTPR_MASTERDETAIL_CF;
GRANT INSERT ON G$TASKS TO PROCEDURE UTPR_MASTERDETAIL_CF;
GRANT EXECUTE ON PROCEDURE UTPR_MASTERDETAIL_CF TO SYSDBA;

В строке str='file:D:\sql\файл для отправки'; указываем путь до файла с файлом SQL

Отправить сетку отображения (распространить вид) таблицы по сети

Для того что бы отправить сетку всем пользователям по сети или нужным профилям в пределах одной сети нужно выполнить следующее:

1. Создаем нужную сетку (вид) которую нужно распространить.

2. Заходим в таблицу USERS, находим пользователя под которым у нас правильная сетка и переходим в поле Data

3. В поле Data должна быть выбрана вкладка AsText - ANSI. В Верху на панели нажимает кнопку с обозначением Дискетки - сохранить.

4. В открывшемся окне выбираем нужную папку для сохранения, тип файла: Все файлы (*.*), набираем понятное имя файла и в конце обязательно добавляем ".ZIP", запоминаем путь, нажимаем кнопку Cохранить.

5. Переходим в каталог куда мы сохранили файл, находим его и распаковываем в папку и переходим в эту папку

6. Выполняем сортировку по дате изменения так, что бы можно было определить самый новый файл. Находим нужную нам сетку, она будет самая новая и быть без какого-либо расширения, например DocArchHeader

7. Архивируем нужную нам сетку или если их несколько то несколько в одном файле, запоминаем путь.

8. Открываем IBExpert, заходим в серверную базу, обычно называется ZTRADE_G.FDB, нам нужна процедура UTPR_MASTERDETAIL_GRID Заходим в нее. Если ее нет ниже SQL:

SET TERM ^ ;
create or alter procedure UTPR_MASTERDETAIL_GRID
as
declare variable PROFILE_ID type of DM_ID;
declare variable S DM_TEXT1024;
declare variable STR DM_BLOBTEXT;
begin
  for select md.id from g$profiles md
where md.dbsecurekey is not null and relationtype=1 and status=0
--and  md.id not in (57,157)
into :profile_id do
  begin
    str=;
 insert into g$tasks (PROFILE_ID,TASK_TYPE,CAPTION,data) values
  (:profile_id,2,'Сетка журнала документов -2', (select data from G$TASKS_TMPL where id = 0));
  end 
end^
SET TERM ; ^
GRANT SELECT ON G$PROFILES TO PROCEDURE UTPR_MASTERDETAIL_GRID;
GRANT INSERT ON G$TASKS TO PROCEDURE UTPR_MASTERDETAIL_GRID;
GRANT SELECT ON G$TASKS_TMPL TO PROCEDURE UTPR_MASTERDETAIL_GRID;
GRANT EXECUTE ON PROCEDURE UTPR_MASTERDETAIL_GRID TO SYSDBA;

9 В процедуре есть текст, типа (select data from G$TASKS_TMPL where id = 0) смотрим какой id указан и переходим в эту таблицу G$TASKS_TMPL. Под указанным ID в данном случае 0 открываем поле DATA должна быть выбрана вкладка AsText - ANSI.

10. Нажимаем кнопку Открыть, выбираем файл подготовленный в п.7, подтверждаем изменения - делаем коммит

11. В процедуре UTPR_MASTERDETAIL_GRID выбираем 1 профиль и выполняем процедуру. Через некоторое время проверяем изменения на объекте. Если все хорошо отправляем сетку всех профилей у кого она должна быть, внеся изменения в указанную процедуру.

Все проверяем через некоторое время исправления должны быть у всех пользователей.

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

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 той записи, на которую ругается синхронизация. Удалите одну из них.

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;

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

 delete from g$distribute g where g.soper <> 2 and g.tablename='имя таблицы' and
 not exists(select id from имя таблицы d where d.d$uuid = g.uuid)

Если просит удалить более 1000 записей, ток внедрению

Connection reset by peer

• Проверить таймауты
• Проверить ограничения пакетов
• Выключить антивирус
• Выключить брэндмауэр
• Проверить системное время
• Выключить роутер на 15 минут
• Почистить таблицу g$distribute.

Incomplete Zip File

Ошибка бывает на клиенте.

• Скорей всего связана с блокировками синхронизации антивирусом.
• Проверить правильность написания URL

wrong page type

Ошибка wrong page type page 79332 is of wrong type (expected 7, found 5)... падение базы. выполнить: mend - backup - restore.

Ошибка при сеансе обмена: checkprevtask: предыдущая задача не выполнена или выполнена с ошибкой

в глоб базе в табл g$task по профилю есть задача, которая не выполнилась по полю senddt отправка прошла , а по полю enddt нет. т е задача не завершилась в этом случае поле senddt устанавливаем в NULL . синхронизируем. ждем завершения задачи

update g$tasks g set g.senddt = null where g.senddt is not null and g.enddt is null and g.checkprevtask is not null

Также пробуем последнее условие "g.checkprevtask is not null" убрать, так как не все записи удаляются, подвисшие остаются