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.