Access ASP SQL Server VBA NET - Форумы по проектированию

LEADERSOFT.ru Разработка на заказ программ и сайтов

Форумы по информационным технологиям

Начало

Forums

Регистрация | Вход

Форумы

Поиск

Список форумов

Программирование

Microsoft Access. Файлы mdb и accdb

Тема: Отловить ...

RE: Отловить ошибку ADO на форме в Access project

15.06.2007 21:04:49

All

4316 сообщения

RE: Отловить ошибку ADO на форме в Access project

1. В VBA есть функция err, а для ADODB.connection есть массив ошибок Errors (см. пример 3 файла la_ado.mdb).
2. Вообще надо запомнить, что срабатывание событий формы по времени будет намного позже, чем заполнение объектов ошибок.
3. В данном случае поставьте точку прерывания на объект(ы) ошибок: Break When Value Is True.
4. Программа остановится, когда будет ошибка. Далее, просматривая в дебагере ошибку и стек, можно тайти причину и место ее возникновения.

P.S. Общий раздел по формам
Автор: Admin от 0:00:00 Источник ...

15.06.2007 21:04:49

Павел3

7 сообщения

RE: Отловить ошибку ADO на форме в Access project

1. Ты предлагаешь использовать таймер?
2. см.1.
3. прерывание ставится в коде, а это код системы.
4. см. 3.

Дело в том, что программа просто не генерирует ошибок, которые можно и нужно перехватить!
Место вохзникновения - SQL Server, а не мой код.
Access глотает и не показывает эти ошибки.
Я же достаточно четко объяснил ситуацию, чтобы говорить мне совсем о другом.

Один из возможных путей отслеживания ошибок в рекордсете:
Public WithEvents MyRs as Recordset
Set MyRs = Me.Recordset
У рекордсета есть разные события - см.доку.

Вопрос 2: как на форме отследить изменение ссылки на рекордсет, т.е. изменение свойства формы Recordset/RecordsetClone, конечно только в случае неявного изменения самим Access'ом?

P.S. Общий раздел по формам
Автор: Павел от 11.12.2003 14:02:01 Источник ...

15.06.2007 21:04:49

ТимурРахимов

16 сообщения

RE: Отловить ошибку ADO на форме в Access project

Не вполне уверен, что это та самая проблема, с которой я некогда столкнулся, но, может быть, это хоть натолкнёт на мысль.

Дело в том, что мне стоило немалых трудов наладить более-менее приемлемую передачу ошибок, возникающих при выполнении хранимых процедур на сервере (и триггеров), в приложение Access (.ADP).

Этому препятствуют, например, отладочные операторы SELECT и PRINT в SQL-коде. Ниже привожу свои записки по этому поводу без пояснений (фрагмент 1).

Ещё одно соображение. Я обнаружил, что в форме Access сообщение об ошибке на сервере (например, в случае constraint violations), если я пытаюсь сохранить запись из программы (к примеру, при нажатии пользователем кнопки "Сохранить") не показывается! Обошёл я это следующим образом: программно посылаю в форму "нажатие" клавиш Shift+Enter, чтобы пользователь хоть увидел, "что не так" с данными (это сообщение об ошибке может посылать и триггер). Привожу ниже код с "сырым" комментарием из моего приложения, который иллюстрирует это (фрагмент 2).

