Синхронизация:Общие вопросы по синхронизации

2021-07-02T08:03:35Z

Avo: /* Пустые наименования */

=Порядок действий, если не работает синхронизация=

==На стороне клиента==
* Обновить Distribute Client.
* Убрать настройку '''перезапуск раз в n циклов'''.
* Убрать галку '''хранить историю в g$distribute'''.
* Проверить таймауты, ограничения пакетов.
* Удалить все лишнее из папки с dtclient'ом (*.zip и *.rcvd файлы).
* Выключить брэндмауэр и антивирус.
* Запустить exe с ключом +detail
* Запустить программу от имени администратора
* Проверить, что дата/время на компьютере установлена верно.
* Поискать запись по d$uuid в g$distribute в первой, серверной и второй базах, чтобы определить между какими базами проблема.
<pre>
select * from g$distribute g where g.uuid="..."
</pre>
* Посмотреть когда были последние данные, которые пришли по синхронизации:
<pre>
select * from g$distribute g order by g.serverpacket desc
</pre>
* Если запись не ушла из первой базы в серверную, то сравните поле 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>
* проапдейтить необходимые записи.
* Посмотреть за какое число сейчас пытается скачать даннные клиент. Берем '''uuid''' последней записи:
<pre>
select g.uuid from g$distribute g order by g.serverpacket desc
</pre>
Затем выполняем '''на сервере''':
<pre>
select g.insertdt, g.updatedt from g$distribute g where g.uuid="..."
</pre>
'''Если даты старые''' (больше недели), то проверяем актуален ли serverpacket на клиенте. Выполняем на сервере:
<pre>
select serverpacket from g$distribute where from_profile_id=:profile_id order by serverpacket desc
</pre>
Выполняем на клиенте:
<pre>
select serverpacket from g$distribute where 1=1 order by serverpacket desc
</pre>
Сравниваем. '''Если на сервере значение меньше''', то обновляем на клиенте:
<pre>
update g$distribute set serverpacket=:serverpacket where serverpacket=(select max(g.serverpacket) from g$distribute g)
</pre>
* Проверить базу на ошибки.
Снова запускаем синхронизацию.

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

