|  19.12.2001, 17:14 | #1 | 
| Moderator | Метод Merge 
			
			У таблицы есть метод Merge, который вызывается когда две записи объединяются. Не могли бы Вы объяснить, что здесь имеется в виду ? Когда и каким образом происходит объединение записей ? | 
|  | 
|  21.12.2001, 20:21 | #2 | 
| Administrator | 
			
			К сожалению, не успел проверить, поэтому пишу как есть в Справке. <hr> <b>Синтаксис</b><pre> void merge(common mergeInto)</pre> <b>Описание</b> Этот метод переместит всех потомков, принадлежащих выбранной записи (той, у которой вызывается метод merge), в запись, которая передается как параметр. Запись mergeInto должна существовать. После успешного перемещения запись mergeFrom удаляется. Если возникает ситуация создания записи с уже существующим ключом, происходит ошибка времени выполнения и ttsabort. <hr> Не знаю, насколько это тебе поможет. Как я понял, потомки определяются по внешнему ключу. 
				__________________ Not registered yet? Register here! Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me | 
|  | 
|  07.07.2009, 11:45 | #3 | 
| Мрачный тип | 
			
			merge() на таблице, входящей в виртуальную компанию, отработает только по текущей компании или на всех компаниях, входящих в виртуальную ? P.S. Вопрос снят, отрабатывает правильно по всем, испытание "на кошках" подтвердило - "кошки" живы   
				__________________ Мы летаем, кружимся, нагоняем ужасы ... Последний раз редактировалось TasmanianDevil; 07.07.2009 в 12:31. | 
|  | 
|  07.07.2009, 12:13 | #4 | 
| Участник | 
			
			насколько я знаю, метод merge является устаревшим и уже давно не поддерживается.
		 | 
|  | 
|  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() должно помочь вроде ... 
				__________________ Мы летаем, кружимся, нагоняем ужасы ... | 
|  | 
|  07.07.2009, 19:27 | #9 | 
| Member | Цитата: 
		
			Сообщение от mazzy
			
			 ...метод merge является устаревшим и уже давно не поддерживается... Насколько я помню его еще до 2.5 убрали из пользовательского интерфейса. Т.к. в общем случае он работать не может, т.к. потенциально может привести к нарушению уникальности индексов в связанных таблицах. Думаю что именно поэтому его убрали из пользовательского интерфейса и оставили доступным для программистов, которые понимают что делают. 
				__________________ С уважением, glibs® | 
|  |