0

I don't have experience in using ms-access as client-server in window application. Let me get knowledge about some below -

  1. In server, do I just place this access db in a share folder? And in client, just point to this path? Could i get a sample path syntax?
  2. Four users will use this db. how should I do for concurrency? There will be insert, update and delete operation.

Thank you.

HansUp
  • 95,961
  • 11
  • 77
  • 135
soclose
  • 2,773
  • 12
  • 51
  • 60
  • 2
    Access is not a server. You should use SQL Server. – SLaks Jun 05 '11 at 12:25
  • UAT was done. :( How do I keep on? – soclose Jun 05 '11 at 12:35
  • Your last comment is unclear, can you elaborate? It sounds like you're saying that you need to continue to use Access because it was tested and accepted. However, if the system is scaling beyond the original specs then it will likely need a little re-engineering to meet the new specs properly. Some things will have to be re-tested. – David Jun 05 '11 at 12:43
  • Yes, David. I will do re-engineering. – soclose Jun 05 '11 at 12:51

2 Answers2

1

I'm concerned about the type of responses you're getting here. You can't reliably share any Access front end, whether it's split or not. To your questions:

In server, do I just place this access db in a share folder? And in client, just point to this path? Could i get a sample path syntax?

You first need to SPLIT your application into two files, one, the back end, with nothing but data tables, and the other with the front-end user interface objects (forms/reports/queries/etc.) and linked tables (instead of local tables). Only the back end file is placed on the server. Each individual user will get a copy of the front end.

The linked tables should be linked with UNC paths, i.e., \\Server\Databases\MyDataFile.mdb, instead of using mapped drives (which could be mapped differently on different workstations).

You might find a posting of mine about setting up a proper Access development environment useful. It also discusses deployment and splitting the app. For more information on that you might find Tony Toews set of articles on the subject helpful.

By the way, the split architecture has always been the only viable deployment approach for Access apps. I have always wondered why MS doesn't do a better job in its documentations of explaining this.

Four users will use this db. how should I do for concurrency? There will be insert, update and delete operation

Four users should be trivial, but it entirely depends on the nature of the kind of data you have and how the users are editing it. If a single record needs to be edited by multiple users, then you could easily have edit collisions. On the other hand, if users are usually inserting and editing their own records and not really overlapping with the other users, there should be little or no concurrency problems at all.

For some detailed consideration of record locking issues, see a post of mine from a long time ago that considers the subject of setting up an Access database for multi-user access.

Community
  • 1
  • 1
David-W-Fenton
  • 22,871
  • 4
  • 45
  • 58
0
  1. Yes, the database would probably just sit on a file share. Something like: \SERVERNAME\ShareName\filename.mdb
  2. Depends on the usage, I guess. The database engine should handle basic concurrency just fine like any other database. If the usage is going to continue to scale then I highly recommend moving to a more manageable database system.

With multiple users hitting it across the network you (and your application) need to start considering things like how to handle network outages (client is up, server is down), connectivity problems (one user can hit the database, another can't), database backups (what's your current backup and restore strategy?), etc.

David
  • 208,112
  • 36
  • 198
  • 279
  • 1) for backup and restore, currently I don't have any strategy. Just manually backup. Let me know any suitable strategy. – soclose Jun 05 '11 at 12:54
  • @soclose: A suitable strategy would be to move to a more manageable database system, such as SQL Server. Manual steps genrally don't scale well, and they tend to place a heavy dependency on a single person, who may or may not always be there. If multiple people are accessing the database, simply copying and replacing the file is asking for trouble. – David Jun 05 '11 at 12:59
  • Thank you very much, David. 2) actually their usage is not much. However, I'd like to prepare it for multiple users. Let me get any idea. Is there any lock feature in ms access? – soclose Jun 05 '11 at 13:03
  • Four users should be well within the capabilities of Jet/ACE. Anybody who can't design a performant Access database application for that user population is doing EVERYTHING wrong. – David-W-Fenton Jun 12 '11 at 21:32