===Дополнительно===
* Поискать запись по d$uuid в g$distribute в первой, серверной и второй базах, чтобы определить между какими базами проблема.
<pre>
select * from g$distribute g where g.uuid="..."
</pre>
* Посмотреть когда были последние данные, которые пришли по синхронизации:
<pre>
select * from g$distribute g where g.from_profile_id=:profile_id order by g.serverpacket desc
</pre>
* в таблице '''g$queue''' есть свежие данные:
<pre>
select * from g$queue q where q.profile_id=:profile_id order by q.insertdt desc
</pre>
* в таблице '''docs''' есть свежие данные
<pre>
select * from docs d where d.g$profile_id=:profile_id order by d.commitdate desc
</pre>
Посмотрите на поле '''endflag''': если там '''-1''', значит ошибка.
* профиль прописан в '''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>
* Firebird работает. Если linux, то
<pre>
/etc/init.d/firebird<Tab> status
</pre>
если нужно перезапустить:
<pre>
/etc/init.d/firebird<Tab> restart
</pre>
* Wamp включен. Если linux, то
<pre>
/etc/init.d/apache<Tab> status
</pre>
если нужно перезапустить
<pre>
/etc/init.d/apache<Tab> stop
/etc/init.d/apache<Tab> start
</pre>
* Удалить все содержимое каталогов users и queue. Если linux, то
<pre>
cd ... <путь до скриптов>
cd users
<убедитесь, что вы точно зашли в папку users>
rm -R ./* -v
cd ../queue
<убедитесь, что вы зашли в папку queue>
rm -R ./* -v
</pre>
* Проверить, что дата/время на компьютере установлено верно. Если linux, то
<pre>
date
</pre>
если нужно установить время:
<pre>
date +%T -s "11:14:00"
</pre>
* Проверить настройки в declare.php. Если linux, то
<pre>
cd ... <путь до скриптов>
nano declare.php
</pre>
* Служба очереди работает.

=Частые вопросы=
==Distribute Client не запускается, выходит ошибка "программа уже запущена"==
Перезагрузите firebird или сделайте базу в даун и снова онлайн.

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

===В клиентской базе которую хотим распространить===
* Добавляем поля D$UUID и D$SRVUPDDT
<pre>
ALTER TABLE MY_TABLE
ADD D$UUID DM_UUID;
ALTER TABLE MY_TABLE
ADD D$SRVUPDDT DM_DATETIME;
</pre>
*Делаем первичный ключ на поле d$uuid:
<pre>
ALTER TABLE MY_TABLE
ADD CONSTRAINT PK_MY_TABLE
PRIMARY KEY (D$UUID);
</pre>
или уникальный
<pre>
ALTER TABLE MY_TABLE
ADD CONSTRAINT UNQ1_MY_TABLE
UNIQUE (D$UUID);
</pre>

*Генерируем значения поля d$uuid:
<pre>
update MY_TABLE set d$uuid=UUID_TO_CHAR(GEN_UUID()), d$srvupddt='2000-01-01';
</pre>
* Создаем триггеры:
<pre>
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 ; ^
</pre>
* Делаем update, чтобы отправить данные на сервер:
<pre>
update MY_TABLE set id=id
</pre>

* '''Для того, что бы не было конфликтов ID на точках при двух сторонней синхронизации необходимо отправить по сети чистку данных в точках, если они есть''':
<pre>
delete from MY_TABLE
</pre>

===Настраиваем одностороннюю синхронизацию на сервере===
* Создаем таблицу с той структурой, которую сделали в клиентских базах '''(переносим только структуру)'''.
* Не забываем сделать поле d$uuid уникальным:
<pre>
ALTER TABLE DOCS ADD CONSTRAINT PK_MY_TABLE PRIMARY KEY (D$UUID);
</pre>
* Добавляем поле G$PROFILE_ID
<pre>
ALTER TABLE MY_TABLE
ADD G$PROFILE_ID DM_ID;
</pre>
* Создаем триггеры:
<pre>
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 ; ^
</pre>

==Настраиваем двухстороннюю синхронизацию на сервере==
* Создаем таблицу с той структурой, которую сделали в клиентских базах '''(переносим только структуру)'''.
* Если в таблице первоначально сделано уникальное поле '''G$PROFILE_ID, то нужно его удалить'''
<pre>
ALTER TABLE MY_TABLE DROP CONSTRAINT FK_MY_TABLE_1;
ALTER TABLE MY_TABLES DROP G$PROFILE_ID;
</pre>
* Не забываем сделать поле d$uuid уникальным:
<pre>
ALTER TABLE MY_TABLE ADD CONSTRAINT PK_MY_TABLE PRIMARY KEY (D$UUID);
</pre>
* Добавляем триггеры:
<pre>
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 ; ^
</pre>
* Добавляем информацию о нашей таблице в G$DISTRIBUTE_VECTORS
<pre>
INSERT INTO G$DISTRIBUTE_VECTORS (FROM_PROFILE_ID, TO_PROFILE_ID, TABLENAME, PERMISSION) VALUES (0, 0, 'MY_TABLE', 0);
</pre>

* Добавляем информацию о нашей таблице в G$DISTRIBUTE_X_TABLES, если профилей уже много в базе можно применить выполнение блока:
<pre>
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
</pre>

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

Дополнительно проверить что было отправлено при необходимости:
* '''Для того, что бы не было конфликтов ID на точках необходимо отправить по сети чистку данных в точках:'''
<pre>
delete from MY_TABLE
</pre>

==Добавить запись к частично-двусторонней синхронизации==
* Для чего нужно: требуется для настройки групп (GROUPS) где часть записей существует самостоятельно в клиентской базе, а часть нужно поддерживать в едином варианте по всей сети.
* Допустим нужно запись ID=:ID таблицы MY_TABLE настроить так, что бы изменения "ходили" по двусторонней синхронизации.
* Внести исправления в getrelationtype.php
* Удалить все следы записи в серверной и сводных базах.
<pre>
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);
</pre>
* Обеспечить идентичные d$uuid у нужной записи во всех клиентских базах, только аккуратно, что бы при установке новых d$uuid запись не пошла по синхронизации, для этого в запросе добавим Update d$srvupddt. Данные sql-запросы можно разослать с помощью g$tasks.
<pre>
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;
</pre>
* Теперь можно вносить изменения в записи и она разойдется по всей сети без ошибок.

==Можно ли вручную перенести записи если они не приходят по синхронизации?==
Теоретически если записи по непонятным причинам не доходят по синхронизации, а нужно, чтобы эти данные срочно появились в нужной базе, то теоретически можно вручную скопировать эти записи и вставить их в базу вручную через ibexpert. Главное перед этим посмотреть: данная таблица синхронизируется в одну сторону, или в обе стороны, т.е. в клиентской базе данные только этой базы, или вообще всей сети?
* в первом случае при вставке записей не нужно заполнять поле d$uuid для того, чтобы оно сгенерировалось бы заново.
* во втором случае нужно обязательно заполнить поле d$uuid оригинальными значениями.
Если сделать наоборот, то затем, когда записи, которые должны были дойти по синхронизации, дойдут, а они со временем обязательно дойдут, в базах будут возникать конфликты при вставке записей, связанные с пересечением ключей.

==Пустые наименования==
<pre>
* Для начала проверить все ли настройки выполенны, так как если они не выполнены, то проблема вернется
1) поправить declare.php (убрать WARES.SNAME, поле должно приходить по синхронизации с локальной базы);
2) проверить триггеры на wares.sname на серверной БД (заполнения поля на серверной/сводной БД быть не должно);
3) сделать поле wares.sname на серверной БД NOT NULL (поле должно быть всегда заполнено);
</pre>
* Сначала нужно определиться чего именно не хватает. Партия цепляет варес, варес цепляет валс. Обычно не хватает или вареса или валса. Бывает, что все есть, но в валсе пустое значение (в этом случае нужно в менеджере два раза нажать на наименование и вставить оригинальное значение товара).
выполняем запрос, берем ware_id и выполняем следующий, смотрим есть ли значение наименование sname
'''select name_id, sname from wares where id=:ware_id'''
берем ware_id и выполняем следующий, смотрим есть ли значение наименование sname
'''select svalue from vals v where v.id=:name_id'''

Если '''в wares поле sname = null''', а '''svalue в vals имеет значение''' выполняем обновление:
<pre>
update
wares w
set w.sname=(select v.svalue from vals v where v.id=w.name_id)
where ((sname='') or (sname is null)) and (select v.svalue from vals v where v.id=w.name_id) is not null
</pre>

после выполнения update wares обновляем сводные остатки:
<pre>
update
warebase_g w
set w.part_id=part_id
where w.sname is null
</pre>
/*Если не помогает делаем напрямую исправление наименования в сводных остатках по name_id*/
<pre>
update
warebase_g w
set w.sname=(select v.svalue from vals v where v.id=w.name_id)
where w.sname is null
</pre>

* Бывают случаи, когда наименование привелось к пустому значению, т.е. проблема в приведении. Попробуйте поискать связки:
<pre>
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
</pre>
* Когда определись чего не хватает в текущей базе, попробовать поискать этот валс или варес в другой серверной, сводной или клиентской базе по его id.
* Если проблема была в варесе, то скорей всего он есть где то в другой базе и его достаточно проапдейтить:
<pre>
update wares w where w.id=:id
</pre>
* Если проблема с валсом, то нужно перепривязать данное поле вареса, которое на него ссылается, на другое значение (другой валс). Если, например, проблема с наименованием, а оригинальное наименование ссылается на другое значение, то возьмите его и вставьте в название.
<pre>
update wares w set w.name_id=(select wa.orig_name_id from wares wa where wa.id=:ID) where w.id=:ID
</pre>

==Нужно чтобы закрытая аптека не висела бы на sinhro но чтобы данные по ней отображались в своднике==
Поставить dbsecurekey в таблицы g$profiles в null.

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

==Что можно удалить если синхронизация много весит (каталог wamp занимаем очень много места, больше 1гб)?==
* В папке '''queue''' можно чистить все кроме последних 2х дней.
* В папке '''users''' можно чистить все.

==Как переотправить накладную требования/перемещение/переоценки по синхронизации==
* Нужно подключиться к базе, с которой была отправлена накладная.
* Найти doc_id нужного документа по его номеру:
<pre>
select * from docs d where d.caption containing :docnum
</pre>
* Переотправить накладную спомощью процедуры:
<pre>
execute procedure GM$PR_PRIHOD_DOC_TREB(:doc_id);
</pre>

==Как отправить (выполнить) большой 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

Теги: отправить, выполнить, большой 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 профиль и выполняем процедуру. Через некоторое время проверяем изменения на объекте. Если все хорошо отправляем сетку всех профилей у кого она должна быть, внеся изменения в указанную процедуру.

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

==Как отправить поле типа Blob по синхронизации на примере таблицы Reports==

'''Внимание!!! Для сетей, где таблицы ходят по двухсторонней синхронизации смотри раздел выше "Добавить запись к частично-двусторонней синхронизации"'''

Для отправки добавления отчета в таблицу Reports используется штатный механизм отправки тасков процедура '''"UTPR_MASTERDETAIL"''' отправляем всем нужным профилям добавление отчета:

INSERT INTO REPORTS (PARENT_ID, STATUS, REPORTTYPE, SORTING, CAPTION, PARAMS, WDICT_ID)
VALUES (0, 0, 1, 400, ''Новый отчет'', ''[freereport]
tmplpath=
'', NULL);

Далее сохраняем поле DATA таблицы REPORTS с нужным нам отчетом в txt. Далее открываем таблицу любую таблицу которая ходит по двухсторонней синхронизации, например таблица G$PROFILES. Находим у таблицы поля типа Blob которые не используются, например, TMP_BLOB1 ... TMP_BLOB_N. Если нет можно создать и распространить по сети.
Далее в данное поле сохраняем выгруженный нами отчет и Коммитим изменения - ''''' ЖДЕМ НЕСКОЛЬКО ЧАСОВ!!! ''''' что бы данные дошли до точек. После этого создаем новый таск используя процедуру '''UTPR_MASTERDETAIL''', где обновляем таблицу REPORTS по полю дата заменяю его значением из G$PROFILES:
update reports r set r.data = (select TMP_BLOB1 from g$profiles where id=1 and TMP_BLOB1 is not null) where r.caption =''Новый отчет'';

Теги: отправить, поле, Blob, синхронизация, UTPR_MASTERDETAIL

==Как добавить на панель АРМ Кассира кнопку с нужным действием (ТМС, Отчет)==
'''Важно!!! На момент проведения действия кассиры должны быть все закрыты!!! В противном случае, после закрытия АРМ Кассир все изменения будут заполнены текущими настройками '''
Для рапространения требуется процедура '''"UTPR_MASTERDETAIL_KASSIR"''', если ее нет нужно добавить скрипт ниже:
SET TERM ^ ;
create or alter procedure UTPR_MASTERDETAIL_KASSIR
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
into :profile_id do
begin
--str='';
insert into g$tasks (PROFILE_ID,TASK_TYPE,CAPTION,data) values
(:profile_id,4,'Кнопка в кассире', 'file:E:\Standart-N\tasks\kassabuttons.txt');
end
end^
SET TERM ; ^
GRANT SELECT ON G$PROFILES TO PROCEDURE UTPR_MASTERDETAIL_KASSIR;
GRANT INSERT ON G$TASKS TO PROCEDURE UTPR_MASTERDETAIL_KASSIR;
1. На любой точке или копии базы сети выводим нужную кнопку на панель под определенным пользователем Кассы.

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

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

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

5. Переходим в каталог куда мы сохранили файл, находим его и распаковываем в папку и находим файл '''zkassa#user.ini'''. Открываем его на редактирование.

