Не Сохраняется Документ. Создается Лишняя Копия.

@Somshyzz86 · Регистрация: 18.06.2010

Author24 — интернет-сервис помощи студентам

Помогите решить проблему.

Есть агент, который создает документ копированием. После заполнения полей пытаюсь сохранить док, но сохраняется
еще одна копия документа, при этом половина полей заполнена в одном, половина в другом.
З.ы. Ранее агент работал корректно.

Вот часть кода.

LotusScript

Function CreateProcess(mgr_doc As NotesDocument, target_db As NotesDatabase) As NotesDocument
On Error GoTo er
 
Dim example_doc As NotesDocument
Dim Process As NotesDocument
Set example_doc = target_db.GetDocumentByUNID("4B8361C435F3454544257D5100437C8C")
Set Process = example_doc.CopyToDatabase( target_db )
 
Process.Form = "Process"
 
здесь просто заполение полей
даты
основные поля
 
допонительная информация
 
 
Process.UniversalID = mgr_doc.MaimProccesID(0)
WriteLogToFile( "Process.UniversalID установлен: # " + Process.UniversalID)
 
 
Call Process.ComputeWithForm( False, False )
Call Process.Save( False, False )
 
Set CreateProcess = Process
 
Exit Function

@sovt · 14.09.2014, 10:27

Где вызов функции и где инициализация второго параметра target_db
По коду:

LotusScript

Set example_doc = target_db.GetDocumentByUNID("4B8361C435F3454544257D5100437C8C")
Это получение в базе назначения документа по UNID
 
Set Process = example_doc.CopyToDatabase( target_db )
А вот это уже в этой же базе назанчения создание копии документа.

Здесь нигде нет копирования из одной базы в другую, тут только копирование в пределах одной базы.

@Somshyzz86 · 14.09.2014, 11:00

Сообщение от savl

Где вызов функции и где инициализация второго параметра target_db
По коду:

LotusScript

Set example_doc = target_db.GetDocumentByUNID("4B8361C435F3454544257D5100437C8C")
Это получение в базе назначения документа по UNID
 
Set Process = example_doc.CopyToDatabase( target_db )
А вот это уже в этой же базе назанчения создание копии документа.

Здесь нигде нет копирования из одной базы в другую, тут только копирование в пределах одной базы.

Все происходит в одной базе.
Я беру документ по UNID, делаю его копию, после меняю почти все поля, в том числе и UNID нового документа.
После пытаюсь сохранить, но при этом создается еще один документ.
Т. е. я имею в итоге исходный док, промежуточный, который создан командой CopyToDatabase и документ созданный после сохранения.
Ранее у меня все это работало. Получалось два дока. Исходный и новый с измененым UNID. Почему так происходит не могу понять уже 2 дня.

@hosm · 14.09.2014, 11:33

до замены унида сохранение есть?

@Somshyzz86 · 14.09.2014, 11:53

Сообщение от OKEN

до замены унида сохранение есть?

Нет. Вся функция в первом сообщении. Удалил только кучу строк с Call Process.ReplaceItemValue("","")
При этом после вызова: Set Process = example_doc.CopyToDatabase( target_db ) в базе появляется документ

Недавно пересоздал базу. Может где настройка бд не правильная?

@sovt · 14.09.2014, 11:54

CopyToDatabase - сама по себе уже сохраняет документ...
Новая копия создается только если меняется UniversalID проверял на 9-ке.
Если 2 дня назад работало, то недавно обновляли сервер/клиент?
Впрочем, может это так и в 8-ке работает.

Мой совет: заменить CopyToDatabase на CreateDocument.
Далее копируете необходимые поля и меняете UNID до первого сохранения.

Добавлено: OKEN
Ага, при CopyToDatabase

@Somshyzz86 · 14.09.2014, 12:07

Сообщение от savl

CopyToDatabase - сама по себе уже сохраняет документ...
Новая копия создается только если меняется UniversalID проверял на 9-ке.
Если 2 дня назад работало, то недавно обновляли сервер/клиент?
Впрочем, может это так и в 8-ке работает.

Мой совет: заменить CopyToDatabase на CreateDocument.
Далее копируете необходимые поля и меняете UNID до первого сохранения.

Добавлено: OKEN
Ага, при CopyToDatabase

