how to deploy and manage ms access as client-server in window application

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 f开发者_如何学Goor concurrency? There will be insert, update and delete operation.

Thank you.

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.

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.