Насколько я понял проблему автора вопроса, тут дело в коде самого Access 2000, и обновление MDAC тут не поможет. Это документировано в MSDN. Я впервые столкнулся с этим в 2000-м году, тогда же методом "научного тыка" нашёл удовлетворительное решение, и лишь совсем недавно ясно понял природу проблемы и как её решить практически полностью (на Access 2000, конечно - справедливо было указано, что на Access 2002 вопрос неактуален).

Проблема в том, что "родные" сообщения об ошибках MS SQL Server выводятся только тогда, когда действие инициируется кодом самого Access (в ответ на интерактивные действия пользователя). Если же мы попытаемся, к примеру, сохранить запись, например, так -
, то при невозможности сохранения записи сервером (constraint violation или ещё что) ВСЕГДА будет генерироваться одна и та же ошибка номер 2757 - "There was a problem accessing property or method of OLE object". Это лишает возможности информировать пользователя о причине ошибке и хоть как-то осмысленно отреагировать на произошедшее.

Два решения:

1) Довольно быстро я догадался, как снять остроту проблемы (простым перебором всех возможных вариантов). Как уже сказано, если запись сохраняется командой из меню, а не пользовательским кодом, то текст сообщения об ошибке, пришедшей с сервера, показывается правильный. Решение очевидно - всякий раз, когда кодом нам нужно сохранить запись, используем имитацию нажатий клавиш, приводящих к сохранению записи самим Access'ом (аргумент True важен, поскольку в большинстве случаев нужна синхронная обработка команды):

2) Хотя приведённое выше решение оказалось на практике вполне приемлемым, я долгое время искал способ преодолеть его очевидные ограничения - хотелось бы заменять малопонятные для обычного пользователя сообщения об ошибках сервера на английском языке на свои. Проблема тут в том, что никаким способом (включая перехват события Error формы и исследование свойств коллекции Errors ADO) невозможно получить ни код ошибки сервера, ни её текст - везде всё те же 2757 "There was a problem accessing property or method of OLE object".
И лишь совсем недавно, читая статью в MS KB (написанную совершенно по другому поводу), я понял, что надо сделать: отлавливать события объекта Recordset формы. В тот же вечер я это всё с успехом реализовал, так что задача была почти решена. "Почти" - это, во-первых, потому, что код ошибки MS SQL Server получить, видимо, в Access 2000 принципиально невозможно (так что придётся устраивать разбор строки ошибки), а во-вторых, потому, что не всегда при нарушениях целостности данных ошибка генерируется сервером: в некоторых случаях "умный" Access отображает ошибку, даже не посылая данные на сервер. В последнем случае описанный метод не работает и перехватить такое событие своим кодом, похоже, никак нельзя.

Только после того, как я всё это реализовал самостоятельно, я натолкнулся на статью Сергея Вакшуля, который прошёл тем же путём, что и я, ещё в 2002 году:
http://www.hiprog.com/access/article.asp?id=365

yuniki:
В моём случае так не работало - коллекция Errors объекта CurrentProject.Connection была во всех случаях пуста (Access SP3,MS SQL 2000 SP3). Возможно, это поправлено, начиная с MDAC 2.8 (я не проверял - мне пришлось добиваться работоспособности кода на предыдущих версиях). Однако проблему скрытия Access'ом сообщения сервера об ошибке в случае программного сохранения записи (замены его на "There was...") MDAC 2.8, похоже, всё таки не решает.

Но, судя по строкам

ваш код написан для MDB? В таком случае это вряд ли может служить аргументом, ведь мы обсуждаем, если не ошибаюсь, ADP?

Dmitry Biryukov:
Если описанное вами поведение происходит не в результате действия вашего кода, а в ответ на выбор команды из встроенного меню, то это глюк. В этом случае, возможно, переустановка компонентов или всей программы в целом должна помочь.

Ещё раз: на вашей конфигурации (Access 2000 SR1, MS SQL 2000 SP3) у меня сообщение об ошибке, пришедшее с сервера, надёжно отображается в виде системного message box'а с единственной кнопкой ОК (но только в случае, если попытка сохранения записи инициировалась самим Access'ом, а не моим кодом).

yunikiМне просто интересно, у меня-то Access2000 и даже, если форма без кода - все-равно о нарушениях целостности выходят адекватые американские сообщения, проблема только в том, чтоб их MsSQL посылал по русски.
У меня в точности то же самое, и здесь нет никакой проблемы (к сожалению, как я понял, у автора вопроса уже на этом этапе затруднения). Проблемы начинаются, когда сохранение записи инициируется нашим кодом, а не Access'ом, и продолжаются, когда мы хотим заменить системные сообщения, пришедшие с сервера, на свои.

yunikiМне тут (вернее на MsSQL говорили, что можно это сделать за счет спец. свойств полей в таблицах).
Ссылочку не дадите? Что-то мне кажется, что речь тут идёт о sp_addextendedproperty , но это решение, как я думаю, для другой задачи.

Dmitry Biryukovнадо для логина установить default language = russian
Да, при условии, что таблица sysmessages в master содержит варианты сообщений на русском языке (не у всех это так), это несколько облегчит ситуацию. Но, к сожалению, не решит проблему: в большинстве случаев системные сообщения, даже будучи переведёнными на русский язык, останутся пользователю непонятными. Чтобы сообщение было им понятно, оно должно быть сформулировано в понятиях предметной области, для которой написана ваша программа, так что всё равно есть потребность в замене системных сообщений на свои (уникальные для этой конкретной программы).

Что касается вот этого:
Тимур РахимовНо, судя по строкам
yuniki
ваш код написан для MDB? В таком случае это вряд ли может служить аргументом, ведь мы обсуждаем, если не ошибаюсь, ADP?
Я проверил, это действительно для ADP. Извиняюсь.

Если бы у меня так работало, не пришлось бы городить такой огород.

yuniki:

Что касается такого способа подмены системных серверных сообщений о нарушениях целостности -

Я проверил, всё прекрасно работает. Но... в Access 2002! И выше (наверное).

Спасибо за подсказку - я не знал, что кроме MS_Description , Access может использовать ещё-какие-то свойства серверных объектов.

А в Access 2000 по прежнему приходится рассчитывать только на свои силы.