6. Выполняем поиск по файлу раздела [UserToolBar] - это радел где хранятся кнопки выведенные на панель - находим по названию нужную кнопку нам в добавляем в начале строки '''zkassa#user.ini>UserToolBar>>'''

7. Копируем строку в новый файл форма txt, сохраняем его на диске сервера синхронизации. В процедуре UTPR_MASTERDETAIL_KASSIR указываем путь к данному файлу

Gif на тему:

[[Файл:Add_bitton1.gif]]

Отправляем исправления по синхронизации ночью!!! когда все АРМ Кассир закрыты.

Для этого подготавливаем процедуру '''UTPR_MASTERDETAIL_KASSIR''' и планируем выполнение задания через ''Планировщик заданий Windows'' (команда taskschd.msc) ночью на запуск ТМС SpacePro которая будет вызывать нашу процедуру '''UTPR_MASTERDETAIL_KASSIR'''. Пример: ''D:\Standart-N\Standart-N\spacepro.exe +TMS=№_ТМС''

Теги: отправить, кнопку, Blob, синхронизация, USERS, UTPR_MASTERDETAIL_KASSIR, панель, АРМ Кассир

== Как обновить удаленно Distribute Client (dtclient) ==
Для обновления заходим на сервер синхронизации где установлен установлен каталог синхронизации sinhro.

