AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 11.12.2006, 13:34   #1  
sparur is offline
sparur
Участник
 
334 / 25 (1) +++
Регистрация: 19.05.2006
Синхронизация таблиц м/у 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  
sparur is offline
sparur
Участник
 
334 / 25 (1) +++
Регистрация: 19.05.2006
код как то криво вставился уж простите меня грешного.
Старый 11.12.2006, 13:41   #3  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2476 (88) +++++++++
Регистрация: 20.08.2005
У полей в табличной переменной вообще нет никаких признаков. Есть только данные, которые они хранят.
В принципе, можно сравнивать данные в табличной переменной и в [табличная переменная].orig(), но это можно сделать так же только перебором этих самых полей
__________________
Axapta v.3.0 sp5 kr2
Старый 11.12.2006, 13:43   #4  
sparur is offline
sparur
Участник
 
334 / 25 (1) +++
Регистрация: 19.05.2006
Цитата:
Сообщение от AndyD Посмотреть сообщение
...
В принципе, можно сравнивать данные в табличной переменной и в [табличная переменная].orig(), но это можно сделать так же только перебором этих самых полей
другими словами смысла в моей затеи нет?? и придется тупо переприсваивать все поля и потом вызывать апдейт?
Старый 11.12.2006, 13:53   #5  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от sparur Посмотреть сообщение
Реализовываю синхронизацию различных таблиц м/у компаниями. Все это делаю путем модификации табличных методов insert, update, delete в компании источнике.
Как только вы это делаете, то методы групповой обработки перестают работать.
Читайте про recordset_insert, recordset_update, delete_from

Как только вы это делаете, то управление транзакциями сильно усложняется.

И кроме того, самое главное: вы все равно не гарантированы от различий в разных компаниях. Во-первых, есть методы doInset, doUpdate, doDelete. Во-вторых, теоретически можно изменить что-нибудь напрямую в SQL.

Поэтому, пересмотрите подход к синхронизации.
Ваш подход увеличивает количество гемора и не дает никаких гарантий.

Прямой и штатный способ "синхронизации" - отказаться от синхронизации и перейти к виртуальным компаниям (читайте доку про виртуальные компании).

Цитата:
Сообщение от sparur Посмотреть сообщение
dictField = new dictField(_tableRec.TableId,dt.fieldCnt2Id(i));
Есть метод Global::buf2buf(from,to)
Юзайте его.

Вы не обрабатываете array-поля. Это значит, что такие поля (например, dimension) будут копироваться целиком.

Цитата:
Сообщение от sparur Посмотреть сообщение
а вот "проблемка" с update. Не охота также тупо перебирать ВСЕ поля таблицы, переприсваивать и потом апдейтить.
А смысл? SQL все равно будет тупо апдейтить все поля.
Впрочем, попробуйте поработать с orig(), если очень хочется.

Цитата:
Сообщение от sparur Посмотреть сообщение
код как то криво вставился уж простите меня грешного.
Есть тег [xpp]...код на X++...[/xpp]
В панели инструментов самая правая иконка позволяет вводить этот тег.
__________________
полезное на axForum, github, vk, coub.
Старый 11.12.2006, 14:06   #6  
sparur is offline
sparur
Участник
 
334 / 25 (1) +++
Регистрация: 19.05.2006
Цитата:
Сообщение от mazzy Посмотреть сообщение
Как только вы это делаете, то методы групповой обработки перестают работать.
Читайте про recordset_insert, recordset_update, delete_from

Как только вы это делаете, то управление транзакциями сильно усложняется.

И кроме того, самое главное: вы все равно не гарантированы от различий в разных компаниях. Во-первых, есть методы doInset, doUpdate, doDelete. Во-вторых, теоретически можно изменить что-нибудь напрямую в SQL.

Поэтому, пересмотрите подход к синхронизации.
Ваш подход увеличивает количество гемора и не дает никаких гарантий.
ммм... вери бэд... спасибо за наводку будем поднимать вопрос...

Цитата:
Сообщение от mazzy Посмотреть сообщение
Прямой и штатный способ "синхронизации" - отказаться от синхронизации и перейти к виртуальным компаниям (читайте доку про виртуальные компании).
вряд ли получится перейти к виртуализации, есть определенные нюансы
Цитата:
Сообщение от mazzy Посмотреть сообщение
Есть метод Global::buf2buf(from,to)
Юзайте его.
чем он лучше моего метода?
Цитата:
Сообщение от mazzy Посмотреть сообщение
Вы не обрабатываете array-поля. Это значит, что такие поля (например, dimension) будут копироваться целиком.
ага, так оно и есть как говорится что хотели, то и получат (нужна точная копия записи в др компании)

Цитата:
Сообщение от mazzy Посмотреть сообщение
Есть тег [xpp]...код на X++...[/xpp]
В панели инструментов самая правая иконка позволяет вводить этот тег.
и еще раз респект - буду знать
Старый 11.12.2006, 14:11   #7  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от sparur Посмотреть сообщение
чем он лучше моего метода?
вызывая buf2buf() вы пишете меньше кода.
ваш код будет проще понять и отлаживать.
в вашем коде будет меньше ошибок.

Либо я не понял вопроса, либо одно из двух.
__________________
полезное на axForum, github, vk, coub.
Старый 11.12.2006, 14:26   #8  
sparur is offline
sparur
Участник
 
334 / 25 (1) +++
Регистрация: 19.05.2006
Цитата:
Сообщение от mazzy Посмотреть сообщение
вызывая buf2buf() вы пишете меньше кода.
ваш код будет проще понять и отлаживать.
в вашем коде будет меньше ошибок.

