Reputation: 17
So here is the gig, I have this inventory access database that I am trying to seperate the form logic from the database itself; having the database on the server while the form is distributed to users.
I know how to seperate the database to a "front end" and a "back end" but my question becomes " is that all I need to do? Send the users the front end with the form and call it done?"
How do I ensure the database can still talk to all instances of the form?
Help, or at least a point in the right direction, would be great! Been trying to figure this out for the past week.
Upvotes: 0
Views: 2433
Reputation: 23067
Based on your question "How do I ensure the database can still talk to all instances of the form?" it seems to me that you fundamentally don't understand how Access/Jet/ACE works.
The database (back end) doesn't do any "talking" -- it's just a file. Each user's PC does all the data manipulation, and as long as the linked tables in each user's front end has the right connect string, it will load the data from the shared file on the file server.
It's all "pull" -- no "push" as there's no server process running on the server to send anything back to the users.
Upvotes: 1
Reputation: 7882
See the "Splitting your app into a front end and back end Tips" page for more info. See the free, for basic use, Auto FE Updater utility to make the distribution of new FEs relatively painless
Upvotes: 1
Reputation: 91376
That is basically it. You will probably need some code to check the linked back-end tables and re-link them if any are missing. I like to keep a small set-up table that lists the expected tables and location and a start-up form. The start-up form checks a few things and either loads the menu form, if all is well, or a form to find the back-end database is all is not well.
Upvotes: 0