By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,414 Members | 2,919 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,414 IT Pros & Developers. It's quick & easy.

Full, simple, instructions for connecting my C# app to an Access database?

P: n/a
I'm new to this game. I can find my way around C# without any trouble,
and I've used Access, a little bit, in the past. Now a friend wants an
application of mine to read from his Access database. He's sent me the
..mdb file and a username and password, also an .mdw security file, and
I've tried to connect to it, using a couple of sample programs I found
on the web. Here's the critical code (<path>, <user>, and <password>
of course filling in for actual values):

static readonly string CONNECTION_STRING =
"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=<path>.mdb;user
id=<user>;password=<password>";
....
connection_ = new OleDbConnection(Metadata.CONNECTION_STRING);
connection_.Open();

Which gives me this result:
Error :Cannot start your application. The workgroup information file is missing or opened exclusively by another user.


I have tried to establish the mdw file he sent me as my MS Access
Database, using the ODBC Data Source Administrator, but it made no
difference.

I do not have MS Access installed on my development machine.

I would appreciate a detailed but minimal set of instructions to get
this working. Thanks in advance.

Nov 13 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Try just storing the MDW in the same folder as the database of the same
name. I presume your colleague gave you a valid userid and password that are
defined in the MDW; if not, you need to get those if the database has been
secured. Alas, very few of us in this newsgroup do much with any of the
C-family of languages, and many of us don't do any ADO.NET, or don't do
much.

I trust you have installed and have references to the ADO.NET library for
C#, or perhaps the "classic" ADO library. At least the classic ADO library
is in the "MDAC" from Microsoft. If you don't have it already, download the
most current version and install it.

Not really pertinent to your particular issues, but just for the record,
Access is the user interface and development tool. The default database
engine used with Access is Jet. What you have is a Jet database -- those are
often called "Access databases". But Access can be used as a front-end to
any ODBC compliant database, and with ADO, to any database that has an ADODB
data provider.

You'll have a better chance of getting the answers you need if you will
visit a newsgroup that is devoted to ADO.NET or C# database access. I
suspect you'll be able to find one that is suitable at the free newsserver
news.microsoft.com.

Larry Linson
Microsoft Access MVP

<ca***********@gmail.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...
I'm new to this game. I can find my way around C# without any trouble,
and I've used Access, a little bit, in the past. Now a friend wants an
application of mine to read from his Access database. He's sent me the
.mdb file and a username and password, also an .mdw security file, and
I've tried to connect to it, using a couple of sample programs I found
on the web. Here's the critical code (<path>, <user>, and <password>
of course filling in for actual values):

static readonly string CONNECTION_STRING =
"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=<path>.mdb;user
id=<user>;password=<password>";
...
connection_ = new OleDbConnection(Metadata.CONNECTION_STRING);
connection_.Open();

Which gives me this result:
Error :Cannot start your application. The workgroup information file is
missing or opened exclusively by another user.
I have tried to establish the mdw file he sent me as my MS Access
Database, using the ODBC Data Source Administrator, but it made no
difference.

I do not have MS Access installed on my development machine.

I would appreciate a detailed but minimal set of instructions to get
this working. Thanks in advance.

Nov 13 '05 #2

P: n/a
Thanks, Larry.

I tried naming the .mdw file the same as the .mdb (it was already in
the same folder), to no avail. Thank you for the terminological
clarification, too. I'll go ask on another newsgroup.

--Carl

Nov 13 '05 #3

P: n/a
ca***********@gmail.com wrote in
news:11*********************@z14g2000cwz.googlegro ups.com:
I tried naming the .mdw file the same as the .mdb (it was already
in the same folder), to no avail. Thank you for the
terminological clarification, too. I'll go ask on another
newsgroup.


Um, you *never* want the MDW and the MDB file to have the same name
if they are stored in the same folder. The reason is that, given the
fact that an MDW is just a special kind of MDB, when it's in use,
there's a recordlocking file, *.LDB, with "*" being the name of the
MDB/MDW. If you've got the same file name for both, you end up with
a collision on the LDB file.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #4

