By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,851 Members | 983 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,851 IT Pros & Developers. It's quick & easy.

Error trapping in Access 2003

P: n/a
I'm still using Office 2000 myself, but some of my clients have Office 2003.
I've recently added a piece of code to create an instance of Word, open a
document, fill in the blanks and become visible so the document can be
printed and/or modified.

This all takes place within one form, in which the Word.Application and
Word.Document objects are both private form-level variables. Just to be on
the safe side I included this piece of code in the Form_Close() event
procedure:

On Error Resume Next
doc.Close wdDoNotSaveChanges
app.Quit
Set doc = Nothing
Set app = Nothing

This all works fine in Access 2000 - if the objects are no longer set the
error trapping deals with it silently.

However, in Access 2003 it behaves exactly as if the 'On Error Resume Next'
were not there. In fact it seems to be the beyond reach of any kind of
error trapping code whatsoever!

Can anyone tell me whether this is a bug or a feature - and whichever it is,
how do I deal with it?

Thanks.
May 15 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Captain Nemo wrote in message
<F3******************@text.news.blueyonder.co.uk > :
I'm still using Office 2000 myself, but some of my clients have
Office 2003. I've recently added a piece of code to create an
instance of Word, open a document, fill in the blanks and become
visible so the document can be printed and/or modified.

This all takes place within one form, in which the Word.Application
and Word.Document objects are both private form-level variables.
Just to be on the safe side I included this piece of code in the
Form_Close() event procedure:

On Error Resume Next
doc.Close wdDoNotSaveChanges
app.Quit
Set doc = Nothing
Set app = Nothing

This all works fine in Access 2000 - if the objects are no longer set
the error trapping deals with it silently.

However, in Access 2003 it behaves exactly as if the 'On Error Resume
Next' were not there. In fact it seems to be the beyond reach of any
kind of error trapping code whatsoever!

Can anyone tell me whether this is a bug or a feature - and whichever
it is, how do I deal with it?

Thanks.


My first guess, would be the setting for error trapping. In VBE - Tools
| Options - General Tab - make sure it's set to Break on Unhandled
Errors.

--
Roy-Vidar
May 15 '06 #2

P: n/a
"RoyVidar" <ro*************@yahoo.no> wrote in message
news:mn***********************@yahoo.no...
My first guess, would be the setting for error trapping. In VBE - Tools
| Options - General Tab - make sure it's set to Break on Unhandled
Errors.


Interesting point. Given that the Tools -> Options submenu is
"grayed out" until you load a database, I had assumed that this
meant that all options were saved with the .mdb file. That and
the fact that at least one option (Compact On Close) most
definitely IS saved with the database.

However, I was wrong about this. In fact, this is one of the
murkiest and worst-documented features of Access. For instance,
in the online help page "Set Options from Visual Basic" there is
a note at the bottom of the page advising the developer to set
Error Trapping to 2, when a project is completed. However, the
fact that "Error Trapping" does NOT appear in the list of Options
that may be set from VBA code further reinforces the myth that
such settings are saved with the .mdb file. The inference is that
as long as you manually set the Error Trapping to "Break on
Unhandled Errors" before you send the file off to the customer,
all will be well...

However, the good news is that this is nothing to do with Access
2003 (there are some peculiar bugs in that edition but this is not
one of them).

And the moral of this story is: ALWAYS make sure that the
Form_Open() event procedure of your startup form contains this line:

Application.SetOption "Error Trapping", 2

May 17 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.