Скопировано с сайта Новикова Сергея nsa.cat.ru. Автор статьи - Павел Жидков (Кузбас)

"Данные, добавленные в базу данных, не будут отображены в форме, так как они противоречат условиям на базовый источник записей"

Прислал Павел Жидков.
Окончательно обессилив в борьбе с ошибкой в проекте Access'a 2000 "Данные, добавленные в базу данных, не будут отображены в форме, так как они противоречат условиям на базовый источник записей" при вставке записи в таблицу с ключевым полем Identity и триггером On Insert, добавляющим записиии в другую таблицу с ключевым (или не ключевым) полем Identity я решил заглянуть в корень проблемы. Итак:
При работе с SQL сервером через ODBC такой проблемы не возникает, следовательно запускаем ODBC Trace и изучаем вызовы ODBC функций. И вот какая интересная штука - сразу после вставки записи, до COMMIT одна из функций запрашивает @@Identity. (Для тех кто не знает @@Identity это системная переменная (или функция(?)) которая содержит значение последнего поля Identity, сгенерированного при вставке записи). Снова начал эксперементировать с OLE DB Provider for MSSQL, и вскоре выяснил, что этот самый провайдер возвращает Access'у значение @@Identity после Commit, когда @@Identity в результате работы триггера уже приняло значение отличное от значения в поле.
Это со стороны Microsoft безусловно Глюк и баг !!! Но как-то нужно выкручиваться. И вот что мне пришло в голову: Если отказаться от Identity Вообще, то неизбежно возникнет проблема создания уникального значения для ключевого поля. В однопользовательской среде это, собственно, и не проблема -бери MAX от значений поля, наращивай на 1 и всавляй. Но вот в многопользовательской среде это, во первых, замедлит работу и вызовет нежелательную блокировку таблицы, а во вторых может привести к нарушению уникальности ключа из-за попытки одновременно вставить запись разными пользователями. Но есть замечательная штука - uniqueidentifier. Используя его в качестве ключевого поля проблему удалось решить). Но не всем и далеко не всегда удобно и необходимо использовать uniqueidentifier, к тому же сортировка по полю этого типа невозможна (хотя эти проблемы обойти легко). Напрашивался вывод: нужно заставить вернуть @@Identity нужное Access'y значение. Мне удалось найти только один способ (да простят меня знатоки T-SQL за глумление над полезными операторами !)

В начале триггера/процедуры
Declare @Idt As int, @SqlStr As Varchar(100)
Set @Idt = @@Identity
...

В конце триггера/процедуры
Set @SqlStr = 'Select Identity (Int, ' + Cast(@Idt As Varchar(10)) + ', 1) As id Into #Tmp'
Execute (@SqlStr)

С наилучшими пожеланиями
Павел Жидков
Программист вечно работающий не по специальности.

Извините, опечатался. Не nsa.cat.ru, а nsa.chat.ru