Да, все логично. Поставил в тупик тот факт, что ранее агент работал. Вот и пытаюсь понять как он работал.

@omdry · 14.09.2014, 12:35

А параметра CopyToDatabase_New_UNID со значением "1" в ini-файле случаем нету ?

Если да - то вот эта строка создает и сохраняет док с новым UNID:
Set Process = example_doc.CopyToDatabase( target_db )

Вот эта строка меняет у созданного дока UNID на другой
Process.UniversalID = mgr_doc.MaimProccesID(0)

А вот эта приводит к созданию еще одного документа, т.к. UNID установленный при CopyToDatabase изменен
Call Process.Save( False, False )

@Somshyzz86 · 14.09.2014, 13:06

Сообщение от Andre

А параметра CopyToDatabase_New_UNID со значением "1" в ini-файле случаем нету ?

Если да - то вот эта строка создает и сохраняет док с новым UNID:
Set Process = example_doc.CopyToDatabase( target_db )

Вот эта строка меняет у созданного дока UNID на другой
Process.UniversalID = mgr_doc.MaimProccesID(0)

А вот эта приводит к созданию еще одного документа, т.к. UNID установленный при CopyToDatabase изменен
Call Process.Save( False, False )

Параметра в notes.ini нет. Сейчас все происходит как описано. Интересно, почему ранее сохранялась одна копия?

@sovt · 14.09.2014, 13:11

Andre
Ну данный параметр был нужен для исправления ошибки CopyToDatabase, по которой новый UNID как раз таки НЕ генерился.
Это исправили, начиная с 7-ки такого больше нет.
Так же данный параметр для сервера.
Может быть он и работает.

Добавлено:

Интересно, почему ранее сохранялась одна копия?

Изменения были?
Сервер переустанавливали? Клиентов? Машины меняли?
Код где отрабатывает?

@omdry · 14.09.2014, 16:02

Сообщение от savl

Ну данный параметр был нужен для исправления ошибки CopyToDatabase, по которой новый UNID как раз таки НЕ генерился.
Это исправили, начиная с 7-ки такого больше нет.

А откуда такая информация, что начиная с 7 этого нет ?

Согласно вот этим ссылкам - очень даже есть, и в качестве фикса предлагается использовать переменную в notes.ini :
Documents copied using CopyToDatabase method reuse same UNID
Some documents created using the LotusScript CopyToDatabase method do not replicate as expected

Допускаю, что при установке клиента или сервера последних версий (или начиная например с 8) этот параметр прошивается автоматически в ini-шку.
Но чтобы менялось поведение метода на противоположное (создание нового UNID вместо сохранения оригинального), вроде информации не встречал.

P.S. Да и функциональность по умолчанию с "сохранением" оригинального UNID бывает очень полезной, например при архивации.

@sovt · 14.09.2014, 16:31

Andre
Нет данного параметра на сервере, проверил на наших (правда у нас 8-9), так что если и прошивается, то где-то глубже.
Либо сам метод переопределили, за IBM это водится. Опять же, может настройка и работает, проверять не буду, так как это серверная часть.
Да и на локале это работает именно так - новый UNID, по факту тот же сервер.
Ну и SPR# ASHW4X9P8R
Однако, справедливости ради стоит отметить, что если документа с таким UNID в базе нет, то копирование таким образом - сохранит первоначальный UNID, но вот если уже есть - создаст новый.
Для первой архивации документа да, это хорошо, для второй (если был восстановлен) - нет.
Лучше использовать запасной вариант с CWC-полем UNID.
А для копирования: связку - CreateDocument + copyAllItems.

Добавлено:

Но чтобы менялось поведение метода на противоположное (создание нового UNID вместо сохранения оригинального), вроде информации не встречал

Да сам так же - опытным путем узнал.

@omdry · 14.09.2014, 19:40

Сообщение от savl

Нет данного параметра на сервере, проверил на наших (правда у нас 8-9), так что если и прошивается, то где-то глубже.
Либо сам метод переопределили, за IBM это водится. Опять же, может настройка и работает, проверять не буду, так как это серверная часть.
Да и на локале это работает именно так - новый UNID, по факту тот же сервер.

Ну и SPR# ASHW4X9P8R

Спс, посмотрел.
Вроде, как все то же самое, поведение метода не меняли - ввели параметр в ini - хочешь включай, хочешь выключай. И это вроде-как единственный фикс по этому методу.

