Unable to connect to MDB in shared folder

[syvman]

Hello everyone... I have run across a very strange problem, and I'm at
my wits end, hehe. It seems that I'm unable to connect to an access
..mdb database file via Jet OLE DB Provider when I use a network shared
folder as the path AND the database is in use. In other words, if I
use "V:\databases\dbs\testdb.mdb" it will work fine (I have the V:
drive mapped to this machine's c: drive), but if I use
"\\machinename\dbs\testdb.mdb" then it will not work ('dbs' is set up
as a network shared folder). Please keep in mind that it doesn't work
ONLY when the database is in use - if the database is not in use, I am
able to connect to it just fine. This not only affects my VB app that
I'm working on, but also the datalink manager will not allow me to
connect to the MDB when I use the "\\machinename\dbs\testdb.mdb" as the
database path (by using the "Test Connection" button).
Anyone ever seen this before? This consistent across several machines,
not just mine, so I am pretty sure that someone else may have seen this
before. The reason I am required to use the machine name and network
shared folder path approach is because this app will be accessed by
others who won't have any drives mapped to this machine on the network.

Here's my connection string and connection method (the error occurs
during the .open):

Dim strDbConn As String = "Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=" _
& strDBPath
Dim dbConnection As New OleDb.OleDbConnection(strDbConn)
dbConnection.Open()

Again, when strDBPath = "V:\databases\dbs\testdb.mdb" it works fine,
even if the db is open by someone else.
When strDBPath = "\\machinename\dbs\testdb.mdb" it works only when the
database is not open by someone else.

Thanks in advance for any suggestions! Have a great day!
-Terry

 

[Cor Ligthert [MVP]]

Syman,

Just check this newsgroup on Google.
It has to do with the general security settings.

http://groups.google.com/group/micr...ed+folders&qt_g=1&searchnow=Search+this+group

However in general, this is one of the endless problems when you are using
the Jet database files instead of a real database server.

Cor

 

[Paul Clement]

On 14 Sep 2006 15:51:57 -0700, (e-mail address removed) wrote:

¤ Hello everyone... I have run across a very strange problem, and I'm at
¤ my wits end, hehe. It seems that I'm unable to connect to an access
¤ .mdb database file via Jet OLE DB Provider when I use a network shared
¤ folder as the path AND the database is in use. In other words, if I
¤ use "V:\databases\dbs\testdb.mdb" it will work fine (I have the V:
¤ drive mapped to this machine's c: drive), but if I use
¤ "\\machinename\dbs\testdb.mdb" then it will not work ('dbs' is set up
¤ as a network shared folder). Please keep in mind that it doesn't work
¤ ONLY when the database is in use - if the database is not in use, I am
¤ able to connect to it just fine. This not only affects my VB app that
¤ I'm working on, but also the datalink manager will not allow me to
¤ connect to the MDB when I use the "\\machinename\dbs\testdb.mdb" as the
¤ database path (by using the "Test Connection" button).
¤ Anyone ever seen this before? This consistent across several machines,
¤ not just mine, so I am pretty sure that someone else may have seen this
¤ before. The reason I am required to use the machine name and network
¤ shared folder path approach is because this app will be accessed by
¤ others who won't have any drives mapped to this machine on the network.
¤
¤ Here's my connection string and connection method (the error occurs
¤ during the .open):
¤
¤ Dim strDbConn As String = "Provider=Microsoft.Jet.OLEDB.4.0;Data
¤ Source=" _
¤ & strDBPath
¤ Dim dbConnection As New OleDb.OleDbConnection(strDbConn)
¤ dbConnection.Open()
¤
¤ Again, when strDBPath = "V:\databases\dbs\testdb.mdb" it works fine,
¤ even if the db is open by someone else.
¤ When strDBPath = "\\machinename\dbs\testdb.mdb" it works only when the
¤ database is not open by someone else.
¤

I'm not exactly sure what you mean by "doesn't work". Is an error being generated?

Typically problems occur when working with an Access database on a network resource when users do
not have full permissions on the folder where the database resides. Without knowing what sort of
problem your are encountering this would be my first guess.

There are no issues when using a UNC path that I am aware of.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Jim Hughes]

Be sure that another application (Like Access) is not opening the database
for Exclusive use (check the Access help.

Set the Exclusive property in the connection string appropriately.

Exclusive "Driver={Microsoft Access Driver (*.mdb)};
DBQ=C:\App1\Your_Database_Name.mdb; Exclusive=1; Uid=Your_Username;
Pwd=Your_Password;"

Shared "Driver={Microsoft Access Driver (*.mdb)};
DBQ=C:\App1\Your_Database_Name.mdb; Exclusive=0; Uid=Your_Username;
Pwd=Your_Password;"

 

[syvman]

Thanks everyone for your replies! I'll try to answer the first few
questions I saw...

Cor - I will definitely go read that post on general security settings
- after some more research last night I have determined that my problem
is definitely along those lines.

Paul - Yes, it is resulting in an "Unhandled Exception Error"... Could
not open "; file is in use. Actually, this is the error that my .net
application results in when I try to open the connection to the
database. If I try to open the database in MS Access, I get a "Could
not lock file" error.

I have determined that it is not a folder permissions issue, as I am
able to copy a different .mdb file into the same folder as the database
in question and open it read-only whether it is opened by another user
or not. There is a fundamental difference between the two .mdb files,
but I can't seem to put my finger on it. They are both Access
2002-2003 format, both have similar Security settings, and are both set
up as "shared" for the default open mode. This is really baffling.
The only other difference between the two files is their size - the one
that I am able to open (when I say "open" I mean that I am able to
actually open it in MS Access as read-only) is only a couple of hundred
megabytes in size, where as the file I am unable to open is nearly a
gig in size.

Jim - I am 99% sure that the databases are not being opened exclusively
by other users, only because I am able to connect to or open the .mdb
read-only as long as I access it through a mapped drive, not a network
share. But the problem lies in the .mdb file itself - I've at least
narrowed it down that far.

Thanks again for everyone's replies. I really appreciate you taking
the time to read this post and help me. I'm going to go read that
general security settings post and do some more research on this. If
anyone can think of anything else I might be missing, please set me
straight, hehe! Have a great day and a great weekend everyone!
-Terry

 

[Paul Clement]

On 15 Sep 2006 11:16:38 -0700, (e-mail address removed) wrote:

¤ Paul - Yes, it is resulting in an "Unhandled Exception Error"... Could
¤ not open "; file is in use. Actually, this is the error that my .net
¤ application results in when I try to open the connection to the
¤ database. If I try to open the database in MS Access, I get a "Could
¤ not lock file" error.
¤

All of these errors would indicate the Jet database engine is unable to create, access or modify the
corresponding .LDB file that is required when an Access database is opened for update or that the
database is read-only.

I would verify that the database is not read-only and that there are not any permissions on the file
itself that would override the folder permissions.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[syvman]

Well, I thought I'd just let everyone know that I was unable to figure
out why I am unable to connect to the database. I brought in some
other help, and it stumped those folks, as well.
We've found a workaround, and that is to parse the dataset that
actually gets loaded into the .mdb file. It would be much simpler to
the user to be able to use the data straight from the .mdb (the file
naming conventions and saved locations are a little convoluted), but
for the time being, this is the ony viable workaround we could find.
Again, I want to thank everyone for your help on this issue. It
stumped me - and I'm not proud to say that I was unable to figure it
out, but sometimes that happens. Everyone have a great day, and thanks
again!!!
-Terry