Re: 80004005 Unspecified Error


"Dimitris Pantazopoulos" <DimitrisPantazopoulos@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote in message news:A556904C-ED16-4915-9BD3-D3B7A18A6960@xxxxxxxxxxxxxxxx
> It is very very true indeed.
>
> First, I did not expect MVPs to argue over cute variable names

You got the bonus plan, then. Thing you have to consider is, when you post
your petty complaints about our free advice like that, you cut our incentive
to spend further time on your issue, to the bone.

> * The error message usually is "unspecified error" (but not always).

If the error message is inconsistent, then it's likely you're either dealing
with multiple problems, or you have a resource leak/hardware
problem/corrupted o/s.

> * The error has nothing to do either with db authentication or badly
> written
> code (mispelled connection strings etc).

a.) It often happens that questionable coding practices get broken by o/s
patches and updates. In today's climate of opportunistic vandalism and with
critical short-falls on ethics becomming distressingly common, virtually
every update that comes down the pike restricts access and hardens security.
Code will get broken by updates just a sure as script kiddies and hackers
will violate vulnerable systems. You have no choice but to get real with
it.

b.) Just because your Jet database has none of Jet's [lame] security
applied, does not make you free from security concerns. Access is a COM+
server, it has associated launch and activation permissions. NTFS
permissions also apply. The first connection to a Jet db causes the
creation of an .LDB file in the same dir as the .MDB, maybe this page is
accessed via multiple different security contexts, maybe it works when an
admin logs in -- the possibilities are almost endless. You need to take a
more wholistic view of the entire scenario.

> * Prior to some windows and/or mdac update, OUR code worked just fine. Now
> it just produces this error.

Wah! [See item a. above.]

> * It so happens that the same asp code may work today but not tomorrow or
> the day after!!!

In that case, forgive me for being so flip, but it sucks to be you, don't
it? [See item b.) above.] There is clearly something going on that's
deeper than you're looking. While it's working try dumping all of the
connection object's dynamic [and static] properties, then do the same while
it's failing, maybe you'll notice something significant.

Have you tried enumerating the connection.errors collection? VBS typically
only dumps the first error, though there may be more.

> Third, I've tried the TEMP/TMP solution also suggested by QUE in this
> thread. It worked just fine (I had to restart my win2000 server) TILL I
> restarted the IIS. Then the problem appeared again!

Again, sounds like a deeper permissions issue -- not a Jet permissions
issue, but Jet is far from the last line of defense.

> * My configuration is: IIS 5 on Windows 2000. My database is Access 2000.
> * Exactly the same asp code runs perfectly locally on my XP machine (with
> IIS 5 again).

XP ships with IIS 5.1; 2K server ships with IIS 5.0. They are very similar,
but most definitely not the same. Also, of course your code runs perfectly,
all objects on the same box, logged in as an admin, with all kinds of cached
credentials... All that means is it *might* run without problems on any
given server. It does NOT mean that your code is flawless, nor does it mean
it is coded to function well in a server environment.

> Last but NOT LEAST, obviously Microsoft does not really know how this
> problem occured nor how to solve it. None of the msdn articles really
> presents a final and deterministic solution.

No kidding! "Unspecified" errors are catch-alls for problems they don't
expect to impact the main stream of users, and therefore decline to invest
in what it would take to render a meaningful error in all cases.

> My opinion is, it must be side-effect of some windows update.

If your opinion was highly valuable in this instance, you wouldn't be asking
for help on the usenet, would you?

> There is really nothing we can do to solve this problem once and for all,
> right ?

About all the scenarios that can cause an unspecified error to occur? Nope,
there's no solution. About the problem, or cocktail of problems you have on
tap, hard to say -- but the more combative and closed-minded you are, the
less likely it is your issue will be resolved here.


Sorry if my "tough love" approach has offended you... but if you want
further consideration, I'd suggest you get over it. :-)


-Mark



> dp
>
>
> "Bob Barrows [MVP]" wrote:
>
>> que wrote:
>> > I feel like I am in good company this week.
>> > I was moving an application from one server to another when it broke.
>> > Exactly same error message: Microsoft JET Database Engine error
>> > '80004005'
>> > Unspecified error
>> > from the database connection line
>> >
>> > It had to be either a permissions problem or a driver issue since it
>> > was
>> > fine on the old server.
>> > I double checked the permissions between servers - ok
>> > I tried using a different connection string hoping it was the driver:
>> > Conn.open "Driver={Microsoft Access Driver (*.mdb)};DBQ=" & dbpath
>> > Got a different error: "[Microsoft][ODBC Microsoft Access
>> > Driver]General
>> > error Unable to open
>> > registry key 'Temporary (volatile) Jet DSN for process"
>> >
>> > Found this website:
>> > http://www.attention-to-details.com/newslog/38n-temporary-volatile-jet-dsn-for-process.asp
>> >
>> > The solution was the user who has modify rights on the .mdb must also
>> > have
>> > modify right to the system TEMP directory
>> > Tried it - fixed
>> > Switched back to original connection string - fixed
>> >
>>
>> That's not true if you use the OLE DB provider for Jet, instead of the
>> ODBC
>> driver.
>>
>> --
>> Microsoft MVP - ASP/ASP.NET
>> Please reply to the newsgroup. This email account is my spam trap so I
>> don't check it very often. If you must reply off-line, then remove the
>> "NO SPAM"
>>
>>
>>


.