P: n/a
<ca***********@gmail.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...
I'm new to this game. I can find my way around C# without any trouble,
and I've used Access, a little bit, in the past. Now a friend wants an
application of mine to read from his Access database. He's sent me the
.mdb file and a username and password, also an .mdw security file, and
I've tried to connect to it, using a couple of sample programs I found
on the web. Here's the critical code (<path>, <user>, and <password>
of course filling in for actual values):

static readonly string CONNECTION_STRING =
"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=<path>.mdb;user
id=<user>;password=<password>";
...
connection_ = new OleDbConnection(Metadata.CONNECTION_STRING);
connection_.Open();

Which gives me this result:
Error :Cannot start your application. The workgroup information file is
missing or opened exclusively by another user.


I have tried to establish the mdw file he sent me as my MS Access
Database, using the ODBC Data Source Administrator, but it made no
difference.

I do not have MS Access installed on my development machine.

I would appreciate a detailed but minimal set of instructions to get
this working. Thanks in advance.


You don't seem to have specified which mdw file to use. As part of the
connection string you could have:

"Jet OLEDB:System database=C:\MyFolder\MyWorkgroup.mdw"

Have a look at http://support.microsoft.com/kb/q191754/ for examples. Also
note that whether you are using ADO or ADO.NET one of the few things left
unchanged is the format of the connection string.

Nov 13 '05 #5

P: n/a
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86...
ca***********@gmail.com wrote in
news:11*********************@z14g2000cwz.googlegro ups.com:
I tried naming the .mdw file the same as the .mdb (it was already
in the same folder), to no avail. Thank you for the
terminological clarification, too. I'll go ask on another
newsgroup.


Um, you *never* want the MDW and the MDB file to have the same name
if they are stored in the same folder. The reason is that, given the
fact that an MDW is just a special kind of MDB, when it's in use,
there's a recordlocking file, *.LDB, with "*" being the name of the
MDB/MDW. If you've got the same file name for both, you end up with
a collision on the LDB file.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

A collision sounds dangerous, damaging, if not fatal. Have you tried this
yourself and found what damage is caused. Out of curiosity, I tried this
with AccXP and found that I could edit the database as normal. A single ldb
file is created with two entries per login.
Not that this is desirable, nor have I ever previously used the same
name/location for both files, but it does give more detail than the answer
"don't do this or there'll be a collision". Or perhaps you know further
details of the effects...


Nov 13 '05 #6

P: n/a
Thanks, Justin,

That worked beautifully. This is exactly the piece of information I
was missing. For the record, the mdw and mdb names were the same in
this case and it worked fine.

Peace,
--Carl

Nov 13 '05 #7

P: n/a
"Justin Hoffman" <j@b.com> wrote in
news:d9**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com:
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86...
ca***********@gmail.com wrote in
news:11*********************@z14g2000cwz.googlegro ups.com:
I tried naming the .mdw file the same as the .mdb (it was
already in the same folder), to no avail. Thank you for the
terminological clarification, too. I'll go ask on another
newsgroup.


Um, you *never* want the MDW and the MDB file to have the same
name if they are stored in the same folder. The reason is that,
given the fact that an MDW is just a special kind of MDB, when
it's in use, there's a recordlocking file, *.LDB, with "*" being
the name of the MDB/MDW. If you've got the same file name for
both, you end up with a collision on the LDB file.


A collision sounds dangerous, damaging, if not fatal. Have you
tried this yourself and found what damage is caused. Out of
curiosity, I tried this with AccXP and found that I could edit the
database as normal. A single ldb file is created with two entries
per login. Not that this is desirable, nor have I ever previously
used the same name/location for both files, but it does give more
detail than the answer "don't do this or there'll be a collision".
Or perhaps you know further details of the effects...


No, I've never done it. It makes no sense whatsoever to try it.

Either give the MDW a different name or put it in a different
folder.

I vote for changing the name, since users basically never know
anything about it. My policy on this is if the app is called
XYZ.mdb, then the MDW is XYZUsers.mdw.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.