80004005 Error . . .

[Walter Rands-Trevor]

Hello,

I am getting the infamous 80004005 (like just about everyone else on the net
it seems). Using NT4/IIS4, Access 97 DB, it is a low volume (20 hits a day)
site that worked perfectly for over a year. Then suddenly, without me
changing any code on the site, it decided to start giving 80004005 errors.
Basically, in trying to fix this, I have tried several different connections
to the db,

objConn.ConnectionString = "DSN=Ops"
objConn.Open

or
objConn.Open "PROVIDER=MICROSOFT.JET.OLEDB.4.0;DATA SOURCE=c:\database.mdb"

or (had this suggested to me today but it also doesnt work for very long)
objConn.Open "Provider=MSDASQL.1;Extended
Properties=""DSN=Ops;FIL=MSAccess;UID="";"";"

Whichever connection I use, it will work fine for a short period of time,
and then stop working again. If I edit the code, and change the connection
to one of the other strings, it will work for a short while, and then stop
again. Once one page fails, all pages for all users fail. I have tried
different login names specified in the DSN properties, and in my ASP
connections. All permissions for the IUSR account have been checked and
double checked, I have updated MDAC several times (now up to 2.8), all the
patches and updates I can find are loaded onto the server, and virus scans
come up clean. I am closing and destroying the connections and recordsets,
and diming the variables. I have run compact and repair on the database,
but nothing I do fixes the error for more than half a day. Can anyone
suggest anything?

Thanks in advance,

Regards,
Walter Rands-Trevor

[Aaron Bertrand [MVP]]

There are about 50 80004005 errors. Could you be more specific? Or, see
the following:

[url]http://www.aspfaq.com/2009[/url]
[url]http://www.aspfaq.com/80004005[/url]

--
Aaron Bertrand
SQL Server MVP
[url]http://www.aspfaq.com/[/url]




"Walter Rands-Trevor" <walter@arknet.co.nz> wrote in message
news:uhh#vZy$DHA.2348@TK2MSFTNGP09.phx.gbl...

> Hello,
>
> I am getting the infamous 80004005 (like just about everyone else on the

net

> it seems). Using NT4/IIS4, Access 97 DB, it is a low volume (20 hits a

day)

> site that worked perfectly for over a year. Then suddenly, without me
> changing any code on the site, it decided to start giving 80004005 errors.
> Basically, in trying to fix this, I have tried several different

connections

> to the db,
>
> objConn.ConnectionString = "DSN=Ops"
> objConn.Open
>
> or
> objConn.Open "PROVIDER=MICROSOFT.JET.OLEDB.4.0;DATA

SOURCE=c:\database.mdb"

>
> or (had this suggested to me today but it also doesnt work for very long)
> objConn.Open "Provider=MSDASQL.1;Extended
> Properties=""DSN=Ops;FIL=MSAccess;UID="";"";"
>
> Whichever connection I use, it will work fine for a short period of time,
> and then stop working again. If I edit the code, and change the

connection

> to one of the other strings, it will work for a short while, and then stop
> again. Once one page fails, all pages for all users fail. I have tried
> different login names specified in the DSN properties, and in my ASP
> connections. All permissions for the IUSR account have been checked and
> double checked, I have updated MDAC several times (now up to 2.8), all the
> patches and updates I can find are loaded onto the server, and virus scans
> come up clean. I am closing and destroying the connections and

recordsets,

> and diming the variables. I have run compact and repair on the database,
> but nothing I do fixes the error for more than half a day. Can anyone
> suggest anything?
>
> Thanks in advance,
>
> Regards,
> Walter Rands-Trevor
>
>

[Walter Rands-Trevor]

The error is stubbornly refusing to show up just at this point in time, but
from memory I just get a page stating "Provider error '80004005' Uspecified
Error" followed by the page and line number.

It always relates to the line in the code that opens the connection to the
database. I can fix the problem (temporarily) by changing the code to use a
different type of connection, or if I wait a while (anywhere from 5 mins to
half an hour) the problem fixes itself. Sooner or later tho, it always
comes back . . .

Any thoughts?



"Aaron Bertrand [MVP]" <aaron@TRASHaspfaq.com> wrote in message
news:#Lm2Jnz$DHA.2336@TK2MSFTNGP11.phx.gbl...

> There are about 50 80004005 errors. Could you be more specific? Or, see
> the following:
>
> [url]http://www.aspfaq.com/2009[/url]
> [url]http://www.aspfaq.com/80004005[/url]
>
> --
> Aaron Bertrand
> SQL Server MVP
> [url]http://www.aspfaq.com/[/url]
>
>
>
>
> "Walter Rands-Trevor" <walter@arknet.co.nz> wrote in message
> news:uhh#vZy$DHA.2348@TK2MSFTNGP09.phx.gbl...

