Using the errors() collection?

[jsteph]

I'm having a catch-22 sort of issue with the errors() collection. While debugging I just try ?errors(0), and that act alone generates an error(0)="Item not found in this collection", even though there may have been nothing before.
So now in testing, every time there is code with a For Each in the errors collection, there is now an entry in the 0 ordinal = "Item not found...", so further testing is difficult.

I know I could check the .count, but if I'm just doing a quick debug test, I sometimes forget.

So how does one clear the errors(0) collection? There doesn't seem to be a .Clear method.
Thanks,
--Jim

 

[Remou]

Does Err.Clear not work?

 

[jsteph]

No, the errors collection remains intact after that.
--Jim

 

[JoeAtWork]

For clarification, are you talking about the Errors collection in an ADO Connection object?

    Dim cn As ADODB.Connection
    
    cn.Errors.Clear

 

[jsteph]

No, I use no qualifier, just Errors(), but it's part of the dbengine object. I use it when I need more detail on ODBC errors, ie, when the err.description is, for example "ODBC Call failed", that would be errors(1), and errors(0) might be something like "Cannot insert duplicate key...".

It has only .Count and .Refresh as propery and method, and the .Refresh does not clear it.
--Jim

 

[webturner]

The Resume statement should clear it, i.e. Resume Next,

However it sounds like you need to change your debugging practices to look at count first, or perhaps just looking at err.description instead?

 

[Remou]

It seems you cannot clear the error collection:
[tt]As each such error occurs, an Error object is placed in the Errors collection of the DBEngine object. A single event can therefore result in several Error objects appearing in the Errors collection.

When a subsequent DAO operation generates an error, the Errors collection is cleared, and one or more new Error objects are placed in the Errors collection.[/tt]

This may be worth noting:
[tt]Note that the last Error object in the Errors collection should always refer to the same error as the Err object. That is, the value of Err.Number should be equivalent to Errors.Count – 1. If these two values aren't equivalent, information in the Errors collection may be outdated. Use the Refresh method to ensure that the Errors collection includes the most recent error information.[/tt]

 

[jsteph]

Remou,
Thanks for that info, it's what I was afraid of. Not a big deal in the big picture though. However

Note that the last Error object in the Errors collection should always refer to the same error as the Err object.

This is true at the high level, ie, the err.Description might say "ODBC Call Failed", and errors(count-1) should and does say the same thing, but it's errors(count-2) that has the more telling description.

webturner,

However it sounds like you need to change your debugging practices to look at count first, or perhaps just looking at err.description instead?

True, as I'd said in the o.p. I know I could check the .count, but if I'm just doing a quick debug test, I sometimes forget. And the reason I don't do err.description is I need to get down to the errors(0) error to get the 'real' error.

The main difference here is that (for example) if you do in code:
msgbox err.description
msgbox err.description
...you get two blank msgs.
However if you do:
msgbox errors(0)
msgbox errors(0)
...the first one is blank, and the second one is "Item not found in this collection"--the error generated by trying to display the nonexistent error in the first box. The key being that attempting to display a non existent err.description does not generate an error, where attempting errors(0) does.
--Jim



--Jim