Jet OleDB Unspecified Error

[Rob]

I have a Windows 2000 server with the latest updates and patches from
Microsoft (Service Pack 3). I have version 2.7 of the MDAC, and
version 8.0 of Jet OLEDB. I'm running Access 2000, and COM+ Components
written in VB6 SP5 that access SQL Server 2000 database tables.

I have some ASP scripts that connect to Access databases as follows.

' Open connection
Set objConn = Server.CreateObject("ADODB.Connection")
If (Not IsObject(objConn)) Then
Response.Redirect "Session_Error.asp"
End If
' First clear errors
objConn.Errors.Clear

' Now open the connection
objConn.Provider = "Microsoft.Jet.OLEDB.4.0"
objConn.Open "Data Source=" & Session("MDBLoc") & "; Jet
OLEDB:Database Password=" & Session("MDBPwd")
CheckErrors("ADOConnection_OpenFailed")
objConn.CursorLocation = adUseClient

This logic works fine for weeks at a time. And then, and I'm not sure
how or why, the scripts that access the Access DBs stop working. The
connection fails with the following error.

Microsoft JET OLE DB Provider (0x80004005)
Unspecified Error
Filename xxx, Line Number xxx

The following line is the one that generates the error.

objConn.Open "Data Source=" & Session("MDBLoc") & "; Jet
OLEDB:Database

I do not know what is causing this problem to appear, but it seems to
occur when I reboot the system. I have to reboot again to recover.
Then it works fine for a week or two. But ultimately, it fails again.

It's not the Session variables, because I used some diagnostics to
verify that they are correct. It's not permissions, because I have the
anonymous user setup with all access rights to the temporary directory
in Winnt\System\Temp. It's not the environment variables; they are set
properly. It would never work if either of these problems existed.

I'm beginning to think that a bug exists in the OLE DB provider that
is leaving a file in the temporary directory locked as "in use". Once
this occurs, the ASPs that connect to the Access databases fail. All
of them fail. But the ASPs that access the SQL Server database tables
work, as do those that use COM+ Components.

I've been to the Microsoft site; no solutions there that I haven't
tried. I've searched the net to no avail. The only solution is reboot
the box, sometimes twice, and that's not acceptable.

Does anyone have any ideas?

Rob

[Ray at]

"Rob" <rmgalante@yahoo.com> wrote in message
news:2d6606e8.0312050939.7ce2c88e@posting.google.c om...

> I have a Windows 2000 server with the latest updates and patches from

>
> Microsoft JET OLE DB Provider (0x80004005)
> Unspecified Error
> Filename xxx, Line Number xxx
>
> The following line is the one that generates the error.
>
> objConn.Open "Data Source=" & Session("MDBLoc") & "; Jet
> OLEDB:Database
>

Modify your code so you can try to get a better idea of what's going on.

Dim sConnectionString
On Error Resume Next
sConnectionString = "Data Source=" & Session("MDBLoc") & "; Jet
OLEDB:Database" '?
objConn.Open sConnectionString
If Err.Number <> 0 Then
Response.Write "Sorry. There was an error. Please copy and paste this
page into an e-mail and send it to the webmaster.<br>"
Response.Write "sConnectionstring = " & sConnectionString & "<br>"
Response.End
End If

You could always have it e-mail you the value or whatever.

Ray at home

[Rob Galante]

Hi Ray,

Thanks for your response. Generally, my code runs with error trapping
disabled so that I don't get unsightly errors. But when the problem
manifests, I cannot see what's happening because it continues through
with a bad connection. So I enable the error trapping, to see the ASP
error that is occurring. That's how I found the error 80004005
Unspecified Error.

I have a hypothesis that two sites on my server with the same Access
database name might be causing the same temporary JET files to lock "in
use". I don't have a way to prove this yet. But rebooting and deleting
the temporary JET files seems to work.

*** Sent via Developersdex [url]http://www.developersdex.com[/url] ***
Don't just participate in USENET...get rewarded for it!

[Bob Barrows]

Rob Galante wrote:

> Hi Ray,
>
> Thanks for your response. Generally, my code runs with error trapping
> disabled so that I don't get unsightly errors. But when the problem
> manifests, I cannot see what's happening because it continues through
> with a bad connection. So I enable the error trapping, to see the ASP
> error that is occurring. That's how I found the error 80004005
> Unspecified Error.
>
> I have a hypothesis that two sites on my server with the same Access
> database name might be causing the same temporary JET files to lock
> "in use". I don't have a way to prove this yet. But rebooting and
> deleting the temporary JET files seems to work.
>