> > Hello,
> >
> > I am getting the infamous 80004005 (like just about everyone else on the

> net

> > it seems). Using NT4/IIS4, Access 97 DB, it is a low volume (20 hits a

> day)

> > site that worked perfectly for over a year. Then suddenly, without me
> > changing any code on the site, it decided to start giving 80004005

errors.

> > Basically, in trying to fix this, I have tried several different

> connections

> > to the db,
> >
> > objConn.ConnectionString = "DSN=Ops"
> > objConn.Open
> >
> > or
> > objConn.Open "PROVIDER=MICROSOFT.JET.OLEDB.4.0;DATA

> SOURCE=c:\database.mdb"

> >
> > or (had this suggested to me today but it also doesnt work for very

long)

> > objConn.Open "Provider=MSDASQL.1;Extended
> > Properties=""DSN=Ops;FIL=MSAccess;UID="";"";"
> >
> > Whichever connection I use, it will work fine for a short period of

time,

> > and then stop working again. If I edit the code, and change the

> connection

> > to one of the other strings, it will work for a short while, and then

stop

> > again. Once one page fails, all pages for all users fail. I have tried
> > different login names specified in the DSN properties, and in my ASP
> > connections. All permissions for the IUSR account have been checked and
> > double checked, I have updated MDAC several times (now up to 2.8), all

the

> > patches and updates I can find are loaded onto the server, and virus

scans

> > come up clean. I am closing and destroying the connections and

> recordsets,

> > and diming the variables. I have run compact and repair on the

database,

> > but nothing I do fixes the error for more than half a day. Can anyone
> > suggest anything?
> >
> > Thanks in advance,
> >
> > Regards,
> > Walter Rands-Trevor
> >
> >

>
>

[Aaron Bertrand [MVP]]

> Any thoughts?

Well, did you bother looking at the two links I posted?

--
Aaron Bertrand
SQL Server MVP
[url]http://www.aspfaq.com/[/url]

[Jeff Cochran]

On Mon, 1 Mar 2004 16:31:22 +1300, "Walter Rands-Trevor"
<walter@arknet.co.nz> wrote:

>The error is stubbornly refusing to show up just at this point in time, but
>from memory I just get a page stating "Provider error '80004005' Uspecified
>Error" followed by the page and line number.
>
>It always relates to the line in the code that opens the connection to the
>database. I can fix the problem (temporarily) by changing the code to use a
>different type of connection, or if I wait a while (anywhere from 5 mins to
>half an hour) the problem fixes itself. Sooner or later tho, it always
>comes back . . .
>
>Any thoughts?

Wait until it comes back. Then look at the two links posted by AAron
and do what they say.

Jeff

>"Aaron Bertrand [MVP]" <aaron@TRASHaspfaq.com> wrote in message
>news:#Lm2Jnz$DHA.2336@TK2MSFTNGP11.phx.gbl...

>> There are about 50 80004005 errors. Could you be more specific? Or, see
>> the following:
>>
>> [url]http://www.aspfaq.com/2009[/url]
>> [url]http://www.aspfaq.com/80004005[/url]
>>
>> --
>> Aaron Bertrand
>> SQL Server MVP
>> [url]http://www.aspfaq.com/[/url]
>>
>>
>>
>>
>> "Walter Rands-Trevor" <walter@arknet.co.nz> wrote in message
>> news:uhh#vZy$DHA.2348@TK2MSFTNGP09.phx.gbl...

>> > Hello,
>> >
>> > I am getting the infamous 80004005 (like just about everyone else on the

>> net

>> > it seems). Using NT4/IIS4, Access 97 DB, it is a low volume (20 hits a

>> day)

>> > site that worked perfectly for over a year. Then suddenly, without me
>> > changing any code on the site, it decided to start giving 80004005

>errors.

>> > Basically, in trying to fix this, I have tried several different

>> connections

>> > to the db,
>> >
>> > objConn.ConnectionString = "DSN=Ops"
>> > objConn.Open
>> >
>> > or
>> > objConn.Open "PROVIDER=MICROSOFT.JET.OLEDB.4.0;DATA

>> SOURCE=c:\database.mdb"

>> >
>> > or (had this suggested to me today but it also doesnt work for very

>long)

>> > objConn.Open "Provider=MSDASQL.1;Extended
>> > Properties=""DSN=Ops;FIL=MSAccess;UID="";"";"
>> >
>> > Whichever connection I use, it will work fine for a short period of

>time,

>> > and then stop working again. If I edit the code, and change the

>> connection

>> > to one of the other strings, it will work for a short while, and then

>stop

