Кто пользуется синхронизацией баз данных? : Супермаг Плюс (Супермаг 2000)

Dim · █ 26.09.2010 18:37

В почтовике есть замечательная фишка - синхронизация БД. На мой взгляд не хватает возможности в условиях отбора при создании процесса отметить галочками те виды документов, кот. надо синхронизовать. Тогда вся синхронизация пойдет одним процессом, тогда как сейчас на каждый тип документов для каждой базы необходимо создавать отдельный процесс. Например, синхронизация документов приходных, расходных накладных, возврат через кассу, продажа через кассу для 5 баз потребует создания 20 процессов. Хочется иметь 1 процесс на магазин. А в идеале и вообще 1 процесс на ВСЕ магазины.
На конференции общался с разработчиками. Сказали, что тоже нетрудно реализовать. Просьба - отпишитесь в техподдержку с просьбой добавить данный функционал.

OlegON · █ 26.09.2010 19:37

К сожалению, диагностирую мертворождение фичи в том виде, в каком она есть. А именно: 1) Практически никакое логгирование 2) Труднодиагностируемость ошибок 3) Неудобство пользования (как раз то, о чем ты говоришь)
В общем, все болячки почтовика были унаследованы.
Я, собственно, потому и создавал синхронизацию в оптимизаторе (это было после того, как уперся в попытках выжать что-то вменяемое из синхронизации почтовика). Задумка хорошая и нужная, НО, во-первых, необходим нормальный лог вида:

Цитата:

01.01.2010 - 17:00 В базе "Траляля" обнаружен отсутствующий в любых статусах документ приходная накладная №78378, передан в базу "ЦО", ошибок не обнаружено
01.01.2010 - 17:01 В базе "Траляля" обнаружен черновик документа акт переоценки №82989, присутствующий в базе "ЦО" в зеленом статусе. Документ не пересылается.
01.01.2010 - 17:02 В базе "Траляля" обнаружен документ приходная накладная №8983222, передача в базу "ЦО" не удалась, ошибка ORA-01502: Unusable index

Лог привел в подробном виде, безусловно надо использовать шаблоны, я лишь демонстрировал принципы и отражаемые детали. Если заниматься автоматизацией этого процесса, то делать это хорошо. Во-вторых, механизм поддержки, которому нужен механизм поддержки - пятое колесо. Безусловное преимущество того, что есть сейчас - возможность работать в оффлайне, т.е. при отсутствии прямого линка от центральной базы к подчиненным. Это козырь. Но в остальном "usability" этого механизма оставляет желать лучшего. Я пошел более простым и доступным путем, просто ежедневно создаю текстовичок, где написано, какие карточки/документы и в каких статусах находятся в одной базе и каких нет в другой, каких, соответственно, наоборот. Эта самая дельта позволяет администратору самостоятельно принимать решение о необходимости что-то предпринимать. Все другие ветки развития вижу настолько монстроидальными и обвешанными опциями, что эффект от их добавления ниже стоимости потраченного на разработку времени.
Извините за сумбур :)

konst · █ 26.09.2010 19:43

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

OlegON · █ 26.09.2010 20:36

Цитата:

konst ➤ проблему неудобного управления решали созданием заданий на синхронизацию с помощью SQL запросов непосредственно в самой БД...

Может, поделишься? :) А то, думаю, вопрос Dimа решится с полпинка...

GENDALF · █ 27.09.2010 01:18

