possible error 'could not lock file' after installing security updates?

[John Smit]

X-No-Archive: Yes


Situation a:
- 16-bit Visual Basic 3 application talks to MS Access 2.0 database
- MS Access 2.0 database is located on DFS/NTFS in network.
- MS Access 2.0 database is accessed via absolute path (F:\...)
- Don't know exactly how the app communicates with database.
Probably DAO/some kind of ODBC-link. No DSN or whatever is needed.
- All users have full control to the directory where the database resides.
- Application resides on Windows 2000 server and Windows xp client


Situation b:
- Machine is a Windows 2000 machine.
- Apache server with PHP running in SYSTEM account.
- Server accesses the same MS Access 2.0 database as mentioned above
using full network path (\\fileserver01\long_full_path\db.mdb)
- Connection has uses OLEDB 4.0
- Connection string: "Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=\\fileserver01\long_full_path\db.mdb;Mode=ReadWrite;Persist
Security Info=True;User Id=admin ;Password=;"
(I thought the Mode parameter also included: "Share Deny None")

Situation b can be replaced by any normal 32-bit program.


Both applications could successfully access the database simultaniously.
A week ago something went wrong....

1. If VB3 app client connects to database everything goes well.
2. If a second VB3 app client connects to database everything goes well.
3. OK

1. If VB3 app client connects to database everything goes well.
2. If a 32-bit application then connects to database then the error
"Could not lock file" appears.
3. At this point the .ldb file seems to be locked/inaccessible?!? Even
not viewable with notepad. The .ldb is viewable with notepad between
step 1 and 2. The first VB3 app client can continue to work without a
problem.
The strange thing is that at this point... when viewing the
properties of the .ldb in explorer there is only a 'General' sheet and
no 'Security' sheet. Between step 1 and 2 there is a 'Security' sheet.
4. The .ldb file disappears when the VB3 app client application exits.
The .ldb doesn't always automatically disappear.



The following KB articles had been installed when the problem occurred.
Could one of them be the victim?
KB885835
KB885836
KB873339
KB889293

If I place the database on a FAT partition the problem goes away?!? NTFS
permissions?

Help!

 

[Andy]

I can't offer much, but we have very similiar problem which seems to be
caused by KB885835, or XPsp2 with Office 2003. There are other
combinations, but haven't found them yet. Basically we have 16bit VB
app constantly reading a writing to a access 2 db, when a user queries
the db with one of the above patches\service packs in place, they lock
the table and appear to corrupt the ldb file. The problem only goes
away when everyone comes out of the db so that the ldb is removed and
recreated.

Any further info much appreciated.

Andy

 

[John Smit]

X-No-Archive: Yes

I can't offer much, but we have very similiar problem which seems to be
caused by KB885835, or XPsp2 with Office 2003. There are other
combinations, but haven't found them yet. Basically we have 16bit VB
app constantly reading a writing to a access 2 db, when a user queries
the db with one of the above patches\service packs in place, they lock
the table and appear to corrupt the ldb file. The problem only goes
away when everyone comes out of the db so that the ldb is removed and
recreated.

Any further info much appreciated.

Thank you very much. The problem disappeared when we had uninstalled
KB885835.

I found this article some days ago. There are some interesting things
from point 6.