Greetings,
We created a vb6-app, that uses two Access2000 databases in a WinNt4-sp5 environment. The vb6-app uses standard data controls to talk to the databases.
We installed the app at the client's. The systems test was performed using a NT system administrator's account. All went well.
Next, we started the user test, logged on to NT as a user. All of a sudden one database was unreachable. The error was twofold: "File '' not found" and "Could not lock file". These messages were generated by only one form, and for only one database. All other database access appearantly succeeded.
We expect the problem to stem from register or dll privileges, allowing administrators and disallowing users. We searched the ms knowledge base and the developer network for known problems with Access 2k, VB6, ADO and WinNT4-sp5, to little avail.
Ideas anyone?
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Greetings,
We're not using dsns. We're using VB data controls and ADO connection objects that establish connections themselves. We use this method all the time and never had this problem.
We didn't try MSDE because we rely on the Access reports. Converting this to any other reporting mechanism costs too much time.
Yes, we gave explicit access permission to the database folder(s), and the temporary folders, and the system folder even.
Any other ideas?
Greetings,
We did contact Microsoft and after an extensive 3 month search period, we decided to try something. And we solved the problem. Lucky, I guess.
What was the problem? The NT operating system was unable to lock the MS Access database file (or the .ldb file).
First, we assumed that could be caused by the use of VB Data controls, that had their own, seperate database connection. Since there already was a global connection to the same database, we decided to throw out the Data controls. That alleviated a bit of the stress.
Now, we only ran into trouble when more than three people simultaneously accessed the application. Multi-user problems? Us?
So we dug into the code and disected every line. And as it turned out, most of the database connections were coded wrong. Where recordsets attached themselves to the connection, the code stated:
myADORecordset.ActiveConne
instead of this:
Set myADORecordset.ActiveConne
Now what's the difference?
The second, normal line takes an existing connection and hands it to the recordset. The same port is used, the same process, the same memory, the same pool.
The first line takes the default value of the connection, which is its connection string, and hands that to the recordset. That in turn opens a new connection, although based on the same connection string, but possibly using a different port, different process, different memory, and different pool.
Hence every recordset in the application created its own connection, instead of all recordsets using one and the same connection. NT simply couldn't keep up.
We didn't think of this first, and then solved it. Rather, we stumbled over it and started to look for implications. We fixed it, saw that it worked, and then looked for the rationale.
This question can be paqed.
Imagine!
Business Accounts
Answer for Membership
by: XstaticXPosted on 2002-11-14 at 14:12:33ID: 7450365
Are you using ODBC DSN's? Theres a number of areas that can cause problems there. Just out of interest, have you tried using MSDE? Its free and gives better support in a multi user environment.
Also, have you given explict access rights to the Folder where the DataBase lives?