Этот, механизм хорош как идея, но плох,потому что не доведен до ума. :( до автоматизации... которая преследуется любым ПО.

Dim · █ 27.09.2010 06:59

Цитата:

GENDALF ➤ Этот, механизм хорош как идея, но плох,потому что не доведен до ума. :( до автоматизации... которая преследуется любым ПО.

так давайте сообща решим, каков он должен быть. и может к нам прислушаются.

OlegON · █ 27.09.2010 07:29

Пусть бы лучше лог почтовика вынесли в базовый модуль. Чтобы все то, что юзера косячат с документами, сами юзера бы и разгребали. Только с нормальными обратными сообщениями. И двумя типами логов, только по тем документам, что сам делал и вообще по всем. И не сразу всасывать все записи, а по мере перемещения ползунка, чтобы не пришлось активному юзеру неделю ждать всасывания.
И еще бы сделали, чтобы юзер смог из одной базы заказать документ удаленной базы в свою, если он по правилам рассылки в нее должен пересылаться. А если не может влиться или правилам не соответствует - увидеть эту ошибку. Цель - предотвратить помойку, а не мучить бедного админа рутиной по ее разгребанию. Тогда и моего текстовичка с разницей документов хватит. Даже в самой помойке в этом текстовичке десяток документов...

А по этому... Логи и еще раз логи... И не сообщения типа "Не удалось закончить процесс из-за сбоя", а что-нибудь вменяемое.

deucel · █ 27.09.2010 12:26

Цитата:

OlegON ➤ Может, поделишься? :) А то, думаю, вопрос Dimа решится с полпинка...

вроде этот скрипт:

Код:

DECLARE
   rid          NUMBER := &rgnid;
   datestart    DATE   := TO_DATE ('01.01.2006', 'DD.MM.YYYY');
   dateend      DATE   := TO_DATE ('01.01.2007', 'DD.MM.YYYY');
   vprocessid   NUMBER;
BEGIN
   FOR c_rec IN (SELECT ROWNUM, m.dbaseid rdb, l.ID storeloc, l.NAME storelocname
                   FROM smstorelocations l, smpostlocmap m
                  WHERE l.rgnid = rid AND l.accepted = 1 AND l.ID = m.storeloc)
   LOOP
      BEGIN
         SELECT smprocessseq.NEXTVAL INTO vprocessid FROM DUAL;

         INSERT INTO smprocess (processid, processtype, employee)
              VALUES (vprocessid, 'SYCP', -1);

         COMMIT;

         INSERT INTO smpostsynchroprocess (processid, remotedb, objtype, condition, conditiondesc, state)
              VALUES (vprocessid, c_rec.rdb, 'IW',
                      'SMDocuments' || CHR (10) || 'DocType' || CHR (10) || '1' || CHR (10) || 'IW' || CHR (10) || CHR (10) || 
                      'SMDocuments' || CHR (10) || 'LocationFrom' || CHR (10) || '1' || CHR (10) || c_rec.storeloc || CHR (10) || CHR (10) || 
                      'SMDocuments' || CHR (10) || 'CreatedAt' || CHR (10) || '4' || CHR (10) || TO_CHAR(datestart, 'YYYYMMDD')  || CHR (10) || TO_CHAR(dateend, 'YYYYMMDD') || CHR (10) || CHR (10),
                      c_rec.storelocname || ', с ' || TO_CHAR(datestart, 'DD.MM.YYYY') || ' по ' || TO_CHAR(dateend, 'DD.MM.YYYY'), 0);

         COMMIT;

         SELECT smprocessseq.NEXTVAL INTO vprocessid FROM DUAL;

         INSERT INTO smprocess (processid, processtype, employee)
              VALUES (vprocessid, 'SYCP', -1);

         COMMIT;

         INSERT INTO smpostsynchroprocess (processid, remotedb, objtype, condition, conditiondesc, state)
              VALUES (vprocessid, c_rec.rdb, 'IW',
                      'SMDocuments' || CHR (10) || 'DocType' || CHR (10) || '1' || CHR (10) || 'IW' || CHR (10) || CHR (10) || 
                      'SMDocuments' || CHR (10) || 'LocationTo' || CHR (10) || '1' || CHR (10) || c_rec.storeloc || CHR (10) || CHR (10) || 
                      'SMDocuments' || CHR (10) || 'CreatedAt' || CHR (10) || '4' || CHR (10) || TO_CHAR(datestart, 'YYYYMMDD')  || CHR (10) || TO_CHAR(dateend, 'YYYYMMDD') || CHR (10) || CHR (10),
                      c_rec.storelocname || ', с ' || TO_CHAR(datestart, 'DD.MM.YYYY') || ' по ' || TO_CHAR(dateend, 'DD.MM.YYYY'), 0);

         COMMIT;

         SELECT smprocessseq.NEXTVAL INTO vprocessid FROM DUAL;

         INSERT INTO smprocess (processid, processtype, employee)
              VALUES (vprocessid, 'SYCP', -1);

         COMMIT;

         INSERT INTO smpostsynchroprocess (processid, remotedb, objtype, condition, conditiondesc, state)
              VALUES (vprocessid, c_rec.rdb, 'WI',
                      'SMDocuments' || CHR (10) || 'DocType' || CHR (10) || '1' || CHR (10) || 'WI' || CHR (10) || CHR (10) || 
                      'SMDocuments' || CHR (10) || 'LocationTo' || CHR (10) || '1' || CHR (10) || c_rec.storeloc || CHR (10) || CHR (10) || 
                      'SMDocuments' || CHR (10) || 'CreatedAt' || CHR (10) || '4' || CHR (10) || TO_CHAR(datestart, 'YYYYMMDD')  || CHR (10) || TO_CHAR(dateend, 'YYYYMMDD') || CHR (10) || CHR (10),
                      c_rec.storelocname || ', с ' || TO_CHAR(datestart, 'DD.MM.YYYY') || ' по ' || TO_CHAR(dateend, 'DD.MM.YYYY'), 0);

         COMMIT;

         SELECT smprocessseq.NEXTVAL INTO vprocessid FROM DUAL;

         INSERT INTO smprocess (processid, processtype, employee)
              VALUES (vprocessid, 'SYCP', -1);

         COMMIT;

         INSERT INTO smpostsynchroprocess (processid, remotedb, objtype, condition, conditiondesc, state)
              VALUES (vprocessid, c_rec.rdb, 'WO',
                      'SMDocuments' || CHR (10) || 'DocType' || CHR (10) || '1' || CHR (10) || 'WO' || CHR (10) || CHR (10) || 
                      'SMDocuments' || CHR (10) || 'LocationFrom' || CHR (10) || '1' || CHR (10) || c_rec.storeloc || CHR (10) || CHR (10) || 
                      'SMDocuments' || CHR (10) || 'CreatedAt' || CHR (10) || '4' || CHR (10) || TO_CHAR(datestart, 'YYYYMMDD')  || CHR (10) || TO_CHAR(dateend, 'YYYYMMDD') || CHR (10) || CHR (10),
                      c_rec.storelocname || ', с ' || TO_CHAR(datestart, 'DD.MM.YYYY') || ' по ' || TO_CHAR(dateend, 'DD.MM.YYYY'), 0);

         COMMIT;

         SELECT smprocessseq.NEXTVAL INTO vprocessid FROM DUAL;

         INSERT INTO smprocess (processid, processtype, employee)
              VALUES (vprocessid, 'SYCP', -1);

         COMMIT;

         INSERT INTO smpostsynchroprocess (processid, remotedb, objtype, condition, conditiondesc, state)
              VALUES (vprocessid, c_rec.rdb, 'CS',
                      'SMDocuments' || CHR (10) || 'DocType' || CHR (10) || '1' || CHR (10) || 'CS' || CHR (10) || CHR (10) || 
                      'SMDocuments' || CHR (10) || 'LocationFrom' || CHR (10) || '1' || CHR (10) || c_rec.storeloc || CHR (10) || CHR (10) || 
                      'SMDocuments' || CHR (10) || 'CreatedAt' || CHR (10) || '4' || CHR (10) || TO_CHAR(datestart, 'YYYYMMDD')  || CHR (10) || TO_CHAR(dateend, 'YYYYMMDD') || CHR (10) || CHR (10),
                      c_rec.storelocname || ', с ' || TO_CHAR(datestart, 'DD.MM.YYYY') || ' по ' || TO_CHAR(dateend, 'DD.MM.YYYY'), 0);

         COMMIT;

         SELECT smprocessseq.NEXTVAL INTO vprocessid FROM DUAL;

         INSERT INTO smprocess (processid, processtype, employee)
              VALUES (vprocessid, 'SYCP', -1);

         COMMIT;

         INSERT INTO smpostsynchroprocess (processid, remotedb, objtype, condition, conditiondesc, state)
              VALUES (vprocessid, c_rec.rdb, 'CR',
                      'SMDocuments' || CHR (10) || 'DocType' || CHR (10) || '1' || CHR (10) || 'CR' || CHR (10) || CHR (10) || 
                      'SMDocuments' || CHR (10) || 'LocationTo' || CHR (10) || '1' || CHR (10) || c_rec.storeloc || CHR (10) || CHR (10) || 
                      'SMDocuments' || CHR (10) || 'CreatedAt' || CHR (10) || '4' || CHR (10) || TO_CHAR(datestart, 'YYYYMMDD')  || CHR (10) || TO_CHAR(dateend, 'YYYYMMDD') || CHR (10) || CHR (10),
                      c_rec.storelocname || ', с ' || TO_CHAR(datestart, 'DD.MM.YYYY') || ' по ' || TO_CHAR(dateend, 'DD.MM.YYYY'), 0);

         COMMIT;
      END;
   END LOOP;
END;

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

Результаты опроса: Пользуетесь ли вы синхронизацией баз данных почтовиком?
Да	3	23.08%
Нет	6	46.15%
Планирую начать	4	30.77%
А что это такое? :)	0	0%
Голосовавшие: 13. Вы ещё не голосовали в этом опросе