|
19.12.2001, 17:14 | #1 |
Moderator
|
Метод Merge
У таблицы есть метод Merge, который вызывается когда две записи объединяются. Не могли бы Вы объяснить, что здесь имеется в виду ?
Когда и каким образом происходит объединение записей ? |
|
07.07.2009, 11:45 | #2 |
Мрачный тип
|
merge() на таблице, входящей в виртуальную компанию, отработает только по текущей компании или на всех компаниях, входящих в виртуальную ?
P.S. Вопрос снят, отрабатывает правильно по всем, испытание "на кошках" подтвердило - "кошки" живы
__________________
Мы летаем, кружимся, нагоняем ужасы ... Последний раз редактировалось TasmanianDevil; 07.07.2009 в 12:31. |
|
07.07.2009, 12:13 | #3 |
Участник
|
насколько я знаю, метод merge является устаревшим и уже давно не поддерживается.
|
|
07.07.2009, 19:27 | #4 |
Member
|
Цитата:
Сообщение от mazzy
...метод merge является устаревшим и уже давно не поддерживается...
Насколько я помню его еще до 2.5 убрали из пользовательского интерфейса. Т.к. в общем случае он работать не может, т.к. потенциально может привести к нарушению уникальности индексов в связанных таблицах. Думаю что именно поэтому его убрали из пользовательского интерфейса и оставили доступным для программистов, которые понимают что делают.
__________________
С уважением, glibs® |
|
07.07.2009, 13:42 | #5 |
Участник
|
Цитата:
Метод RenamePrimaryKey() глючит на связках таблиц при использовании dataareaId. Например, если у вас справочник клиентов в виртуальной компании, то при переименовании первичного ключа, в строках журнала главной книги ссылки могу не переименоваться. Полагаю, что merge тоже может быть не свободен от этого бага, но я не проверял. |
|
07.07.2009, 14:35 | #6 |
Мрачный тип
|
Цитата:
Цитата:
Или переименуется, но не во всех компаниях? Ибо "барабашки нет" (c) mazzy Переименование первичного ключа, равно как и объединение записей должно происходить в 2 итерации :
В этом случае при описанном случае пропуск строк ОЖ с типом счета "клиент" при переименовании виртуального справочника клиентов в принципе не должен происходить. Почему происходит такое? Рискну предположить, что либо вообще вторую итерацию не задействуют, либо задействуют, но не по всем компаниям, входящим в виртуальную
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
07.07.2009, 15:52 | #7 |
Участник
|
Цитата:
Сообщение от TasmanianDevil
Может или не переименуется точно ?
Или переименуется, но не во всех компаниях? Ибо "барабашки нет" (c) mazzy Переименование первичного ключа, равно как и объединение записей должно происходить в 2 итерации :
Ну вы сами попробуйте. Барабашки конечно нет, а глюк есть. Глючит обработка п.2 из вашей схемы. Т.е. ядро пытается для каждой компании из набора компаний составляющих виртуальную компанию выполнить запрос перекодирующий счет и коррсчет в строках журнала ГК, но при генерации запроса на основе relation влезает условие по Ledgerjournaltrans.companyId==CustTable.dataareaID подставляя в запрос код виртуальной компании (вместо реальной, так как в ledgerjournalTrans хранятся ссылки не на виртуальную компанию, а на реальные компании) из-за этого записи остаются необновленными. |
|
07.07.2009, 18:26 | #8 |
Мрачный тип
|
Реальный баг
Игнорирование в п.2 Relations по компании на нашу таблицу, входящую в виртуальную компанию и по которой мы хотим сделать merge()/renamePrimaryKey() должно помочь вроде ...
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|