И,наконец, в наглую перебрасываю третий вопрос !
При корректировке через View мы полностью отрезаны от всяких ограничений,правил,чеков, действующих
на входящие в запрос таблицы. При этом надо готовиться к многосложному диалогу с сервером на предмет различных ограничений. Мы на нашем предпр считаем, что не надо давать юзеру возможности ошибаться еще во время ввода
данных.
Если знаешь таблицы-источники, то при корректировке из View надо выдать отдельные
Update по каждой из таблиц.
Хотелось бы знать, какая колонка данного View какой колонке какой таблицы
соответствует, тогда можно в момент ввода выполнять проверку уникальности, наличия соотв ключа, соответствие CHECK ...
Смысл вопроса :
Надо средствами T-SQL получить ПОЛНУЮ информацию о происхождении колонок представления,
то есть для первой колонки узнать ее <Tabl>.<Column> источника, и не является ли колонка представления выражением и т.д.
Обращение к INFORMATION_SCHEMA либо к стандартным ХП (которые я пока знаю) не дают точного ответа.
Зная источники, можно правильно закрывать от редактирования колонки гридов, строить UPDATE команды к таблицам источников... А все эти мышиные оболочки (ЕМ,QA) меня не интересуют - их в приложение не вставишь!
Интересно, но в разрещенных для модификации через View случаях корректировка идет нормально, то есть несмотря на возможные переименования сервер знает, куда класть данные
В данных примерах все работает
create view v1 as select t1.k1 as 'x1' from t1
update v2 set x2='99' where x1='01'
create view v2 as select t1.k1 as 'x1',t2.k2 as 'x2' from t1,t2 where t1.k1=t2.k2
update v2 set x2 ='99' where x2 ='01'
и даже крестом
update v2 set x2 ='99' where x1 ='01'

При этом Я не знаю, чему соответствует х1 или х2 (не обращаясь ни к каким оболочкам), а сервер разложит данные ровно туда, куда надо ! Вот это куда надо меня и интересует !
Изложение немного сумбурное, но я здесь собрал несколько мессагов из Вопрос-Ответ

2Garya
Конечно, если разработчик клиента и серверной части - 2 в одном флаконе, то он знает все!
Мы за многолетнюю работу на крупном предприятии давно убедились, что клиентская часть должна как можно меньше
зависить от изменений на сервере. Тогда не приходится постоянно держать руку на исходниках ..., реже заменяются приложения на клиентских машинах ... Конечно, есть значительная часть приложений, в которых достаточно жестко прописаны составы таблиц и характер связей и правил, многое из чего просто не подлежит обсуждению и изменениям.
Но даже в них (в этих приложениях) весомая часть функциональщины может реагировать на некоторые настойки, и весьма существенно.
Есть чисто адаптивные приложения, работающие от метаданных.
В любом случае, если бы нами не были разработаны подобные механизмы, врядли я смог сидеть в форуме при почти 30 АРМах
на сотне мест в 5-7 службах завода.
Так что не хакер я !
Просто ищу возможности для разработок гибких приложений в среде СКЛ2к а в настоящее время имею нерешенный вопрос.
Предложение использовать VIEW_METADATA интересно как частный случай, и триггеры можно отследить.
Проще показать на примере:
Пусть некое представление корректируется. В нем есть колонка, являющаяся РК из некой таблы. Зная источник, при ВВОДЕ можно проверить уникальность значения и не пустить далее. Другая колонка - FK и при ее набивке можно проверить значение. Если после сдачи в эксплуатацию задачи на сервере будут введены ограничения типа CHECK с Like , либо введены еще какие-то дополнительные связи, то задача могла бы правильно реагировать на эти изменения. При этом клиентское прложение вообще не претерпело бы изменений !
Все связи и граничения достаю, НО НЕТ МОСТИКА между источником данных и колонкой!
А вот еще прелесть - не зная источника строкового поля я не знаю и допустимой длины данного во время ввода. А Вам не приходилось даже при вводе в ТАБЛ через "гибкие" оболочки ЕМ или QA получать сообщения о превышении длины? Причем это после отработки ВСЕЙ строки !