Сообщение от savl

Однако, справедливости ради стоит отметить, что если документа с таким UNID в базе нет, то копирование таким образом - сохранит первоначальный UNID, но вот если уже есть - создаст новый.

Тут все логично, как в букваре и написано.
Хотя, на самом деле, при таком копировании сохраняются только последние 16 символов из UNID и ЕМНИП простое сравнение не покажет идентичноcть UNID. Но к теме топика это не относится

Сообщение от savl

Для первой архивации документа да, это хорошо, для второй (если был восстановлен) - нет.
Лучше использовать запасной вариант с CWC-полем UNID.
А для копирования: связку - CreateDocument + copyAllItems.

Ну, если уж строить архивацию на этом методе, то и про подводные камни и варианты спасения в случае ЧП подумать заранее. Поле CWC обычно дублирует UNID - это да, есть такое дело.
Тут советов и рекомендаций не давал, просто привел в качестве возможного примера использования ;-)

@hosm 0 / 0 / 0 Регистрация: 15.05.2009 Сообщений: 1,454
	14.09.2014, 11:33	4
	до замены унида сохранение есть? 0

@Somshyzz86 0 / 0 / 0 Регистрация: 18.06.2010 Сообщений: 69
	14.09.2014, 11:53	5
	Сообщение от OKEN до замены унида сохранение есть? Нет. Вся функция в первом сообщении. Удалил только кучу строк с Call Process.ReplaceItemValue("","") При этом после вызова: Set Process = example_doc.CopyToDatabase( target_db ) в базе появляется документ Недавно пересоздал базу. Может где настройка бд не правильная? 0

@sovt 0 / 0 / 0 Регистрация: 27.10.2011 Сообщений: 2,124
	14.09.2014, 11:54	6
	CopyToDatabase - сама по себе уже сохраняет документ... Новая копия создается только если меняется UniversalID проверял на 9-ке. Если 2 дня назад работало, то недавно обновляли сервер/клиент? Впрочем, может это так и в 8-ке работает. Мой совет: заменить CopyToDatabase на CreateDocument. Далее копируете необходимые поля и меняете UNID до первого сохранения. Добавлено: OKEN Ага, при CopyToDatabase 0

@Somshyzz86 0 / 0 / 0 Регистрация: 18.06.2010 Сообщений: 69
	14.09.2014, 12:07	7
	Сообщение от savl CopyToDatabase - сама по себе уже сохраняет документ... Новая копия создается только если меняется UniversalID проверял на 9-ке. Если 2 дня назад работало, то недавно обновляли сервер/клиент? Впрочем, может это так и в 8-ке работает. Мой совет: заменить CopyToDatabase на CreateDocument. Далее копируете необходимые поля и меняете UNID до первого сохранения. Добавлено: OKEN Ага, при CopyToDatabase Да, все логично. Поставил в тупик тот факт, что ранее агент работал. Вот и пытаюсь понять как он работал. 0

@omdry 0 / 0 / 0 Регистрация: 25.07.2004 Сообщений: 109
	14.09.2014, 12:35	8
	А параметра CopyToDatabase_New_UNID со значением "1" в ini-файле случаем нету ? Если да - то вот эта строка создает и сохраняет док с новым UNID: Set Process = example_doc.CopyToDatabase( target_db ) Вот эта строка меняет у созданного дока UNID на другой Process.UniversalID = mgr_doc.MaimProccesID(0) А вот эта приводит к созданию еще одного документа, т.к. UNID установленный при CopyToDatabase изменен Call Process.Save( False, False ) 0

@Somshyzz86 0 / 0 / 0 Регистрация: 18.06.2010 Сообщений: 69
	14.09.2014, 13:06	9
	Сообщение от Andre А параметра CopyToDatabase_New_UNID со значением "1" в ini-файле случаем нету ? Если да - то вот эта строка создает и сохраняет док с новым UNID: Set Process = example_doc.CopyToDatabase( target_db ) Вот эта строка меняет у созданного дока UNID на другой Process.UniversalID = mgr_doc.MaimProccesID(0) А вот эта приводит к созданию еще одного документа, т.к. UNID установленный при CopyToDatabase изменен Call Process.Save( False, False ) Параметра в notes.ini нет. Сейчас все происходит как описано. Интересно, почему ранее сохранялась одна копия? 0

