Секция обычная или controlled access?
Если вторая, то убери её или сделай обычную и попробуй.

 

сли DFAccessAdministrationServer на подформе, то попробуй его вынести на основную форму и переименуй, временно, в DFAccessAdministrationServer_tmp, изменяй в коде это поле. Посмотри сохраняется ли? может дело именно в подформе.

Ого, а когда на основной форме, поле сохранилось нормально. Т.е, например, когда сохраняем docThis, созданный по основной форме, поля субформы на этой форме его родными не считаются и живут отдельно?

 

попробуй еще ComputeWithForm(false,false) сразу после создания документа:

db.CreateDocument
replacteItemValue("Form",...)
ComputeWithForm(false,false)

попробуй, может и не надо будет тогда выносить поле на форму.

Подформы я считаю злом, это личное.
Да, удобно хранить там простые кнопки и поля, которые создаются и не изменяются: UNID, кнопки редакктирования, сохранения и выхода.
Но порой лучше без них. события на подформах двойное зло, опять же личное...

Т.е, например, когда сохраняем docThis, созданный по основной форме, поля субформы на этой форме его родными не считаются и живут отдельно?

Да похоже что так, думаю при создании у тебя документ просто не определяет, что такая подформа в форму встроена.
А после переоткрытия документ, внезапно, это осознает... Впрочем возможно это особенность подформ.
Повторюсь: я их не люблю, стараюсь без них.

 

...Но агента я выше показал, ведь он-то не может его испортить....

Интересно. Это какой-то новый способ письма дальнейшая обработка документа?
Если документ создается полностью в бекэнде БЕЗ открытия в УИ - копай именно этот код.
Для бекэнда все равно есть у тебя поля в документе, в сабформе, секции и т.д.
Закомментируй все вызовы агентов... посмотри... все ли правильно отрабатывает в кнопке.
Далее пошагово снимаешь комментарии с логических блоков и снова проверяешь.
Скорее всего - козлит какой-то из возможных агентов обработки.

И опять же... в чистом бекэнде SaveOptions лучше не используй. А то потом долго концы искать будешь

 

ComputeWithForm не помогло. А агент (он только один в коде кнопки) действительно козлит, засранец! Его вызов закомментил - и поле у документа не пустое. Все хорошо, только этот агент статус нужный ставит, без него никак. Хотя казалось бы, он делает только Strcompare.

Интересно. Это какой-то новый способ письма дальнейшая обработка документа?

Да так это, я придумал. А может изобретатели блок-схем до меня

 

Да так это, я придумал. А может изобретатели блок-схем до меня

Сарказм в данном случае неуместен.
Обратился с проблемой - будь добр приводить код.
Тут не структуру/логику приложения обсуждают, а способ реализации и ошибки.
.... либо копай сам.

В том что ты описал - я (и похоже не только я) ошибку не увидел.

А то вот получается "У меня что-то болит" - "Ну так выпей что-нибудь"

 

Ну прости уж, если обидел.

 

.ComputeWithForm(false,false) - не поможет:

Свойства поля DFAccessAdministrationServer: тип Names, Editable, оно скрытое, значение по ум. ""

Кстати, если документ в уи не открывается, то зачем тогда ставится поле SaveOption, при этом само поле не сохраняется (SaveToDisk = False)?
И после обработки документа агентом, возможно, надо его переполучить заново из БД, так как документ из кода в кнопке может не подхватить изменения, которые сделал агент в документе (для серверных агентов (RunOnServer) - точно не подхватывает, да и если просто по Run вроде тоже).

 

Спасибо, OKEN, все получилось. В конец кода кнопки вставил вызов агента, который выполняется на клиенте и меняет нужные поля. Всем большущее спасибо.