Form_Error Event - Error-Message from SQLServer

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

When I take the Form_Error Event in an Accessform to display errormessages, I
get only the error-no. 3146: "ODBC-Call ..." Is there a way to display
errormessages from SQLServer such as Trigger-Errors, Index-Errors, etc.. ?
(p.e. an stored procedure call functions with a passthourgh-Query very good,
I get errormessages from SQLServer)
 
Fabrice said:
When I take the Form_Error Event in an Accessform to display errormessages, I
get only the error-no. 3146: "ODBC-Call ..." Is there a way to display
errormessages from SQLServer such as Trigger-Errors, Index-Errors, etc.. ?
(p.e. an stored procedure call functions with a passthourgh-Query very good,
I get errormessages from SQLServer)
Click to expand...

Unfortunately there is no way in the form's Error event to trap the errors
returned by SQL Server. However, if you set the Response argument to
acDataErrDisplay then it will display whatever codswallop was returned by
SQL Server (which is, sadly, generally pretty user-unfriendly).
 
Brian said:
Unfortunately there is no way in the form's Error event to trap the
errors returned by SQL Server. However, if you set the Response
argument to acDataErrDisplay then it will display whatever codswallop
was returned by SQL Server (which is, sadly, generally pretty
user-unfriendly).
Click to expand...

What about the DBEngine.Errors collection? I think Fabrice should be
able to get some more detailed information about the error that occurred
from the contents of that collection.
 
Dirk Goldgar said:
What about the DBEngine.Errors collection? I think Fabrice should be
able to get some more detailed information about the error that occurred
from the contents of that collection.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)
Click to expand...

No, Dirk, the DBEngine.Errors collection is not populated in the Form_Error
event. Sad but true. I bear the scars.
 
First thanks for the help. I see, I must give a litle bit background:

So far, I use an Errorhandling, that writes the Error-Description into an
own table on the SQLServer. Now, when I use "acDataErrDisplay", the
Error-Description displays on the Screen, but I cannot receive the
Description p.e. to an variable to save the message into my own table.
The collection "DBEngine.Errors" unfortunately does not return the error to
me, all the same whether before or after setting "Response"

Did you have any ideas ?
 
Fabrice said:
First thanks for the help. I see, I must give a litle bit background:

So far, I use an Errorhandling, that writes the Error-Description into an
own table on the SQLServer. Now, when I use "acDataErrDisplay", the
Error-Description displays on the Screen, but I cannot receive the
Description p.e. to an variable to save the message into my own table.
The collection "DBEngine.Errors" unfortunately does not return the error to
me, all the same whether before or after setting "Response"

Did you have any ideas ?
Click to expand...


No. As I said before, it can't be done: in the Form_Error event, you simply
cannot access the SQL Server error details.
 
Brian said:
No, Dirk, the DBEngine.Errors collection is not populated in the
Form_Error event. Sad but true. I bear the scars.
Click to expand...

I'll take your word for it, having enough scars of my own. Then unless
Fabrice can trap the error nearer to the source, I don't see a way.
 
Brian said:
http://support.microsoft.com/default.aspx?scid=kb;en-us;124395

Still doesn't work in A2002. No reason to suppose it's any different
in 2003.
Click to expand...

Assuming the Form_Error event is raised due to an attempt to update, and
that's what Fabrice would like to trap, I was thinking that maybe there
would be some way to force the update in in code, earlier, allowing
normal error-handling to trap the error and examine the DBEngine.Errors
collection. Failing that, one might have to resort to unbound forms
with updates performed in code, which makes for a much more complicated
programming structure.
 
Dirk Goldgar said:
Assuming the Form_Error event is raised due to an attempt to update, and
that's what Fabrice would like to trap, I was thinking that maybe there
would be some way to force the update in in code, earlier, allowing
normal error-handling to trap the error and examine the DBEngine.Errors
collection. Failing that, one might have to resort to unbound forms
with updates performed in code, which makes for a much more complicated
programming structure.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)
Click to expand...

Yes, I daresay such an approach could be worked out. Fabrice would need to
be a pretty confident programmer! In my experience, trying to divert a
bound form from the way that God and Microsoft intended it to work always
throws up unforseen problems that need to be worked around.

I've always believed that, as soon as one starts using unbound forms as a
matter of course, then Access is the wrong tool and it's a job for Visual
Basic (although that opinion doesn't apply to the mess that is VB.Net: I'd
far rather use unbound forms in Access! Or VB6. Or Delphi. Or anything
else, really!)
 
Thanks beautifully for the nice words. Unfortunately our system is so complex
that a conversion is nearly impossible e.g. on VB. But we aim at a conversion
to ADO. I have unfortunately still no experience with ADP projects. Is there
a better solution by Microsoft reffering the Form_Error event ?
 
Back
Top