Again today, working in ASP backing onto Oracle I had another 80020009 error. As I previously stated, the error code was as follows:

1. error '80020009'
2. Exception occurred.
3. /somefile.asp, line <number>

This time I immediately went to solve the problem based on my previous solution. As it turned out, the date was incorrect. Once corrected however, the error did not go away. I preceded to set the date field back to NULL and then back to a valid date; which was being stored in dd/mm/yyyy format, still nothing.

At this point I started hunting down the possible cause. I couldn’t display the date in that field at all through ASP, yet the same field in different tuples were just fine. I could use an isNull() on the date and it reported that there was in fact ‘something’ in the field. If I tried a Len(), I would get an error. The sub-type of the field in the recordset reported by VarType() for all other tuples was in fact 7 (VBDate), however the one in error was a 9 (VBObject).

At this point I was wondering whether Oracle had some how managed to store a damaged date, so I wrote a small query using SQL to do a comparison on the field against SYSDATE:

1. SELECT completeddate,
2. CASE
3. WHEN (completeddate > SYSDATE) THEN
4. 'TRUE'
5. ELSE
6. 'FALSE'
7. END as FutureEvent
8. FROM tblevents
9. WHERE eventid = 49401;

As expected, Oracle returned the correct values in every case. Which left me with no place to really go forward from here. To put the web application back into a working state, I used the VarType of the field to test whether I should or shouldn’t attempt to display the value; dirty hack but a working solution for the moment.

This leads me to believe, that some how ASP/ADO/something is some how reporting/munging the value of that field for some reason. I still don’t quite know how or why; all I know at this point is that it is frustrating and consumed my time on something that should have otherwise worked perfectly.

I was given another strange error tonight and once again searched around for a quick solution but it didn’t present itself immediately. The error was given was:

1. Error Type: (0x80004005)
2. Unspecified error
3. /aspfile.asp, line <linenumber>

I’m finding it increasingly frustrating that the error codes that ASP presents are far to broad. You get given an error and it can relate to one of 100 different things. At which point, you need to whittle down that list till you finally find one that roughly matches your scenario. I realise that the language is old and it isn’t as much of a problem these days, however if they know it errored and they can categorise the error into the 0x80004005 group, then they must of known exactly what the problem was. At which point, why not provide your developers a specific and useful error message; it would sure save them a lot of time.

Continuing on, in the end, the problem was caused by the name field I was updating, it was a reserved word. This brings me to my next point. You would think that when the person that created this Access database designd it (not me), that Access would have prompted him with a “This is a reserved word, you are not allowed to use it as either a table or field name”. Now, it might have presented him with it, clearly it wasn’t forceful enough as he named it with an invalid name regardless.

To give you an idea of what I was doing, here is a code snippet:

1. sSQL = "SELECT * FROM [Position/Title] WHERE lcase(position) = '" & LCase(Request.Form("position")) & "'"

In this case, not only was his table name wrong (who uses slashes in names, really!), but the field “position” was the reserved word. To save renaming the field, as I didn’t want to change the database, you can wrap the field names in square brackets [ ].

Thankfully Access provided a way around the problem, which was simple and convenient. Now if only the error reporting was concise.

Again today, I came across an error caused by an invalid date value. The error reported was:

1. error '80020009'
2. Exception occurred.
3. /somefile.asp, line <number>

Went and googled again, this time it appeared as though the error was commonly caused by over-stepping the bounds of the resultset. For instance, pulling back 10 records by trying to read the 11th which doesn’t exist. Well that wasn’t the case for mine (once again), it was an invalid date format.

All I was doing, was displaying the date value. I wasn’t using it to do any calculations in either ASP or through SQL, so even it if was invalid, you would assume it would just ‘display it’ and be done with it.

For whatever reason, just trying to display a date of format ‘0000-01-04’ caused it to fall over. The solution of course, just correct the date value. Once again, lack of client and server side checking of user input bites you in the arse.

While working on some ASP today, someone reported that a page used for editing contact details was generating the following error:

1. Microsoft Cursor Engine error '80040e21'
2. Multiple-step operation generated errors. Check each status value.

I googled it and found some possible causes how none of them seemed to match what I was looking for. When I checked PostgreSQL for that particular item, I found that there was a date field which had the value ‘0000-12-24’ in it. I would have thought that PostgreSQL would have errored when someone tried to insert that date, however it would appear it didn’t.

The solution was simple, change the year field back to what it should have been and it was all fine. Just goes to show that you should never trust what a user enters into the system; more checking is required even on a simple thing like a date.