>> > again. Once one page fails, all pages for all users fail. I have tried
>> > different login names specified in the DSN properties, and in my ASP
>> > connections. All permissions for the IUSR account have been checked and
>> > double checked, I have updated MDAC several times (now up to 2.8), all

>the

>> > patches and updates I can find are loaded onto the server, and virus

>scans

>> > come up clean. I am closing and destroying the connections and

>> recordsets,

>> > and diming the variables. I have run compact and repair on the

>database,

>> > but nothing I do fixes the error for more than half a day. Can anyone
>> > suggest anything?
>> >
>> > Thanks in advance,
>> >
>> > Regards,
>> > Walter Rands-Trevor
>> >
>> >

>>
>>

>

[Bob Barrows]

Walter Rands-Trevor wrote:

> Hello,
>
> I am getting the infamous 80004005 (like just about everyone else on
> the net it seems). Using NT4/IIS4, Access 97 DB, it is a low volume
> (20 hits a day) site that worked perfectly for over a year. Then
> suddenly, without me changing any code on the site, it decided to
> start giving 80004005 errors. Basically, in trying to fix this, I
> have tried several different connections to the db,
>
> objConn.ConnectionString = "DSN=Ops"
> objConn.Open
>
> or
> objConn.Open "PROVIDER=MICROSOFT.JET.OLEDB.4.0;DATA
> SOURCE=c:\database.mdb"
>
> or (had this suggested to me today but it also doesnt work for very
> long) objConn.Open "Provider=MSDASQL.1;Extended
> Properties=""DSN=Ops;FIL=MSAccess;UID="";"";"
>
> Whichever connection I use, it will work fine for a short period of
> time, and then stop working again. If I edit the code, and change
> the connection to one of the other strings, it will work for a short
> while, and then stop again. Once one page fails, all pages for all
> users fail. I have tried different login names specified in the DSN
> properties, and in my ASP connections. All permissions for the IUSR
> account have been checked and double checked, I have updated MDAC
> several times (now up to 2.8), all the patches and updates I can find
> are loaded onto the server, and virus scans come up clean. I am
> closing and destroying the connections and recordsets, and diming the
> variables. I have run compact and repair on the database, but
> nothing I do fixes the error for more than half a day. Can anyone
> suggest anything?
>
> Thanks in advance,
>
> Regards,
> Walter Rands-Trevor

Do you have an automatic repair/compact process running on your database? I
have seen situations where the compacting process has resulted in a new mdb
file without the NTFS permissions that were in place for the original file.

Bob Barrows
--
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"

[Walter Rands-Trevor]

Hi Bob,

Thanks for the suggestion, but no automatic process on it. Have struck the
odd problem with running compact and repair in the past, so now I always
manually back up the db, run the process myself and double check everything
.. . . call me paranoid ;-)

- Walter


"Bob Barrows" <reb01501@NOyahoo.SPAMcom> wrote in message
news:ey9Xf24$DHA.624@TK2MSFTNGP11.phx.gbl...

> Walter Rands-Trevor wrote:

> > Hello,
> >
> > I am getting the infamous 80004005 (like just about everyone else on
> > the net it seems). Using NT4/IIS4, Access 97 DB, it is a low volume
> > (20 hits a day) site that worked perfectly for over a year. Then
> > suddenly, without me changing any code on the site, it decided to
> > start giving 80004005 errors. Basically, in trying to fix this, I
> > have tried several different connections to the db,
> >
> > objConn.ConnectionString = "DSN=Ops"
> > objConn.Open
> >
> > or
> > objConn.Open "PROVIDER=MICROSOFT.JET.OLEDB.4.0;DATA
> > SOURCE=c:\database.mdb"
> >
> > or (had this suggested to me today but it also doesnt work for very
> > long) objConn.Open "Provider=MSDASQL.1;Extended
> > Properties=""DSN=Ops;FIL=MSAccess;UID="";"";"
> >
> > Whichever connection I use, it will work fine for a short period of
> > time, and then stop working again. If I edit the code, and change
> > the connection to one of the other strings, it will work for a short
> > while, and then stop again. Once one page fails, all pages for all
> > users fail. I have tried different login names specified in the DSN
> > properties, and in my ASP connections. All permissions for the IUSR
> > account have been checked and double checked, I have updated MDAC
> > several times (now up to 2.8), all the patches and updates I can find
> > are loaded onto the server, and virus scans come up clean. I am
> > closing and destroying the connections and recordsets, and diming the
> > variables. I have run compact and repair on the database, but
> > nothing I do fixes the error for more than half a day. Can anyone
> > suggest anything?
> >
> > Thanks in advance,
> >
> > Regards,
> > Walter Rands-Trevor

>
> Do you have an automatic repair/compact process running on your database?

I

> have seen situations where the compacting process has resulted in a new

mdb

> file without the NTFS permissions that were in place for the original