Внимание!!! Порядок действий не меняем - очень важен для конечного результата

1. Заходим в каталог shellupd, откидываем на всякий случай копию всех файлов в каталог back и копируем туда последнюю тестированную версию Distribute Client.

2. Удаляем файл data.zip и создаем на основе exe Distribute Client с таким же названием в этом же каталоге.

3. Смотрим версию Distribute Client.exe для этого открываем "Свойство" exe, вкладка "Подробно", Версия файла - запоминаем. Нам нужна будет версия между первой точкой.
Например в окне Версия файла мы видим строке 2.2045.0.0, нам будет нужна только 2.2045

4. Открываем файл exe.ver на редактирование и записываем новую версию файла, на текущем примере это 2.2045

Кратко об этом gif:

[[Файл:Update_dtclient.gif]]

Теги: обновить, Distribute Client, dtclient, синхронизация, DistributeClient

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

==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>
Проверяем максимальное значение serverpacket в проблемной базе:
<pre>
select max(g.serverpacket) from g$distribute g;
</pre>
Оно должно быть меньше того что мы получили на сервере. Надо его заменить. Если в проблемной базе эта таблица вообще пустая, тогда берем запись с сервера и вставляем ее там. Затем снова запускаем синхронизацию.
удалить запись можно запросом :