I suppose this might happen if you aren't scrupulous about closing and
destroying your recordset and connection objects when you are done with
them. Disabling error trapping may prevent this cleanup code from running
even if you have been scrupulous about including the cleanup code.

I'm assuming you've given the IUSR account Change permissions on the folder
containing the database files ...

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"

[Rob]

"Bob Barrows" <reb01501@NOyahoo.SPAMcom> wrote in message news:<#ztGvf$uDHA.2308@TK2MSFTNGP09.phx.gbl>...

> Rob Galante wrote:

> > Hi Ray,
> >
> > Thanks for your response. Generally, my code runs with error trapping
> > disabled so that I don't get unsightly errors. But when the problem
> > manifests, I cannot see what's happening because it continues through
> > with a bad connection. So I enable the error trapping, to see the ASP
> > error that is occurring. That's how I found the error 80004005
> > Unspecified Error.
> >
> > I have a hypothesis that two sites on my server with the same Access
> > database name might be causing the same temporary JET files to lock
> > "in use". I don't have a way to prove this yet. But rebooting and
> > deleting the temporary JET files seems to work.
> >

>
> I suppose this might happen if you aren't scrupulous about closing and
> destroying your recordset and connection objects when you are done with
> them. Disabling error trapping may prevent this cleanup code from running
> even if you have been scrupulous about including the cleanup code.
>
> I'm assuming you've given the IUSR account Change permissions on the folder
> containing the database files ...
>
> Bob Barrows

Hi Bob,

Image that you are an ISP. You have 250 users writing ASPs. You cannot
be expected to review all of these programmers' scripts. Suppose 1, 2
or more are not "scrupulous" about closing their recordsets and
connections. Are you suggesting that the only valid solution to this
problem is blame the programmers and reboot the box?

I say, "Blame the operating system, or at least the Jet OLE DB
Provider."

"Blame the programmers" is not an acceptable solution.

[Bob Barrows]

Rob wrote:

> "Bob Barrows" <reb01501@NOyahoo.SPAMcom> wrote in message
> news:<#ztGvf$uDHA.2308@TK2MSFTNGP09.phx.gbl>...

>> Rob Galante wrote:

>>> Hi Ray,
>>>
>>> Thanks for your response. Generally, my code runs with error
>>> trapping
>>> disabled so that I don't get unsightly errors. But when the problem
>>> manifests, I cannot see what's happening because it continues
>>> through
>>> with a bad connection. So I enable the error trapping, to see the
>>> ASP
>>> error that is occurring. That's how I found the error 80004005
>>> Unspecified Error.
>>>
>>> I have a hypothesis that two sites on my server with the same Access
>>> database name might be causing the same temporary JET files to lock
>>> "in use". I don't have a way to prove this yet. But rebooting and
>>> deleting the temporary JET files seems to work.
>>>

>>
>> I suppose this might happen if you aren't scrupulous about closing
>> and
>> destroying your recordset and connection objects when you are done
>> with
>> them. Disabling error trapping may prevent this cleanup code from
>> running
>> even if you have been scrupulous about including the cleanup code.
>>
>> I'm assuming you've given the IUSR account Change permissions on the
>> folder
>> containing the database files ...
>>
>> Bob Barrows

>
> Hi Bob,
>
> Image that you are an ISP. You have 250 users writing ASPs. You cannot
> be expected to review all of these programmers' scripts. Suppose 1, 2
> or more are not "scrupulous" about closing their recordsets and
> connections. Are you suggesting that the only valid solution to this
> problem is blame the programmers and reboot the box?

I've heard of hosting companies cancelling the accounts of those whose
applications consistently cause the server to crash. There was a guy on one
of these newsgroups about a month ago whining that his account got cancelled
because the hosting company blamed his application for crashing their
server.

>
> I say, "Blame the operating system, or at least the Jet OLE DB
> Provider."

