2Павел. В A2K действительно у формы имеется свойство "уникальная таблица", которая позволяет "обмануть" необновляемость набора данных. На самом деле это просто прием, который используется исполняющей системой на самом клиенте - вместо работы с источником данных, который вернул запрос, A2K производит операции вставки/изменения/удаления с уникальной таблицей, которая специально указана как базовый источник данных. В общем случае уникальная таблица может вообще никакого отношения не иметь к данным, возвращенным в запросе ( это я к тому, что следует различать действительно обновляемый набор данных и всякого рода обманки, выполняемые на клиенте). Если параметризованный запрос выполнить через ADO, при условии что аналогичный НЕпараметризованный запрос также возвращает обновляемый набор данных, на клиенте появляется Bookmarkable recordset (терминология OLEDB), который и является условием обновляемости набора данных. Если, к примеру, в Delphi такой набор данных просвечен через DBGrid, то ты можешь непосредственно в нем модифицировать данные, не прибегая ко всякого рода обманкам. Модификация приводит к обращению на SQL-сервер напрямую к нужной записи через механизм Bookmark (меток записи).
2 Dmitry. Лови ссылочку на статьи (там много интересных, включая ту, о которой я говорил) http://www.microsoft.com/rus/sql/rusdocs.html.

2 Павел. Возможно, ты в чем-то прав, и я не совсем корректно попросил привести текст на T-SQL, доказывающий обновляемость набора данных. Однако, в OLEDB такое понятие существует. Известно, что хранимые процедуры возвращают необновляемый набор данных. Если открыть в ADO набор данных, возвращенный SP, то он В СВОЙСТВАХ ADO.Recordset покажет, что набор необновляемый. Ежели выдать команду select ..... чего-нибудь откуды-нибудь, то можно получить набор данных как обновляемый, так и не обновляемый. Вариант указания уникальной таблицы относится к конкретному инструментарию (Access-2000), и более нигде не катит. В Delphi также есть компоненты, выполняющие аналогичные обманные телодвижения. Кстати, в отличие от A2K, в них можно даже сделать так, что вставка будет идти в одну таблицу, модификация будет выполняться над второй, а удаление - в третей. Трудно себе представить, кому такое может понадобиться, но все это сказано лишь с целью подчеркнуть ориентированность определенных приемов на определенный инструментарий. Я же отвечал вообще - без привязки к конкретному инструментарию, а только к механизмам ADO, которые ведут себя схоже в любом инструментарии.
Когда ты в EM открываешь таблицу и модифицируешь в ней строку, то на сервер приходит команда не Update... (которую в аналогичной ситуации формирует A2K), а "exec sp_executesql N'UPDATE......". И еще несколько строк. Подобные строки может формировать ODBC-драйвер, само приложение, а может формировать OLEDB-провайдер, который в общем случае от используемого на клиенте инструментария независим. Вот я о чем.

Я пересказал то, что вычитал (насколько помню, у Дженнингса). Видимо одного свойства Bookmarkable=True недостаточно для того, чтобы получить обновляемый набор данных (однако, если Bookmarkable=false, то набор данных однозначно необновляемый). Видимо, я не совсем правиИнтересно, а что выдаст Debug.Print rst.Supports(adAddNew)? Полагаю, что в первом случае True, а во втором False.

Отвлекли ... случайно нажал "отправить". Я хотел сказать, что видимо, не совсем правильно понимал Bookmarkable как исключительное требование обновляемости. Исходя из сказанного Павлом, я полагаю, что это возможность прицепиться к первичному ключу, однозначно идентифицирующего запись - то есть, одно из требований обновляемости набора данных.