delete from g$distribute g where g.soper <> 2 and g.tablename=Upper('имя таблицы') and
not exists(select id from имя таблицы d where d.d$uuid = g.uuid)
Если просит удалить более 1000 записей, ток внедрению

==Connection reset by peer==
* Проверить таймауты
* Проверить ограничения пакетов
* Выключить антивирус
* Выключить брэндмауэр
* Проверить системное время
* Выключить роутер '''на 15 минут'''
* Почистить таблицу g$distribute.
* в 80 % случаев не верный тип поля (пример DM_ID и DM_ID_NULL) на серверной базе предпочительно разрешать NULL значения

==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 . синхронизируем. ждем завершения задачи
<pre>
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
</pre>

==conversion error from string ...At trigger 'GROUP_DETAIL_AD0_MMBSH' line: 9, col: 34==

Для решение данной ошибки нужно подправить два тригера
<pre>/* Trigger: GROUP_DETAIL_AD0_MMBSH */
CREATE OR ALTER TRIGGER GROUP_DETAIL_AD0_MMBSH FOR GROUP_DETAIL
ACTIVE AFTER DELETE POSITION 0
AS
begin
if (old.grouptable = 'PARTS.NAME_ID' ) then
update warebase w set mmbsh = (select membership from PR_MEMBERSHIPS('PARTS=' || w.part_id || ';PARTS.NAME_ID=' || w.name_id || ';PARTS.IZG_ID=' || w.izg_id ||';',ascii_char(13)||ascii_char(10)))
where name_id = old.grouptable_id;

if ((old.grouptable = 'PARTS' ) and (old.id>0))then
update warebase w set mmbsh = (select membership from PR_MEMBERSHIPS('PARTS=' || w.part_id || ';PARTS.NAME_ID=' || w.name_id || ';PARTS.IZG_ID=' || w.izg_id ||';',ascii_char(13)||ascii_char(10)))
where part_id = cast(old.grouptable_id as bigint);
end </pre>

<pre>/* Trigger: GROUP_DETAIL_BU0_MMBSH */
CREATE OR ALTER TRIGGER GROUP_DETAIL_BU0_MMBSH FOR GROUP_DETAIL
ACTIVE AFTER INSERT OR UPDATE POSITION 0
AS
begin
if (new.grouptable = 'PARTS.NAME_ID' ) then
update warebase w set mmbsh = (select membership from PR_MEMBERSHIPS('PARTS=' || w.part_id || ';PARTS.NAME_ID=' || w.name_id || ';PARTS.IZG_ID=' || w.izg_id ||';',ascii_char(13)||ascii_char(10)))
where name_id = new.grouptable_id;

if ((new.grouptable = 'PARTS' ) and (new.id>0))then
update warebase w set mmbsh = (select membership from PR_MEMBERSHIPS('PARTS=' || w.part_id || ';PARTS.NAME_ID=' || w.name_id || ';PARTS.IZG_ID=' || w.izg_id ||';',ascii_char(13)||ascii_char(10)))
where part_id = new.grouptable_id;
end </pre>

wiki.standart-n.ru - Вклад участника [ru]

Синхронизация:Общие вопросы по синхронизации

Файл:Инструкция ЭСФ АРМ Центральный офис 20210518.docx

Файл:Инструкция ЭСФ АРМ Центральный офис 20210518.docx