Err.Clear vs On Error GoTo 0 2

I don't think you need either extra bits at the end of a module. Each module will restart the error bit on its own, best I recall. So if you're really needing/wanting to use On Error Resume Next (generally frowned upon as bad programming), then just use it, and don't worry about any error clean-up.

I suppose you're thinking of it as a typical object you instantiate and create, and then clean-up in the end. Although those objects do supposedly get cleaned up, it is best practice to manually delete/erase/close any objects you manually create/reference.

The error piece is different than manually instantiating them. The system takes care of that on its own, pretty much. You can grab the errors, and you can throw errors on purpose, but the main application will control pretty much everything else. Of course, if you want a log of the errors, you'd have to build that yourself, and have any errors logged to a table.

"But thanks be to God, which giveth us the victory through our Lord Jesus Christ." 1 Corinthians 15:57

I'm deleting data from Access tables, but if there's no data there I'd prefer to keep the code moving rather than dealing with the error. So I put an On Error Resume Next in front of the SQL. Right now I'm doing an Err.Clear after the SQL to clear any error raised, then an On Error GoTo 0 to clear the error trap. What I'm wondering is if the On Error GoTo 0 will clear any errors raised when it clears the error trap, making the Err. Clear redundant. I think it would, but am just looking for confirmation.

If the square peg won't fit in the round hole, sand off the corners.

Any On Error ... instruction clears the Err object.

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886

>Any On Error ... instruction clears the Err object

Er, wouldn't that make error handling a bit problematical?

strongm, the Err.Clear method is executed at the same time of the On Error instruction, so I don't understand your remark.

I was misunderstanding the context, and thinking about the point at which the error handler was invoked rather than the point at which it was coded

Thanks for your quick short answer, PHV. One of these days, when I grow up, maybe I can answer as clearly and concisely.

"But thanks be to God, which giveth us the victory through our Lord Jesus Christ." 1 Corinthians 15:57

how about

DoCmd.Warnings False

run query

DoCmd.Warnings True

HTH << MaZeWorX >> "I have not failed I have only found ten thousand ways that don't work" <<Edison>>

If you're referring to:
Then that doesn't do the same. Warnings and Errors are totally separate. A warning is something like, "Hey, you're about to create a new table, are you sure?" An error is more like: "Hey, goofball, you forgot to create your variable before using it."


"But thanks be to God, which giveth us the victory through our Lord Jesus Christ." 1 Corinthians 15:57

yah ... but they are doing a simple delete with SQL

I'm deleting data from Access tables ........Right now I'm doing an Err.Clear after the SQL

Click to expand...

HTH << MaZeWorX >> "I have not failed I have only found ten thousand ways that don't work" <<Edison>>

merlynsdad said:

I'm deleting data from Access tables, but if there's no data there I'd prefer to keep the code moving rather than dealing with the error.

Click to expand...

If I run an SQL statement such as:

DELETE * FROM MyTable

it does not cause an error if the table has no records, so why would you need to turn off error handling for this? Even if it did, this is really a bad decision. You are assuming the only possible error that can occur is that there are no records. Let's say your error is really that you have bad syntax, e.g.

DELET * FROM MyTable

Now "MyTable" will not get cleared even if it does have records, but you won't even know it because you told it to ignore all errors.

I would suggest something like this as an error handler, which will allow your code to proceed if you encounter the error you are expecting, but will do proper error handling if it's something you never anticipated:

Set Warnings True/False is an accepted way to turn off the ms nag messages regarding queries. Besides who assumes their queries are correct without testing?

HTH << MaZeWorX >> "I have not failed I have only found ten thousand ways that don't work" <<Edison>>

merlynsdad,

In case you haven't noticed it by now, you're asking about 2 different things. According to the context of your question, you're asking about the warning messages, not error messages. However, you say "..errors.."..

So...

First, you do want to make sure your query is working correctly..
Then, once you KNOW it works correctly, you can use it like this:


"But thanks be to God, which giveth us the victory through our Lord Jesus Christ." 1 Corinthians 15:57