Whether the OS or the provider (who said anything about the provider being
at fault? It's not.) is to blame is irrelevant. There are good coding
practices that will prevent one of the causes of memory leaks which can
crash IIS. Scrupulously closing and destroying your ADO objects is one of
those.

>
> "Blame the programmers" is not an acceptable solution.

Tough.

When debugging a problem, you need to eliminate all the possible causes of
the problem. I was merely suggesting one of the possible causes. If you want
to ignore my suggestion, that's surely up to you.

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"

[Bob Lehmann]

>>>"Blame the programmers" is not an acceptable solution.

But bad programming practices is????

Whether you are using IIS/ASP/Access or Apache/PHP/MySQL, managing resources
is always a consideration. So according to your perspective on things, all
the Operating Systems/Languages/DB Systems are flawed, and should be blamed
for whatever problems are caused.

Good plan. Good Luck.

Bob Lehmann

"Rob" <rmgalante@yahoo.com> wrote in message
news:2d6606e8.0312061204.5cdc73b6@posting.google.c om...

> "Bob Barrows" <reb01501@NOyahoo.SPAMcom> wrote in message

news:<#ztGvf$uDHA.2308@TK2MSFTNGP09.phx.gbl>...

> > Rob Galante wrote:

> > > Hi Ray,
> > >
> > > Thanks for your response. Generally, my code runs with error trapping
> > > disabled so that I don't get unsightly errors. But when the problem
> > > manifests, I cannot see what's happening because it continues through
> > > with a bad connection. So I enable the error trapping, to see the ASP
> > > error that is occurring. That's how I found the error 80004005
> > > Unspecified Error.
> > >
> > > I have a hypothesis that two sites on my server with the same Access
> > > database name might be causing the same temporary JET files to lock
> > > "in use". I don't have a way to prove this yet. But rebooting and
> > > deleting the temporary JET files seems to work.
> > >

> >
> > I suppose this might happen if you aren't scrupulous about closing and
> > destroying your recordset and connection objects when you are done with
> > them. Disabling error trapping may prevent this cleanup code from

running

> > even if you have been scrupulous about including the cleanup code.
> >
> > I'm assuming you've given the IUSR account Change permissions on the

folder

> > containing the database files ...
> >
> > Bob Barrows

>
> Hi Bob,
>
> Image that you are an ISP. You have 250 users writing ASPs. You cannot
> be expected to review all of these programmers' scripts. Suppose 1, 2
> or more are not "scrupulous" about closing their recordsets and
> connections. Are you suggesting that the only valid solution to this
> problem is blame the programmers and reboot the box?
>
> I say, "Blame the operating system, or at least the Jet OLE DB
> Provider."
>
> "Blame the programmers" is not an acceptable solution.

[Aaron Bertrand [MVP]]

> Image that you are an ISP. You have 250 users writing ASPs. You cannot

> be expected to review all of these programmers' scripts. Suppose 1, 2
> or more are not "scrupulous" about closing their recordsets and
> connections. Are you suggesting that the only valid solution to this
> problem is blame the programmers and reboot the box?
>
> I say, "Blame the operating system, or at least the Jet OLE DB
> Provider."

do while 1 <> 2
a = a + 1
loop

Blame the operating system, or at least the ASP engine?

Give me a break. Blaming the technology for bad programming techniques is
the most absurd thing I have heard in a long time.

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

[GVaught]

Something that might help when you open an account and the user expects to
use ASP is to Configure their site as an Application. Doing this will help
prevent their site from taking down the whole site for their bad
programming. For the existing sites, it is a matter of going in during the
middle of the night and configuring these sites to run in there own process.

Any knowledgeable ASP programmer will close their connections and
recordsets. It is the novice that you have to watch out for. If a user is
constantly crashing a site due to poor programming and you can determine
that it is that user's code; you bet your bottom dollar you can blame
him/her.

Look at it from this perspective. Lets say one of your other customers is
running a business on your site that generates thousands of dollars per
month for their company as they accept orders from their customers. They
know their programmers are responsible programmers and ensure that the site
would not effect any other sites. However, you have this one novice or
clueless programmer that is constantly bringing down the website. Your other
customer looses several thousands dollars in one day. Then three days later
he looses several more thousand dollars, because now instead of being down a
few minutes, you are down several days because you keep crashing. After
awhile this customer may decide your service isn't worth the contract it was
written on and silently leaves taking their business elsewhere.

Who do you want to keep? Just a thought!


"Aaron Bertrand [MVP]" <aaron@TRASHaspfaq.com> wrote in message
news:%23eB8eIFvDHA.2712@TK2MSFTNGP11.phx.gbl...

> > Image that you are an ISP. You have 250 users writing ASPs. You cannot
> > be expected to review all of these programmers' scripts. Suppose 1, 2
> > or more are not "scrupulous" about closing their recordsets and
> > connections. Are you suggesting that the only valid solution to this
> > problem is blame the programmers and reboot the box?
> >
> > I say, "Blame the operating system, or at least the Jet OLE DB
> > Provider."

>
> do while 1 <> 2
> a = a + 1
> loop
>
> Blame the operating system, or at least the ASP engine?
>
> Give me a break. Blaming the technology for bad programming techniques is
> the most absurd thing I have heard in a long time.
>
> --
> Aaron Bertrand
> SQL Server MVP
> [url]http://www.aspfaq.com/[/url]
>
>

[Rob]

"GVaught" <glvaught@hotmail.com> wrote in message news:<emKY4qIvDHA.3744@TK2MSFTNGP11.phx.gbl>...

> Something that might help when you open an account and the user expects to
> use ASP is to Configure their site as an Application. Doing this will help
> prevent their site from taking down the whole site for their bad
> programming. For the existing sites, it is a matter of going in during the
> middle of the night and configuring these sites to run in there own process.
>
> Any knowledgeable ASP programmer will close their connections and
> recordsets. It is the novice that you have to watch out for. If a user is
> constantly crashing a site due to poor programming and you can determine
> that it is that user's code; you bet your bottom dollar you can blame
> him/her.
>
> Look at it from this perspective. Lets say one of your other customers is
> running a business on your site that generates thousands of dollars per
> month for their company as they accept orders from their customers. They
> know their programmers are responsible programmers and ensure that the site
> would not effect any other sites. However, you have this one novice or
> clueless programmer that is constantly bringing down the website. Your other
> customer looses several thousands dollars in one day. Then three days later
> he looses several more thousand dollars, because now instead of being down a
> few minutes, you are down several days because you keep crashing. After
> awhile this customer may decide your service isn't worth the contract it was
> written on and silently leaves taking their business elsewhere.
>
> Who do you want to keep? Just a thought!
>
>
> "Aaron Bertrand [MVP]" <aaron@TRASHaspfaq.com> wrote in message
> news:%23eB8eIFvDHA.2712@TK2MSFTNGP11.phx.gbl...

> > > Image that you are an ISP. You have 250 users writing ASPs. You cannot
> > > be expected to review all of these programmers' scripts. Suppose 1, 2
> > > or more are not "scrupulous" about closing their recordsets and
> > > connections. Are you suggesting that the only valid solution to this
> > > problem is blame the programmers and reboot the box?
> > >
> > > I say, "Blame the operating system, or at least the Jet OLE DB
> > > Provider."

> >
> > do while 1 <> 2
> > a = a + 1
> > loop
> >
> > Blame the operating system, or at least the ASP engine?
> >
> > Give me a break. Blaming the technology for bad programming techniques is
> > the most absurd thing I have heard in a long time.
> >
> > --
> > Aaron Bertrand
> > SQL Server MVP
> > [url]http://www.aspfaq.com/[/url]
> >
> >

Aaron,

Thanks for the suggestion. Isolating the site in its own application
is a nice idea. You are right about some bad programming practices.
One that comes to my mind is the "Buffer Overflow" practice. However,
I don't buy that excuse when it comes to database connections and
endless loops. It's just my opinion.

I've determined that the application that is locking the Jet temporary
files as "in use" are DLLHost applications. But I'm not sure that this
condition is the cause of the problem yet.

One set of servers running the same scripts does not experience this
problem. One set of servers running this set of scripts and others
does. I think its about time this problem finds a solution.

Rob

[Aaron Bertrand [MVP]]

> One set of servers running the same scripts does not experience this

> problem. One set of servers running this set of scripts and others
> does. I think its about time this problem finds a solution.

It already has one (actually several). Close and destroy your connections!
Or use a better database! Or upgrade your developers!

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

[Rob]

"Aaron Bertrand [MVP]" <aaron@TRASHaspfaq.com> wrote in message news:<uxsabTMvDHA.3256@TK2MSFTNGP11.phx.gbl>...

> > One set of servers running the same scripts does not experience this
> > problem. One set of servers running this set of scripts and others
> > does. I think its about time this problem finds a solution.

>
> It already has one (actually several). Close and destroy your connections!
> Or use a better database! Or upgrade your developers!

I said that this problem occurs after a reboot. The system has not
been running long enough to generate memory leaks from connections
that have not been closed.

In the real world, you can't just change the database, upgrade your
developers, or modify code. You suggestions are not valid. If one of
your clients was to implement such suggestions, they would spend
thousands of hours and dollars.

MVP? Hardly.

[John Beschler]

>

>MVP? Hardly.

You're not likely to get a lot of help here if you start
insulting people. I read posts here fairly regularly and
Aaron has helped many people with their issues.

If you don't agree with the advice, either ignore it or
say so, but don't insult the poster.

John

[Rob]

[email]rmgalante@yahoo.com[/email] (Rob) wrote in message news:<2d6606e8.0312050939.7ce2c88e@posting.google. com>...

> I have a Windows 2000 server with the latest updates and patches from
> Microsoft (Service Pack 3). I have version 2.7 of the MDAC, and
> version 8.0 of Jet OLEDB. I'm running Access 2000, and COM+ Components
> written in VB6 SP5 that access SQL Server 2000 database tables.
>
> I have some ASP scripts that connect to Access databases as follows.
>
> ' Open connection
> Set objConn = Server.CreateObject("ADODB.Connection")
> If (Not IsObject(objConn)) Then
> Response.Redirect "Session_Error.asp"
> End If
> ' First clear errors
> objConn.Errors.Clear
>
> ' Now open the connection
> objConn.Provider = "Microsoft.Jet.OLEDB.4.0"
> objConn.Open "Data Source=" & Session("MDBLoc") & "; Jet
> OLEDB:Database Password=" & Session("MDBPwd")
> CheckErrors("ADOConnection_OpenFailed")
> objConn.CursorLocation = adUseClient
>
> This logic works fine for weeks at a time. And then, and I'm not sure
> how or why, the scripts that access the Access DBs stop working. The
> connection fails with the following error.
>
> Microsoft JET OLE DB Provider (0x80004005)
> Unspecified Error
> Filename xxx, Line Number xxx
>
> The following line is the one that generates the error.
>
> objConn.Open "Data Source=" & Session("MDBLoc") & "; Jet
> OLEDB:Database
>
> I do not know what is causing this problem to appear, but it seems to
> occur when I reboot the system. I have to reboot again to recover.
> Then it works fine for a week or two. But ultimately, it fails again.
>
> It's not the Session variables, because I used some diagnostics to
> verify that they are correct. It's not permissions, because I have the
> anonymous user setup with all access rights to the temporary directory
> in Winnt\System\Temp. It's not the environment variables; they are set
> properly. It would never work if either of these problems existed.
>
> I'm beginning to think that a bug exists in the OLE DB provider that
> is leaving a file in the temporary directory locked as "in use". Once
> this occurs, the ASPs that connect to the Access databases fail. All
> of them fail. But the ASPs that access the SQL Server database tables
> work, as do those that use COM+ Components.
>
> I've been to the Microsoft site; no solutions there that I haven't
> tried. I've searched the net to no avail. The only solution is reboot
> the box, sometimes twice, and that's not acceptable.
>
> Does anyone have any ideas?
>
> Rob

I have reproduced the problem after another reboot only this time I
was looking at the COM+ Transaction Statistics. This problem is not
caused by memory leaks due to connections not being closed. The system
has not been running long enough or under enough load to justify such
a claim.

I noticed that under normal operations, the current panel's statistics
are as follows.

Active: 0
Max Active: 1
In Doubt: 0

Before I rebooted, I looked one more time. The statistics were as
follows.

Active: 8
Max Active: 8
In Doubt: 0

I was not able to delete the COM+ application and rebuild it. So I
rebooted the system, and rebuilt the COM+ application.

The scripts were unable to connect to the Access databases. I reboot
the system again. All is well.

[Aaron Bertrand - MVP]

> I said that this problem occurs after a reboot.

If there isn't a problem, why are you constantly rebooting your server(s)?
Inquiring minds want to know! You said:

"And then, and I'm not sure how or why, the scripts that access the Access
DBs stop working."

When did you ever mention anything about a reboot CAUSING the problem? From
what I can tell, you've stated multiple times that rebooting SOLVES the
issue.

Also, I wasn't telling you to close your connection objects to fix whatever
your current problem is; I was merely telling you one thing you can do to
help eliminate problems in the future.

> MVP? Hardly.

LOL!

Okay, continue to propogate horrible programming practices, and continue to
believe that you can just blame the technology for sloppiness in your
development. Obviously the suggestions here are falling on deaf ears.

Oh, and if you want to solve the problem, quit whining here and go to
[url]http://www.aspfaq.com/80004005[/url] for potential causes.
[url]http://www.aspfaq.com/2009[/url] is a good place to start.

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

[Bob Barrows]

Rob wrote:

>> Rob

>
> I have reproduced the problem after another reboot only this time I
> was looking at the COM+ Transaction Statistics. This problem is not
> caused by memory leaks due to connections not being closed.

I never said it was.

I was reacting to the fact that you said the lock files were still present
which suggested to me that
a) IUSR had insufficient permissions to delete them
or
b) an unclosed connection was preventing the lock files from being deleted.

