Почтенные, объясните плиз, что за нелепое поведение логики фиксации
изменений в навижн?
Пользовтель заполняет форму (изменяет запись), затем происходит попытка фиксации
записи, и в случае неудачи (валидации значений и т.д.) отменяется весь пользовательский
ввод (все изменения записи)? Насколько я понимаю, изменение значения какого-либо
поля само по себе не вызывает попытки фиксации записи; за что же так жестоко карать,
убивать все изменения полей в форме при неудачной попытке фиксации записи?
Может быть, у меня неверное представление, или таким поведением можно как-то
управлять - выключить такой вот откат изменений данных на форме?
Это же кошмар какой-то...я пока даже не очень представляю, как при такой реализации
правильно реализовать валидацию данных без утраты пользовательского ввода...
НАВ 4, но утверждают, что и в следующих версиях всё то же самое.


Пресветлый старец Фалоим Московскый.
тимтэг:некоммерческое товарищество "Напиджак",
издательство "Московский Пустомолец"

Remarks
http://msdn.microsoft.com/en-us/library/dd355319

This trigger executes before the default modify behavior is executed. If an error occurs in the
trigger code, the record changes are canceled.

We recommend that you do not include code that can stop the user from recording a change in
the OnModify trigger on a table. For example, do not include code for displaying error messages.
If a user has previously changed the contents of some fields in a record, then these changes
must always be accepted by the system .

ЗЫ: почему-то вспомнилось выражение: "парламент-не место для дискуссий".

iscrafmМистерШоуЗЫ: почему-то вспомнилось выражение: "парламент-не место для дискуссий".
OnValidate вместо OnModify

? я в описании не увидел валидэйт уровня записи таблицы или формы.

Tables have the following triggers.
Table trigger Executes when
OnInsert Trigger
A new record is inserted into the table.
OnModify Trigger
A record in the table is modified.
OnDelete Trigger
A record in the table is deleted.
OnRename Trigger
A record is modified in a primary key field

А вот этот триггер:
OnBeforePutRecord Trigger
Executed before a record is saved.
Applies To Forms
If there is an error in the trigger code, the form is closed.

и вовсе озадачил своей применимостью. Видимо, для тех, кто считает,
что просто убить весь пользовательский ввод - это слишком мягко,
нужно ещё и форму закрыть :)

шутю - понятно, что каждая система имеет право на фичу,
а кто не доволен -чемодан/вокзал/ивропа. То есть, десятьтыр/Селезнёвка/1с :)

iscrafmДжекНепотрошительс точки зрения пользовательского интерфейса, система ужасна настолько, насколько это в принципе может быть возможно для GUI-приложений
да ладно. Это на фоне чего?

скепсис понятен, но фейс конечно типичное УГ больших серьезных систем.
Как и в OEBS - функционально, однообразно, масштабируемо, скучно до зевоты.
Фейс, кажущийся кошмаром после домашнего уюта уникальных форм самопальных систем,
где заботливый карманный прог использовал 256 цветов, кучу полезных кнопок,
закладок и т.д. :)
Вот 1С заметил в бухгалтере женщину, не зря в заставке на фоне гроссбухов
эта романтичная розочка - это вообще, имхо, мегагениальное
маркетинговое проникновение в подсознание, "этим только и берут они"(с).

iscrafmМистерШоу? я в описании не увидел валидэйт уровня записи таблицы или формы.
это уровень Field. Вообще, чуть выше один из принципов описан. Сохранять все, а вот учитывать только валидное.

хороший принцип, только в распределенной БД на регулярных репликах уход некорректной
НСИ на места собственно учета - нервное дело. Имхо, продуктивнее при вводе НСИ
добиваться верного состояния, чем потом при учете ловить.

iscrafmМистерШоу? я в описании не увидел валидэйт уровня записи таблицы или формы.
это уровень Field. Вообще, чуть выше один из принципов описан. Сохранять все, а вот учитывать только валидное.

тут простая проверка заполненности обязательных полей в NAV для чужеземца вроде меня
становится делом нетривиальным...я уже испорчен распространенной техникой
валидации при записи с сохранением состояния формы :)

iscrafmМистерШоуКак и в OEBS - функционально, однообразно, масштабируемо, скучно до зевоты.
это какие-то парадоксы рассказываете. На фоне OEBS что-ли интерфейс Навижина ужасен?

я скорее пытался сказать, что оба одинаково тоскливы.

iscrafmСохраните, а потом валидолом кормите уже сохраненное, перенося
правильное в чистовик и оставив пользователя в покое

То есть сделать буферно-карантинную систему?
Одна таблица-буфер накапливает, а потом валидирующей процедурой переваливать в
конечную. Вполне себе выход :) Я также задумался о буфере, только
как над предварительным сохранением значений контролов перед записью, но увы, не
вижу события для подъёма из этой структуры данных.

ОК, коллеги, благодарен за внимание и наставление!