Либо я не понял вопроса, либо одно из двух.
Вопрос Вы поняли... Будем юзать поиск по форуму, дабы найти примеры использования а то что то я как то слабо представляю как он мне в моей конкретной ситуации сможет помочь...
Старый 11.12.2006, 15:39   #9  
MironovI is offline
MironovI
Участник
 
724 / 77 (4) ++++
Регистрация: 30.05.2005
Занимались тут аналогичной задачкой, ноу-хау никакого особо нет, так что могу расказать наверное - вобщем на синхронизаруемые таблицы вешаются триггера на insert, update, delete, которые складывают Recid и TableID в сторонню табличку в базе (у нас эта табличка даже в отдельной базе для надежности). Этот журнал копируется в табличку Аксапты (журнал синхронизации) и обрабатывается периодической операцией.. вобщем все, но есть ньюансы
1) Это "оффлайн" - по сути. Но по факту можно довольно шустро все это обрабатывать.
2) Поскольку это оффлайн - нельзя откатить удаление записи, если удаление в смежной компании приведет к ошибке допустим.

Преимущества очевидны -
1) скулевые триггеры надежны
2) Процесс синхронизации работает централизовано, на сервере, легко мониторить, останавливать/запускать

Последний раз редактировалось MironovI; 11.12.2006 в 16:23.
Старый 11.12.2006, 16:08   #10  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от MironovI Посмотреть сообщение
...на синхронизаруемые таблицы вешаются триггера на insert, update, delete, которые складывают Recid и TableID в сторонню табличку в базе
Почему триггера?
Почему не включили modifiedDate и modifiedTime?
Были какие-нибудь соображения?
__________________
полезное на axForum, github, vk, coub.
Старый 11.12.2006, 16:13   #11  
sparur is offline
sparur
Участник
 
334 / 25 (1) +++
Регистрация: 19.05.2006
Цитата:
Сообщение от MironovI Посмотреть сообщение
Занимались тут аналогичной задачкой, ноу-хау никакого особо нет, так что могу расказать наверное - вобщем на синхронизаруемые таблицы вешаются триггера на insert, update, delete, которые складывают Recid и TableID в сторонню табличку в базе (у нас эта табличка даже в отдельной базе для надежности). Этот журнал копируется в табличку Аксапты (журнал синхронизации) и обрабатывается периодической операцией.. вобщем все, но есть ньюансы
1) Это "оффлайн" - по сути. Но по факту можно довольно шустро все это обрабатывать.
2) Поскольку это оффлайн - нельзя откатить удаление записи, если удаление в смежной компании приведет к ошибке допустим.

Преимущества очевидны -
1) скулевые триггеры надежны
2) Процесс синхроницации работает централизовано, на сервере, легко мониторить, останавливать/запускать
что-то подобное думали реализовать, вернее сказать даже реализовали(правда не триггерами, а как упоминул Mazzy через modifiedDate и modifiedTime), НО на другой задаче!
В данном случае хочется добиться ИМЕННО on-line. поэтому наверное все таки придется пренебречь советами Mazzy (да простит он меня) и продолжать двигаться в том же направлении
Старый 11.12.2006, 16:21   #12  
MironovI is offline
MironovI
Участник
 
724 / 77 (4) ++++
Регистрация: 30.05.2005
Цитата:
Сообщение от mazzy Посмотреть сообщение
Почему триггера?
Почему не включили modifiedDate и modifiedTime?
Были какие-нибудь соображения?
Дык..
1) DoUpdate modifiedTime не трогает
2) Прямое изменение данных через sql (хоть это и не законно, но ты сам упоминал)
3) Паспорт записи - переименование - тоже не меняет modifiedTime
За это сообщение автора поблагодарили: mazzy (5).
Старый 11.12.2006, 16:22   #13  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от sparur Посмотреть сообщение
...придется пренебречь советами Mazzy...
ЕСЛИ вы рассмтрели вопрос с разных сторон, взвесили и плюсы, и минусы...
И после этого приняли ОСОЗНАННОЕ решение...
ТО почему бы и не пренебречь советами?
__________________
полезное на axForum, github, vk, coub.
Старый 11.12.2006, 16:35   #14  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от MironovI Посмотреть сообщение
Дык..
1) DoUpdate modifiedTime не трогает
2) Прямое изменение данных через sql (хоть это и не законно, но ты сам упоминал)
3) Паспорт записи - переименование - тоже не меняет modifiedTime
А... чтобы получить гарантию того, что все изменения...
Ок.

В Bulk операции на SQL-сервере углубляться не будем?
BOL: Controlling Trigger Execution When Bulk Importing Data

Ок. Согласен, что надежность при использовании триггеров выше.
Но все равно не 100% А гемора гарантировано больше.
Надо подумать. Спасибо.
__________________
полезное на axForum, github, vk, coub.
Старый 12.12.2006, 12:22   #15  
DocSerzh is offline
DocSerzh
Участник
 
51 / 22 (0) +++
Регистрация: 28.06.2004
;)
Цитата:
Сообщение от MironovI Посмотреть сообщение
Дык..
1) DoUpdate modifiedTime не трогает
3) Паспорт записи - переименование - тоже не меняет modifiedTime
Вано, привет..

тебя обманули... меняет.
Старый 12.12.2006, 18:47   #16  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
А почему просто не сделали общие таблицы?

С Уважением,
Георгий
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Ре-синхронизация системных таблиц на основании AOT kashperuk DAX: Администрирование 7 28.05.2010 16:36
Владельцы таблиц в БД аксапты AxaptaUser DAX: Администрирование 11 23.05.2007 18:33
Синхронизация таблиц при изменении EDT z_av DAX: Программирование 1 16.12.2004 11:55
синхронизация таблиц andreynikolai DAX: Программирование 3 11.12.2003 16:22
Синхронизация таблиц Андре DAX: Программирование 6 12.04.2002 10:29

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 09:55.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.