Помогите решить проблему с копированием rtitem с аттачментами

[Gandliar]

Привет!

Есть 2 базы данных, рабочая и база с настройками.
В рабочей запускается скрипт, который создает документ в текущей базе и запускает агент в базе с настройками, передавая этот созданный документ (runwithdocumentcontext)
Агент в базе с настройками заполняет в переданном документе поля из настроечного документа. копирует айтемы, в том числе ричтекстовые.
Затем скрипт из рабочей базы открывает новый документ (заполненный агентом) на редактирование.

Проблема, если база с настройками не открыта, аттачменты не открываются с ошибкой "Указанная база не открыта - невозможно сохранение в файл"
Если открыта на рабочем столе или в дизайнере - все открывается штатно.

Сама идея - код по заполнению настроек (в том числе файлы шаблонов документов) вынести в единую базу.

Однако вылазит проблема, что richtextitem не копируется полноценно в документ контекст. Как бы такое победить?

 

[Gandliar]

По итогу проблема не с документом контекстом, а проблема в копировании ричтекстайтемов из одной базы в другую. Копирует видимо только ссылку на аттачменты.
Проблем с копированием из текущей в текущую и последующим открытием несохраненного документа нет. Наверное придется продублировать настроечные документы в целевой базе данных и обновлять их по мере надобности.

 

[VladSh]

Можно попробовать не копировать RichText-поля с вложениями, а выкладывать вложения на диск, а потом, при создании документа в другой базе вкладывать программно, сохранять документ и открывать на экране. Что-то такое припоминается... наверное так решали, точно не помню.

 

[Gandliar]

Можно попробовать не копировать RichText-поля с вложениями, а выкладывать вложения на диск, а потом, при создании документа в другой базе вкладывать программно, сохранять документ и открывать на экране. Что-то такое припоминается... наверное так решали, точно не помню.

Да, это тоже вариант. Спасибо!
С ним сложнее, так как целевой документ не хочется сохранять сразу - мало ли пользователь передумает создавать.
А если не сохранять, то и файлы сразу не удалишь временные, надо думать как их удалять потом не забыть.
Пока что проще через сохраненный документ-прокладку работать, так как он еще и переиспользуется многократно.

 

[VladSh]

У меня был общий код... Выкладываем документы на диск, затем в новый док в несохраняемое поле прописываем пути к файлам, вроде на QueryOpen вычитываем в глобальную переменную на подформе массив файлов, дальше - если массив не пуст, то производилось вложение файлов, а удалялись файлы при закрытии документа - это можно на Onunload или даже на Terminate. Удобно тем, что вся работа с файлами производилось в одном и том же элементе дизайна - спец. подформе.
Мы эту функциональность использовали в самописной CRM'ке при импорте писем из почты. Жали кнопку в виде, на которой из Inbox'а выбиралось письмо, создавался новый док и т.д., как дальше описано выше.

 

[Мыш]

Да, это тоже вариант. Спасибо!
С ним сложнее, так как целевой документ не хочется сохранять сразу - мало ли пользователь передумает создавать.
А если не сохранять, то и файлы сразу не удалишь временные, надо думать как их удалять потом не забыть.
Пока что проще через сохраненный документ-прокладку работать, так как он еще и переиспользуется многократно.

А если копировать весь документ целиком? Потом копию "причёсываем" - удаляем ненужные поля, добавляем нужные... Правда, проблему с временными данными это не решит, т.к. будет временный док-т...

 

[VladSh]

А если копировать весь документ целиком? Потом копию "причёсываем" - удаляем ненужные поля, добавляем нужные... Правда, проблему с временными данными это не решит, т.к. будет временный док-т...

Хорошая идея. Но при сохранении того же дока м.б. ошибка переполнения таблицы полей БД на старых Лотусах в случае, когда в копируемом доке много левых полей. Мы с таким недавно столкнулись. Проблема в том, что сохранить-то такой док оно даёт, но потом база данных в совершенно неожиданных местах сыпет такими ошибками переполнения. И исправить это очень непросто. У нас получилось только программно удалив этот документ и сделав новую реплику с документами, иначе никакие факсапы и компакты не помогали.
Конечно ситуация наиредчайшая, но решил всё же сказать об этом, чем нет.

 

[Мыш]

Хорошая идея. Но при сохранении того же дока м.б. ошибка переполнения таблицы полей БД на старых Лотусах в случае, когда в копируемом доке много левых полей. Мы с таким недавно столкнулись. Проблема в том, что сохранить-то такой док оно даёт, но потом база данных в совершенно неожиданных местах сыпет такими ошибками переполнения. И исправить это очень непросто. У нас получилось только программно удалив этот документ и сделав новую реплику с документами, иначе никакие факсапы и компакты не помогали.
Конечно ситуация наиредчайшая, но решил всё же сказать об этом, чем нет.

Это да. Но и способ этот тоже не от хорошей жизни придуман был. В былые времена Domino так криво "айтемизировал" некоторые док-ты, полученные, скажем, по эл. почте, что нормально работать с аттачами в них иногда получалось только через GUI клиента. Даже бота пытались писать, который бы имитировал нажатия клавиатуры/мыши для извлечения аттачей.