Mind you, these were suggestions only. It was you who chose to take it
personally and get insulted at the thought that somebody might be
criticizing your coding style.

I suggest that you did not give us enough information to properly diagnose
the problem.

Now, I'm not clear. Are you saying you've solved the problem, or that you've
figured out how to reproduce it?

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.

[Rob]

[email]rmgalante@yahoo.com[/email] (Rob) wrote in message news:<2d6606e8.0312050939.7ce2c88e@posting.google. com>...

> I have a Windows 2000 server with the latest updates and patches from
> Microsoft (Service Pack 3). I have version 2.7 of the MDAC, and
> version 8.0 of Jet OLEDB. I'm running Access 2000, and COM+ Components
> written in VB6 SP5 that access SQL Server 2000 database tables.
>
> I have some ASP scripts that connect to Access databases as follows.
>
> ' Open connection
> Set objConn = Server.CreateObject("ADODB.Connection")
> If (Not IsObject(objConn)) Then
> Response.Redirect "Session_Error.asp"
> End If
> ' First clear errors
> objConn.Errors.Clear
>
> ' Now open the connection
> objConn.Provider = "Microsoft.Jet.OLEDB.4.0"
> objConn.Open "Data Source=" & Session("MDBLoc") & "; Jet
> OLEDB:Database Password=" & Session("MDBPwd")
> CheckErrors("ADOConnection_OpenFailed")
> objConn.CursorLocation = adUseClient
>
> This logic works fine for weeks at a time. And then, and I'm not sure
> how or why, the scripts that access the Access DBs stop working. The
> connection fails with the following error.
>
> Microsoft JET OLE DB Provider (0x80004005)
> Unspecified Error
> Filename xxx, Line Number xxx
>
> The following line is the one that generates the error.
>
> objConn.Open "Data Source=" & Session("MDBLoc") & "; Jet
> OLEDB:Database
>
> I do not know what is causing this problem to appear, but it seems to
> occur when I reboot the system. I have to reboot again to recover.
> Then it works fine for a week or two. But ultimately, it fails again.
>
> It's not the Session variables, because I used some diagnostics to
> verify that they are correct. It's not permissions, because I have the
> anonymous user setup with all access rights to the temporary directory
> in Winnt\System\Temp. It's not the environment variables; they are set
> properly. It would never work if either of these problems existed.
>
> I'm beginning to think that a bug exists in the OLE DB provider that
> is leaving a file in the temporary directory locked as "in use". Once
> this occurs, the ASPs that connect to the Access databases fail. All
> of them fail. But the ASPs that access the SQL Server database tables
> work, as do those that use COM+ Components.
>
> I've been to the Microsoft site; no solutions there that I haven't
> tried. I've searched the net to no avail. The only solution is reboot
> the box, sometimes twice, and that's not acceptable.
>
> Does anyone have any ideas?
>
> Rob

Well my investigation has turned up the following.

1. The ASP scripts are not causing the problem. They are merely a
symptom of it, as I suspected.

2. One of our systems was rebooting during power failures. It was not
plugged into a UPS with battery backup. It is a development server, so
we plugged it into a surge protected outlet instead. The first reboot
would occasionally leave COM+ components in an active state. These
components synchronize data between SQL Server database tables and
Access DB tables.

3. The components that were causing the problem were implementing the
IObjectControl interface, and they returned TRUE for the CanBePooled
method. These components should not be pooled by COM+ Services because
they do not support the Free-Threaded concurrency model; they are
apartment threaded.

Setting CanBePooled to FALSE seems to have eliminated the problem. But
only time will tell. The system survives manual reboots intact,
however, which is reassuring.

I'll post another reply in a couple of months, if the system remains
stable.

[Bob Barrows]

Rob wrote:

>
> I'll post another reply in a couple of months, if the system remains
> stable.

Thanks for the feedback. I hope all goes well.

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"