Глюки при использовании MS SQL Server 2000

Установил MS SQL Server 2000. Создал пару таблиц, сделал на их основе VIEW. Подцепил к запросу Instead-триггеры. Если добавляю запись в запрос через Query Analyzer используя синтаксис Insert into MyView ..., Instead-триггер срабатывает и все нормально работает. Если открываю этот же VIEW через Enterprice Manager в режиме Open - Return all rows и пытаюсь добавлять записи, Instead-триггер НЕ срабатывает, причем даже не запускается, словно его и вовсе не существует. И то, и другое работает через один и тот же драйвер ODBC. Как вообще такое может быть?
Пошел дальше. Открыл этот VIEW в Delphi через ADO-компоненты и попробовал рабоать с ним оттуда. Instead-триггеров словно не существует!
Еще одна забавная ситуация. Регистрируюсь я и в Enterprice Manager, и в Query Analyzer через sa с явным указанием, что логинюсь с использованием безопасности SQL-сервера (а не Windows NT). При работе через Query Analyzer функция SYSTEM_USER() возвращает 'sa', а через Enterprice Manager - мое сетевое имя в виде DOMAIN\USERNAME. Грохнул регистрацию сервера, сделал заново - то же самое. Кто знает, что это за чудеса?

Я полагаю, что невозможность вставить записи в updatable view через Enterprise Manager и через ADOшный Recordset - это события одного порядка. Потому что если updatить напрямую, то все работает и через ODBC (Query Analyzer) и через OLE DB: cn.Execute ("insert <View c instead-of триггером> (<поля> values (<значения>"). Так что собака, по-видимому, зарыта именно в обновлениях через курсорную dll OLE DB провайдера, потому что курсоры, созданные непосредственно в SQL Server, нормально обновляют этот view. Такиим образом, это проблема не SQL Server, а MDAC 2.6. Я попробую с этим разобраться.
По поводу второго вопроса - у меня system_user ведет себя корректно и там, и там. Например, если создать в табличке вычисляемое поле с этой функцией и открыть ее в EM, то для стандартной безопасности она честно пишет "sa", а не "domain\username".

С нетерпением жду результатов. Вообще-то странно, что до меня никто этого не заметил. Неужели с Instead-триггерами никто не работает?

Еще одно замечание. Если я правильно понимаю, что ODBC, что OLE DB - это всего лишь ИНТЕРФЕЙС обмена информацией с SQL-сервером. После того как SQL-сервер информацию получил, за правильную ее отработку несет ответственность именно он. Какая нужна ошибка в интерфейсной части, чтобы заставить SQL-сервер ЗАБЫТЬ о существовании триггера? Это возможно только в том случае, если интерфейс напрямую пытается работать не с VIEW, а с таблицей (таблицами), на которых этот взгляд построен, выдавая соответсвующие команды SQL-серверу. Однако, в подобную "заумность" драйверов верится с трудом. Что ты думаешь по этому поводу?

Чёй-то как-то все молчат... Может, это только у меня Instead-триггеры не работают? Может, дистрибутив криво крякнули? Отзовитесь, у кого они работают.
А относительно SYSTEM_USER ситуация такая. Я использую ее вызов из UDF (пользовательской функции). Имеется таблица с перечнем имен пользователей, которые в принципе могут работать с рабочими таблицами. При добавлении новых записей в одно из полей рабочей таблицы автоматом заводится код пользователя, который это сделал. Код ищется в таблице пользователей по имени, возвращаемом функцией SYSTEM_USER. UDF используется в качестве DEFAULT-значения специального столбца в рабочих таблицах. Отлаживая эту UDF, я обнаружил, что при работе из Enterprice manager и из Query Analyzer SYSTEM_USER возвращает разные значения.

Все очень просто. Достаточно посмотреть профайлером, что происходит при добавлении. Там явно видно добавление записи и открытие курсора по ИСХОДНОЙ таблице - и соответственно добавление проходит легко. Так что это явно проблема библиотек.

Подобная проблема есть при добавлении записей из Accessa 97 через ODBC. Глюк и впрямь занятный, запись добавляется, а триггер не срабатывает. Помогло после добавления сказать Refresh. Что нужно сказать в Дельфях не знаю, наверно какой-то свой рефреш. Вообще есть ощущение, что ODBC драйвер маленько не дописан.

Эх, только что напоролся на первую проблему из поста (ADO генерит insert не для view, из которой он берёт данные, а явно для таблицы (из которой вьюха селектит); поэтому не срабатывает instead of trigger на вьюхе).

За пять лет, которые прошли с прошлого сообщения в этом посте, решение так и не придумали?

Спасибо

UniqueNick

За пять лет, которые прошли с прошлого сообщения в этом посте, решение так и не придумали?

Решение только одно - вручную генерировать запрос (или работать через хранимую процеудуру, в которой будет такой запрос).

Breakneck

Решение только одно - вручную генерировать запрос (или работать через хранимую процеудуру, в которой будет такой запрос).

УРА! Решилась проблема!
надо указывать опцию WITH VIEW_METADATA при создании вьюхи!

CREATE VIEW ... [ WITH < view_attribute > [ ,...n ] ] AS
...
< view_attribute > ::=
{ ENCRYPTION | SCHEMABINDING | VIEW_METADATA }
VIEW_METADATA

Specifies that SQL Server will return to the DBLIB, ODBC, and OLE DB APIs the metadata information about the view, instead of the base table or tables...