file.

>
> Bob Barrows
> --
> 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"
>
>

[Walter Rands-Trevor]

Aaron (and Jeff)

Thanks for your input, I have been working through those pages and their
suggestions to see which ones apply to my circumstances, however, the error
is not currently appearing (murphy's law I guess) so at this point I am
making notes and looking for suggestions as I want to see the effect of each
suggestion as I try it. Unfortunately, as you can see in the list of things
that I outlined in my original post, most of the things in those pages I
have already tried, however, two that are interesting are setting the ("JET
OLEDB:Max Locks Per File") property of the connection and running the server
in a seperate memory process.

Firstly, my largest table has around 13,000 records in it, would this be
considered a large amount in Access, and should I try setting the max locks
to 26,000?

Secondly, I have tried setting the site to run in its own memory process in
the past, and it caused permissions errors in the form of:

Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Microsoft Access Driver] The Microsoft Jet database engine
cannot open the file '(unknown)'. It is already opened exclusively by
another user, or you need permission to view its data.

Does this mean that if you run it in a seperate process that it uses
different credentials? If so, how do you find out what these are, so I can
set permissions on the file? As soon as I return the site to the main pool,
this message clears up. As a point of interest (dont know if this has an
effect or not) the site is using anonymous access.

Thanks for your help and advice,

- Walter



"Aaron Bertrand [MVP]" <aaron@TRASHaspfaq.com> wrote in message
news:eOimI40$DHA.1548@TK2MSFTNGP12.phx.gbl...

> > Any thoughts?

>
> Well, did you bother looking at the two links I posted?
>
> --
> Aaron Bertrand
> SQL Server MVP
> [url]http://www.aspfaq.com/[/url]
>
>

[Bob Barrows [MVP]]

Walter Rands-Trevor wrote:

> Firstly, my largest table has around 13,000 records in it, would this
> be considered a large amount in Access, and should I try setting the
> max locks to 26,000?

No - that's a relatively small table

>
> Secondly, I have tried setting the site to run in its own memory
> process in the past, and it caused permissions errors in the form of:
>
> Microsoft OLE DB Provider for ODBC Drivers error '80004005'
> [Microsoft][ODBC Microsoft Access Driver] The Microsoft Jet database
> engine cannot open the file '(unknown)'. It is already opened
> exclusively by another user, or you need permission to view its data.

This is always due to a lack of permissions. If you are using anonymous
security, the IUSR account needs Change permissions on the entire folder
containing the database file - not just the file. The user needs to be able
to create, modify, and delete the ldb locking file.

If you are using Integrated security (NT Challenge or Windows
authentication), then all users of the database need Change permissions for
the folder - not just the database.

When running in its own memory process, the IWAM account is the user, not
the IUSR account, so you need to give the IWAM account permissions for that
folder.

Bob Barrows
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

[Walter Rands-Trevor]

Thank you Bob, I think you may have hit the nail on the head. The error
popped up again, so I have set the permissions on the file and folder to
allow the IWAM account change permissions (previously only had the IUSR
account in the ACL) and now the site is happily running in its own process.
Site is back up now, will be in touch if I get further errors, but thanks
for your help!

- Walter Rands-Trevor


"Bob Barrows [MVP]" <reb01501@NOyahoo.SPAMcom> wrote in message
news:OW4L9#8$DHA.4080@TK2MSFTNGP09.phx.gbl...

> Walter Rands-Trevor wrote:

> > Firstly, my largest table has around 13,000 records in it, would this
> > be considered a large amount in Access, and should I try setting the
> > max locks to 26,000?

>
> No - that's a relatively small table

> >
> > Secondly, I have tried setting the site to run in its own memory
> > process in the past, and it caused permissions errors in the form of:
> >
> > Microsoft OLE DB Provider for ODBC Drivers error '80004005'
> > [Microsoft][ODBC Microsoft Access Driver] The Microsoft Jet database
> > engine cannot open the file '(unknown)'. It is already opened
> > exclusively by another user, or you need permission to view its data.

>
> This is always due to a lack of permissions. If you are using anonymous
> security, the IUSR account needs Change permissions on the entire folder
> containing the database file - not just the file. The user needs to be

able

> to create, modify, and delete the ldb locking file.
>
> If you are using Integrated security (NT Challenge or Windows
> authentication), then all users of the database need Change permissions

for

> the folder - not just the database.
>
> When running in its own memory process, the IWAM account is the user, not
> the IUSR account, so you need to give the IWAM account permissions for

that

> folder.
>
> Bob Barrows
> --
> Microsoft MVP -- ASP/ASP.NET
> Please reply to the newsgroup. The email account listed in my From
> header is my spam trap, so I don't check it very often. You will get a
> quicker response by posting to the newsgroup.
>
>