=== Фрагмент 1 ======
/* Безобразная концепция ошибок MS SQL Server:

Соглашение по терминологии:

wrapper - процедура уровня 0, процедура, вызываемая непосредственно из wrapper'а - уровень 1, вызванные ею процедуры - уровня 2 и так далее.

1. Некоторые ошибки (например, 2714) вызывают немедленное прерывание процедур по всей структуре вложенности вплоть до самой внешней
(то есть прерывается текущий batch), при этом (слава богу, а то перехватить это событие нельзя!) неявно выполняется ROLLBACK TRAN
Программист, понятное дело, обработкой таких ошибок заниматься не должен (и не может!)

2.Некоторые ошибки (например, 208) вызывают НЕМЕДЛЕННОЕ прекращение только текущей процедуры, и передаёт управление охватывающей.
Сразу после этого можно (и нужно!) проверить @@error, чтобы в случае <>0 "вручную" вызвать ROLLBACK TRAN. Если бы ROLLBACK выполнялся
при этом автоматически, или (что ещё лучше) выполнение процедуры не прерывалось (чтоб я сам в той же процедуре после "подозрительной"
команды смог проверить @@error, чтобы откатить транзакцию), жить было бы намного легче! А то приходится делать wrapper для каждой
процедуры (увы, лучше способа пока не нашел), чтобы хоть в охватывающей процедуре вызвать ROLLBACK TRAN. Если этого не сделать, то
последствия будут ужасны: хотя сообщение об ошибке будет выдано пользователю, транзакция так и не будет свернута, и все блокировки
так и будут висеть, пока пользователь не освободит приложение и тем самым не закроет connection.

Увы, ошибка такого типа не доходит до обработчиков в клиентском приложении, использующем ADO (Access2000, например).
При этом VBA.Err.Number=0, conn.Errors(0).NativeError=44 (совершенно неинформативная ошибка). Остается только
проверять возвращаемый статус процедуры (который самому надо назначать при выходе из wrapper'а после вызова ROLLBACK TRAN.

3.Некоторые ошибки (например 2627) не прерывают выполнения процедуры, что даёт возможность программисту проверить @@error и
поступить так, как ему нужно. В этом случае ошибка "всплывает" до клиентского приложения, однакое есть другая проблема: команда IF @@ERROR<>0
СБРАСЫВАЕТ переменную @@ERROR к нулю, поэтому проверить статус ошибки во wrapper'е можно только по статусу возврата вложенной
(основной) процедуры, который в ней нужно назначить по результатам проверки @@error.

4.Ошибки, вызываемые программистом raiserror(), когда с точки зрения системы никакой ошибки нет (когда значение аргумента
процедуры с точки зрения логики программы неверно - отрицательный возраст человека,например), выполнение процедуры не прерывают. Их
обработка производится так же, как и в случае 3. И в этом случае @@error во wrapper'е проверять бесполезно (остается только статус возврата),
хотя состояние ошибки сохраняется для клиентского приложения. Внимание!!! Ошибка "доезжает" до приложения только в том случае, когда
перед ней не выводилось НИКАКОЙ отладочной информации (любые select'ы, возвращающие записи и операторы print). После отладки удалите
все такие строчки, чтобы информация (raiserror - самые информативные события!!) попадала в клиентское приложение.

Концепция обработки этой дурацкой системы
На самом верхнем уровне - стандартный wrapper, который ничего не делает кроме обработки ошибок.
Все ошибки для обработки передаются "наверх" (wrapper пришлось добавить, чтобы было кому "наверху" обработать ошибку типа 2 на первом уровне.

Если процедуре на n-ом уровне вложенности встретилась ошибка типа 1, то управление сразу же передается клиентскому приложению, и оно может проверить состояние ошибки в объекте Error. Обработчики ошибок на этом и всех вышележащих уровнях, включая wrapper, управление так и не получат.

Если текущей процедуре встретилась ошибка типа 2, то управление сразу же передается на вышележащий уровень (n-1) (если это был верхний уровень - то во wrapper). Процедура вышележащего уровня проверяет @@error, и если <>0, то назначает свой статус возврата=-1, и тут же передает управление "наверх" (wrapper передает управление клиентскому приложению). Вышележащая процедура (кроме wrapper'а), проверив сразу после возвращения статус возврата и обнаружив, что он =-1, сразу же, ничего более не делая, назначает свой статус возврата таким же, и возвращает управление вызвавшей процедуре, и так далее, вплоть до wrapper'а, который откатывает транзакцию. Клиентское приложение всегда получает статус возврата -1, который сигнализирует об ошибке и (не всегда) состояние ошибки в объекте Error.

Если в текущей процедуре встретилась ошибка типа 3 или 4 (обработка их одинакова), то обработка происходит так, как это делает охватывающая процедура в случае типа 2, но прерывания процедуры не происходит, поэтому возникающая ошибка обнаруживается на этом же уровне. Аналогично типу 2, статус возврата =-1 передается наверх через все уровни вплоть до клиентского приложения.

*/

==== Фрагмент 2 ====
Function Сохранить() As Boolean

On Error Resume Next

Сохранить = True
If Me.Dirty = False Then Exit Function

'Делаем попытку сохранить запись, это нужно, чтобы увидеть сообщение
'о constraint violations (DoCmd.RunCommand acCmdSaveRecord в этом случае
'генерирует ошибку 2757 "There was a problem accessing a property or method of the OLE object."
'что совершенно неинформативно

'Кроме того, открытие формы в режиме acDialog приводит к тому, что ни
'SendKeys ("+{ENTER}"), True, ни DoCmd.RunCommand acCmdSaveRecord не работают
'(игнорируются), поэтому от режима диалога пришлось отказаться
'
Назв.SetFocus
SendKeys ("+{ENTER}"), True

' Проверяем свойство Dirty - другого способа (идиотизм!) узнать, как завершилось
' сохранение записи, нет! Даже если при этом выводились сообщения о constraint
' violations, все равно Err.number=0 и даже
' Application.CurrentProject.Connection.Errors.Count=0, какая бы ошибка не встретилась
' Так по-дурацки обрабатывается системой SendKeys ("+{ENTER}"), True

If Me.Dirty Then
' Call DisplayCustomMessage(0, 1003)
Сохранить = False
Exit Function
End If

End Function

P.S. Общий раздел по формам
Автор: Тимур Рахимов от 19.12.2003 0:40:45 Источник ...

Страница 2 из 2

Программирование

Microsoft Access. Файлы mdb и accdb

Тема: Отловить ...

Поиск

Список форумов

Начало | Forums