Если нет достойных аргументов (а их почти никогда нет), то своим подчиненным я разрешаю пользоваться только RPC функциями, объявленными на transaction objectе, а Embedded SQL запрещаю.

Должно быть понятно, что когда я написал "запрещаю", то слегка утрировал :-)

С "лучше и проще применять именно Embedded SQL" , штука вот какая.
Когда тебе надо быстро и просто достать из БД ОДНО значение какого нибудь флага, то конечно Embedded SQL выглядит заманчиво.
Проблема в том, что через месяц оказывается, что тебе надо было не один флажок из этой чертовой таблицы в этом событии/функции достать, а 3, а ещё через пару месяцев оказывается, что в эту таблицу добавили ещё пару тройку колонок, без которых твоё событии/функция ну просто как без рук, и т.д. и т.п. Ты продолжаешь менять свой чёртов Embedded SQL, количество локальных переменных (а соответственно и инстанс, в которых ты флаги держишь) растёт, и все это превращается в классический спагетти код.
Вот если б у меня был instance datastore, да ещё и не системный, а мой, который я заточил под доставание флажков которые так позарез моей событии/функции нужны, как бв всё было просто...

Ну а про то когда надо многорядный Result Set тащить, то вообще о чём говорить?
Во-первых datastore/datawindow делает block reads, а курсор тянет по одному ряду, лупы надо писать, локальные переменные и вся лабуда...
Во-вторых datastore - умная datastructure, в которой уже все для итерирования, поиска и сортировки всё написано...

Ermak , если б кто из моих подчинённых "для проверки введенных значений использовал глобальные функции, в которых применял embeded SQL и считал, что это оправдано", то очень быстро стал это считать в другом месте работы :-)

ASCRUS , что то у вас в России с юмором произошло? :-)

Конечно уволить я никого за embedded SQL не уволю, но если увижу, то заставлю поменять :-)

Опять же вы углядели мою неприязнь к глобальным функциям (что правда), а в данном случае речь об embedded SQL идёт.
Тем не менее скажу вот что. Я считаю, что прелесть изобретенного Powersoftom dataobjecta заключается в том что он самодостаточен и самоописуем. Вставлять в него глобальные функции, значит увеличивать зависимость на внешние по отношению к нему факторы, я против этого.

Ermak , я начинал заниматься РВ в начале расцвета классического client/servera, основными принципами было следующее
1) Minimize network traffic
2) Maximize processing on the client
3) If possible, move processing to the data, not data to the processing.

Пример, который вы привели - проверка парвильности введённых данных против СТАТИЧНЫХ наборов кодов с помощью походов с клиента в БД - классический образец увеличения network traffic ни за что ни про что.
Даже если вы не используете dddw, кашировать наборы кодов на клиенте - гораздо злегантнее, чем database hits.
Если вы эти свои проверки в pre-update logic устраивали, это ещё пол беды, но вы же их небось в itemchanged event исполняли...

Ermak говорил "про использование свойства validation exp. для datawindow column." :-)
Так вот и я о том же. Это значит, что у вас на КАЖДОМ itemchanged - database hit. Вот это и называется безобразие.
Давайте на секунду представим, что подобное validation exp (с глобальной функцией зовущей Embedded SQL) у вас сидит на колонке с dddw edit style.
Знаете что происходит, когда пользователь имеет фокус в такой колонке и жмет Up/Down Arrow Keys? Правильно, itemchanged event, причём с такой же скоростью, как repeat rate у keyboarda, и с такой же скоростью летят ваши database hitы. Вот так в вырожденным случае выглядит суть вашего подхода :-)

Кэшировать активно пополняемые справочники (7-10 тыс. записей) , а так же пытаться из них делать dddws я безусловно не рекомендую, но валидировать данные в момент их изменения (а НЕ при попытке update), тоже несколько странно...

К слову сказать, dddw для организации справочников мне не нравится (прооблемы с навигацией)

Какие проблемы с навигацией? Не понимаю.
При нормальных размерах справочников (< 100), лучше чем dddw для организации этого дела придумать что либо трудно, поэтому уже долгие и ПРОВЕРЕННЫЕ годы применятся в тысячах РВ приложений.