@sovt 0 / 0 / 0 Регистрация: 27.10.2011 Сообщений: 2,124
	14.09.2014, 13:11	10
	Andre Ну данный параметр был нужен для исправления ошибки CopyToDatabase, по которой новый UNID как раз таки НЕ генерился. Это исправили, начиная с 7-ки такого больше нет. Так же данный параметр для сервера. Может быть он и работает. Добавлено: Интересно, почему ранее сохранялась одна копия? Изменения были? Сервер переустанавливали? Клиентов? Машины меняли? Код где отрабатывает? 0

@omdry 0 / 0 / 0 Регистрация: 25.07.2004 Сообщений: 109
	14.09.2014, 16:02	11
	Сообщение от savl Ну данный параметр был нужен для исправления ошибки CopyToDatabase, по которой новый UNID как раз таки НЕ генерился. Это исправили, начиная с 7-ки такого больше нет. А откуда такая информация, что начиная с 7 этого нет ? Согласно вот этим ссылкам - очень даже есть, и в качестве фикса предлагается использовать переменную в notes.ini : Documents copied using CopyToDatabase method reuse same UNID Some documents created using the LotusScript CopyToDatabase method do not replicate as expected Допускаю, что при установке клиента или сервера последних версий (или начиная например с 8) этот параметр прошивается автоматически в ini-шку. Но чтобы менялось поведение метода на противоположное (создание нового UNID вместо сохранения оригинального), вроде информации не встречал. P.S. Да и функциональность по умолчанию с "сохранением" оригинального UNID бывает очень полезной, например при архивации. 0

@sovt 0 / 0 / 0 Регистрация: 27.10.2011 Сообщений: 2,124
	14.09.2014, 16:31	12
	Andre Нет данного параметра на сервере, проверил на наших (правда у нас 8-9), так что если и прошивается, то где-то глубже. Либо сам метод переопределили, за IBM это водится. Опять же, может настройка и работает, проверять не буду, так как это серверная часть. Да и на локале это работает именно так - новый UNID, по факту тот же сервер. Ну и SPR# ASHW4X9P8R Однако, справедливости ради стоит отметить, что если документа с таким UNID в базе нет, то копирование таким образом - сохранит первоначальный UNID, но вот если уже есть - создаст новый. Для первой архивации документа да, это хорошо, для второй (если был восстановлен) - нет. Лучше использовать запасной вариант с CWC-полем UNID. А для копирования: связку - CreateDocument + copyAllItems. Добавлено: Но чтобы менялось поведение метода на противоположное (создание нового UNID вместо сохранения оригинального), вроде информации не встречал Да сам так же - опытным путем узнал. 0

@omdry 0 / 0 / 0 Регистрация: 25.07.2004 Сообщений: 109
	14.09.2014, 19:40	13
	Сообщение от savl Нет данного параметра на сервере, проверил на наших (правда у нас 8-9), так что если и прошивается, то где-то глубже. Либо сам метод переопределили, за IBM это водится. Опять же, может настройка и работает, проверять не буду, так как это серверная часть. Да и на локале это работает именно так - новый UNID, по факту тот же сервер. Ну и SPR# ASHW4X9P8R Спс, посмотрел. Вроде, как все то же самое, поведение метода не меняли - ввели параметр в ini - хочешь включай, хочешь выключай. И это вроде-как единственный фикс по этому методу. Сообщение от savl Однако, справедливости ради стоит отметить, что если документа с таким UNID в базе нет, то копирование таким образом - сохранит первоначальный UNID, но вот если уже есть - создаст новый. Тут все логично, как в букваре и написано. Хотя, на самом деле, при таком копировании сохраняются только последние 16 символов из UNID и ЕМНИП простое сравнение не покажет идентичноcть UNID. Но к теме топика это не относится Сообщение от savl Для первой архивации документа да, это хорошо, для второй (если был восстановлен) - нет. Лучше использовать запасной вариант с CWC-полем UNID. А для копирования: связку - CreateDocument + copyAllItems. Ну, если уж строить архивацию на этом методе, то и про подводные камни и варианты спасения в случае ЧП подумать заранее. Поле CWC обычно дублирует UNID - это да, есть такое дело. Тут советов и рекомендаций не давал, просто привел в качестве возможного примера использования ;-) 0