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

Will Jet work for this?

P: n/a
Hi folks,

I have a task to write an application that requires a database backend. At
most I will have 5 or so concurrent users, and perhaps 30 users total. I
need to store the database file(s) at a UNC location on the network that's
backed up regularly, but I can't rely on IT to maintain a database service
there. Is it possible to use the Jet driver (the app will be written in
MFC) from different client machines to simultaneously access this single
database file? Or perhaps I should look at a different database? SQLite?

I'm not yet knowledgeable with databases so I'm looking at this problem from
different angles with the help of some you very smart folks. My apologies
if this is the wrong newsgroup.

Thanks much,
JJ
Mar 17 '08 #1
Share this Question
Share on Google+
7 Replies


P: n/a
"Maleus the Mighty" <ma****@olympus.netwrote
Is it possible to use the Jet driver (the app will
be written in MFC) from different client machines
to simultaneously access this single database file?
Jet is a "file-server" database and always works exactly the way you want...
the database engine and Access (or runtime) are on the user's machine and
use the "backend" file on the shared disk just as though it were on the
local hard drive. Neither Jet nor Access need be installed on the machine
where the shared back-end resides. Each of the users, however, must have
full permissions on the disk or folder where the data resides -- including
create and delete file, update, read, write, and delete records. And the
back-end database is limited to 2GB total size.

* back-end = an .MDB shared tables with data, and relationships
Or perhaps I should look at a different database? SQLite?
If by SQLite, you mean the Express version of Microsoft SQL Server, no,
because all versions of Microsoft SQL Server (including the MSDE version
that shipped with Access in the past) are server databases... that is, the
database engine runs on the server where the data resides. If "SQLite" is a
third-party product, I couldn't answer, because I'm unfamiliar with it; but
I'd say the question is moot because Jet does exactly what you want.

Larry Linson
Microsoft Office Access MVP
Mar 17 '08 #2

P: n/a
"Larry Linson" <bo*****@localhost.notwrote in message
news:OsyDj.2702$bN3.1486@trnddc03...
"Maleus the Mighty" <ma****@olympus.netwrote
Is it possible to use the Jet driver (the app will
be written in MFC) from different client machines
to simultaneously access this single database file?

Jet is a "file-server" database and always works exactly the way you
want... the database engine and Access (or runtime) are on the user's
machine and use the "backend" file on the shared disk just as though it
were on the local hard drive. Neither Jet nor Access need be installed on
the machine where the shared back-end resides. Each of the users,
however, must have full permissions on the disk or folder where the data
resides -- including create and delete file, update, read, write, and
delete records. And the back-end database is limited to 2GB total size.

* back-end = an .MDB shared tables with data, and relationships

... Larry Linson
Microsoft Office Access MVP
Thank you! I had hoped this would be an acceptible approach given the nice
MFC wrappers and redistributable nature of Jet.

Would the MDB file simply be locked during access, or is a more
sophisticated integrity scheme possible? I have a low number of concurrent
users but I'd like consider network latency against the speed of particular
queries/writes/etc.

-JJ
Mar 17 '08 #3

P: n/a
When the first user's front end connects to the back end .mdb Access
creates a lock file with the name of the back end file and the
extension .ldb. That's where Access manages locks and whatnot for
subsequent users. That's why users need write privledges to the
directory holding the back end file.

I hope that's what you mean by "sophisticated integrity scheme." I've
had great sucess with dozens of simultanious user happily creating and
editing records.

Good luck!

Tim Mills-Groninger

...
Would the MDB file simply be locked during access, or is a more
sophisticated integrity scheme possible? *I have a low number of concurrent
users but I'd like consider network latency against the speed of particular
queries/writes/etc.
...
Mar 17 '08 #4

P: n/a
Exactly what I meant. Time to play with a prototype. Thanks much for the
help!

-JJ

------------------------------------

When the first user's front end connects to the back end .mdb Access
creates a lock file with the name of the back end file and the
extension .ldb. That's where Access manages locks and whatnot for
subsequent users. That's why users need write privledges to the
directory holding the back end file.

I hope that's what you mean by "sophisticated integrity scheme." I've
had great sucess with dozens of simultanious user happily creating and
editing records.

Good luck!

Tim Mills-Groninger

....
Would the MDB file simply be locked during access, or is a more
sophisticated integrity scheme possible? I have a low number of concurrent
users but I'd like consider network latency against the speed of
particular
queries/writes/etc.
....
Mar 17 '08 #5

P: n/a
"Maleus the Mighty" <ma****@olympus.netwrote in
news:Mu******************************@scnresearch. com:
Reasonable idea that I'd certainly pursue if not for a front-end
that requires interfacing certain bits of proprietary hardware.
No COM-based interfaces for those? If so, then an MDB will be just
fine.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 18 '08 #6

P: n/a
>Reasonable idea that I'd certainly pursue if not for a front-end
>that requires interfacing certain bits of proprietary hardware.

No COM-based interfaces for those? If so, then an MDB will be just
fine.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
COM or not, it wouldn't matter. Still going with MFC/C++ for the front-end.
But my prototyping indicates an MDB back-end will work just fine.

Thanks to all, this newsgroup has been especially helpful.

-JJ
Mar 18 '08 #7

P: n/a
"Maleus the Mighty" <ma****@olympus.netwrote:
>Reasonable idea that I'd certainly pursue if not for a front-end that
requires interfacing certain bits of proprietary hardware.
Does the hardware come with DLLs what you can use in VB? If so they should port over
to VBA quite nicely.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Mar 19 '08 #8

This discussion thread is closed

Replies have been disabled for this discussion.