stavteamУ меня весь смысл приложения - динамически формировать весьма сложные запросы. Но сложность будет только в условии where, в остальном - это простой запрос из одной таблицы.
В таком случае я бы попытался перенести логику на сервер (источником формы сделать stored procedure).

Да тут "обходной путь"-то, надо сказать, довольно-таки прямолинеен. По утверждению автора вопроса, у него все страшные выражения, которые делают запрос необновляемым, сосредоточены в критериях отбора и как я понял, их роль всего лишь - вычислить значение, с которым нужно сравнить для выполнения отбора в тривиальном однотабличном наборе записей.

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

А с updatable views, построенных на INSTEAD OF триггерах - не советую без необходимости связываться. Только в случае, когда без них точно не обойтись. Я уже ходил этой дорогой, набил шишек.

yuniki Тимур РахимовА с updatable views, построенных на INSTEAD OF триггерах - не советую без необходимости связываться. Только в случае, когда без них точно не обойтись. Я уже ходил этой дорогой, набил шишек.
А что за шишки, если не секрет?
Да там на каждом шагу.

Ну, на грабли с WITH VIEW_METADATA , похоже, каждый наступил.

Про неочевидную необходимость включать в список полей представления ключевые поля всех таблиц (хоть Access и не будет заниматься собственно обновлением) - говорил уже.

Засада на ровном месте с автоинкрементными ключевыми полями (счётчика):
MS SQL Server требует, чтобы вставке записи в обновляемое представление все поля, которые определены как not null ( включая счётчик! ) содержали какое-либо, пусть фиктивное, которое никак не будет использоваться, но значение. Надо ли напоминать, что в поле счётчика Access не позволяет ничего вставить?

Далее. INSTEAD OF триггеры несовместимы с механизмом foreign constraints (FK) - все проверки приходится кропотливо выполнять "руками". Любая ошибка в таких триггерах снимает весь текущий batch начисто, не оставляя никакой возможности коду на T-SQL ни поправить как-то ситуацию, ни даже получить код ошибки. И то и другое резко осложняет программирование. И это ещё не всё! Чтобы легче можно было представить масштаб проблемы, я процитирую одного исключительно компетентного человека:

Crimean...Делать это в INSTEAD триггере красиво, но писать много INSTEAD триггеров - пусть меня лучше покрасят. Глюкалово такое что ну его. Хватит мне одного инстедного триггера на всю систему. В нем ифов больше, чем во всей системе вместе взятой...

...У меня было несколько другое представление о триггерах.
Я считал, что если у меня есть софта, которая месит таблицу, то после добавления триггера (любого!) софту менять не надо.
На деле - ХРЕН!!! Переписывать софту на (зачеркнуто) к (зачеркнуто) в (зачеркнуто), короче, полностью! Плюс к этому написание процедур, через которые ТЕПЕРЬ начинается работа с таблицей, чтобы отвалить триггера ролбэчить и хоть как-то вменяемо прередать Ид из триггера в софтину. Ужас!...

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

Чтобы убедиться во всём этом, наберите в строке поиска (в конференции Microsoft SQL Server) слова instead триггер и посмотрите сами (в частности, "Crimean" гораздо больше моего багов наловил).

геоОчень странно. Все странно.
Действительно, странно. Я тоже попробовал, но уже на Access 2000 SP3 (SQL Server 2000 SP3). Создал всё с нуля: тестовую базу данных, новый файл adp, простейшие три таблицы с PK, единственную форму... Источник строк формы такой:


Обновляется! При этом свойства формы Однозначная таблица и Строка синхронизации пусты. Я вообще никаких свойств формы после того, как она была создана конструктором, не менял!

В общем, всё в точности так, как указал "Geo".

Может, яснее станет, если автор вопроса укажет версии своих программ и сам проверит наличие проблемы на тестовом примере "с нуля"?