|
11.12.2006, 13:34 | #1 |
Участник
|
Синхронизация таблиц м/у 2-мя компаниями
Уважаемые Гуру, добрый день.
Есть небольшая проблемка, думается коллективный раз должен справиться с оной. Вообщем суть такова: Реализовываю синхронизацию различных таблиц м/у компаниями. Все это делаю путем модификации табличных методов insert, update, delete в компании источнике. с методом insert успешно справился: данный метод был вызван в методе insert() компании источника, в котором было сделано changeCompany void insertRec(Common _tableRec) { DictTable dt = new DictTable(_tableRec.TableId); DictField dictField; FieldId fieldId; int cnt = dt.fieldCnt(); //кол-во полей в таблице int i,cntFld=0,cntFldsys=0; int id; boolean flag; ; ttsbegin; commonRec = dt.makeRecord(); flag = false; for (i=1; i<=cnt; i++) { dictField = new dictField(_tableRec.TableId,dt.fieldCnt2Id(i)); fieldId = dt.fieldCnt2Id(i); if (!dictField.isSystem()) {//если поле не системное if (dictField.name(dt.fieldCnt2Id(i))) {//если поле имеет наименование id =fieldName2Id(_tableRec.TableId,dictField.name(dt.fieldCnt2Id(i))); if(id) { commonRec.(Id) = _tableRec.(fieldId); flag = true; } } } } if(flag) { commonRec.insert(); ttscommit; } else ttsabort; } а вот "проблемка" с update. Не охота также тупо перебирать ВСЕ поля таблицы, переприсваивать и потом апдейтить. Думается мне есть какое-то свойство у поля, по которому можно определить было изменено оно или нет. Если есть то можно получить список этих самых смодифицированных полей и работать ТОЛЬКО с ними. проблема собственно: Есть ли такой признак и как его правильно юзать (если он все-таки есть) ??? будут желающие поделиться опытом? |
|
11.12.2006, 13:35 | #2 |
Участник
|
код как то криво вставился уж простите меня грешного.
|
|
11.12.2006, 13:53 | #3 |
Участник
|
Цитата:
Читайте про recordset_insert, recordset_update, delete_from Как только вы это делаете, то управление транзакциями сильно усложняется. И кроме того, самое главное: вы все равно не гарантированы от различий в разных компаниях. Во-первых, есть методы doInset, doUpdate, doDelete. Во-вторых, теоретически можно изменить что-нибудь напрямую в SQL. Поэтому, пересмотрите подход к синхронизации. Ваш подход увеличивает количество гемора и не дает никаких гарантий. Прямой и штатный способ "синхронизации" - отказаться от синхронизации и перейти к виртуальным компаниям (читайте доку про виртуальные компании). Есть метод Global::buf2buf(from,to) Юзайте его. Вы не обрабатываете array-поля. Это значит, что такие поля (например, dimension) будут копироваться целиком. Цитата:
Впрочем, попробуйте поработать с orig(), если очень хочется. Есть тег [xpp]...код на X++...[/xpp] В панели инструментов самая правая иконка позволяет вводить этот тег. |
|
11.12.2006, 14:06 | #4 |
Участник
|
Цитата:
Сообщение от mazzy
Как только вы это делаете, то методы групповой обработки перестают работать.
Читайте про recordset_insert, recordset_update, delete_from Как только вы это делаете, то управление транзакциями сильно усложняется. И кроме того, самое главное: вы все равно не гарантированы от различий в разных компаниях. Во-первых, есть методы doInset, doUpdate, doDelete. Во-вторых, теоретически можно изменить что-нибудь напрямую в SQL. Поэтому, пересмотрите подход к синхронизации. Ваш подход увеличивает количество гемора и не дает никаких гарантий. Цитата:
чем он лучше моего метода? Цитата:
и еще раз респект - буду знать |
|
11.12.2006, 14:11 | #5 |
Участник
|
вызывая buf2buf() вы пишете меньше кода.
ваш код будет проще понять и отлаживать. в вашем коде будет меньше ошибок. Либо я не понял вопроса, либо одно из двух. |
|
11.12.2006, 14:26 | #6 |
Участник
|
Вопрос Вы поняли... Будем юзать поиск по форуму, дабы найти примеры использования а то что то я как то слабо представляю как он мне в моей конкретной ситуации сможет помочь...
|
|
11.12.2006, 13:41 | #7 |
Участник
|
У полей в табличной переменной вообще нет никаких признаков. Есть только данные, которые они хранят.
В принципе, можно сравнивать данные в табличной переменной и в [табличная переменная].orig(), но это можно сделать так же только перебором этих самых полей
__________________
Axapta v.3.0 sp5 kr2 |
|
11.12.2006, 13:43 | #8 |
Участник
|
|
|
11.12.2006, 15:39 | #9 |
Участник
|
Занимались тут аналогичной задачкой, ноу-хау никакого особо нет, так что могу расказать наверное - вобщем на синхронизаруемые таблицы вешаются триггера на insert, update, delete, которые складывают Recid и TableID в сторонню табличку в базе (у нас эта табличка даже в отдельной базе для надежности). Этот журнал копируется в табличку Аксапты (журнал синхронизации) и обрабатывается периодической операцией.. вобщем все, но есть ньюансы
1) Это "оффлайн" - по сути. Но по факту можно довольно шустро все это обрабатывать. 2) Поскольку это оффлайн - нельзя откатить удаление записи, если удаление в смежной компании приведет к ошибке допустим. Преимущества очевидны - 1) скулевые триггеры надежны 2) Процесс синхронизации работает централизовано, на сервере, легко мониторить, останавливать/запускать Последний раз редактировалось MironovI; 11.12.2006 в 16:23. |
|
11.12.2006, 16:08 | #10 |
Участник
|
Цитата:
Почему не включили modifiedDate и modifiedTime? Были какие-нибудь соображения? |
|
11.12.2006, 16:21 | #11 |
Участник
|
Цитата:
1) DoUpdate modifiedTime не трогает 2) Прямое изменение данных через sql (хоть это и не законно, но ты сам упоминал) 3) Паспорт записи - переименование - тоже не меняет modifiedTime |
|
|
За это сообщение автора поблагодарили: mazzy (5). |
11.12.2006, 16:35 | #12 |
Участник
|
Цитата:
Ок. В Bulk операции на SQL-сервере углубляться не будем? BOL: Controlling Trigger Execution When Bulk Importing Data Ок. Согласен, что надежность при использовании триггеров выше. Но все равно не 100% А гемора гарантировано больше. Надо подумать. Спасибо. |
|
12.12.2006, 12:22 | #13 |
Участник
|
|
|
11.12.2006, 16:13 | #14 |
Участник
|
Цитата:
Сообщение от MironovI
Занимались тут аналогичной задачкой, ноу-хау никакого особо нет, так что могу расказать наверное - вобщем на синхронизаруемые таблицы вешаются триггера на insert, update, delete, которые складывают Recid и TableID в сторонню табличку в базе (у нас эта табличка даже в отдельной базе для надежности). Этот журнал копируется в табличку Аксапты (журнал синхронизации) и обрабатывается периодической операцией.. вобщем все, но есть ньюансы
1) Это "оффлайн" - по сути. Но по факту можно довольно шустро все это обрабатывать. 2) Поскольку это оффлайн - нельзя откатить удаление записи, если удаление в смежной компании приведет к ошибке допустим. Преимущества очевидны - 1) скулевые триггеры надежны 2) Процесс синхроницации работает централизовано, на сервере, легко мониторить, останавливать/запускать В данном случае хочется добиться ИМЕННО on-line. поэтому наверное все таки придется пренебречь советами Mazzy (да простит он меня) и продолжать двигаться в том же направлении |
|
11.12.2006, 16:22 | #15 |
Участник
|
ЕСЛИ вы рассмтрели вопрос с разных сторон, взвесили и плюсы, и минусы...
И после этого приняли ОСОЗНАННОЕ решение... ТО почему бы и не пренебречь советами? |
|
12.12.2006, 18:47 | #16 |
Модератор
|
А почему просто не сделали общие таблицы?
С Уважением, Георгий |
|
|
Похожие темы | ||||
Тема | Ответов | |||
Ре-синхронизация системных таблиц на основании AOT | 7 | |||
Владельцы таблиц в БД аксапты | 11 | |||
Синхронизация таблиц при изменении EDT | 1 | |||
синхронизация таблиц | 3 | |||
Синхронизация таблиц | 6 |
|