I built a database, (with the help of many of you)in Access 2000 and now I want to share it out to about 5 to 10 user and let them play around in it, then they'll send me feed back. What is the best way to share the database I'm not ready to split it yet??
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Best way to Share a Access Database while still in Development 1
- Thread starter BubbaJean
- Start date
CajunCenturion
Programmer
I would reconsider whether or not you're ready to split it.
In my current situation, I have continuing the development of an application, which is also in production.
I have split it into three sections, the front end, and two backends, where one backend contains the live data files, and a second which contains system tables, where system tables are those tables needed by the application (ie meta data and system level data), but not ones which would be updated in normal production. The users, at least for now, are using a single shared front end, which is linked to the two backends. I have a local copy of the front end, also split, but I also have local copies of both backends. This allows me to develop locally with test data, and provides me the ability to create and modify the system tables locally as necessary. When the time is right, which right now is about twice a week as we are heavily into development of new functionality, I update the shared front end and system backend as necessary, reset the links, and proceeed. I can also, if necessary, relink my local front end to the production file for testing if something seems awry with the live data.
Once things stabilize and updates can be scheduled, then the shared front end will become local to each users, but both backends will of course remain shared. That will require more effort for front end updates, but that process is also being automated.
I'm also curious to know what techniques others are using as well. It is an ongoing problem dealing with production systems and continuing development.
Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein
In my current situation, I have continuing the development of an application, which is also in production.
I have split it into three sections, the front end, and two backends, where one backend contains the live data files, and a second which contains system tables, where system tables are those tables needed by the application (ie meta data and system level data), but not ones which would be updated in normal production. The users, at least for now, are using a single shared front end, which is linked to the two backends. I have a local copy of the front end, also split, but I also have local copies of both backends. This allows me to develop locally with test data, and provides me the ability to create and modify the system tables locally as necessary. When the time is right, which right now is about twice a week as we are heavily into development of new functionality, I update the shared front end and system backend as necessary, reset the links, and proceeed. I can also, if necessary, relink my local front end to the production file for testing if something seems awry with the live data.
Once things stabilize and updates can be scheduled, then the shared front end will become local to each users, but both backends will of course remain shared. That will require more effort for front end updates, but that process is also being automated.
I'm also curious to know what techniques others are using as well. It is an ongoing problem dealing with production systems and continuing development.
Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein
-
1
- #3
This is how I did it!
split your DB in Front End and Back End.
Make sure your back end's architecture is complete. Your tables are properly designed, and you do not need to modify their design.
Install the front end on all your users computers to a set location. For support purposes you may map all locations of your users FE location as separate drive letters on your machine so that you can easily access the locations and do your FE updates whenever necessary.
Keep developing the front end on your machine, and when necessary update your users with it by simple copy operation. Before copy make sure the front ends are closed at locations you are copying to.
Always do a historical back up of your FE. make sure to back up the last working releases everytime major revisions are posted.
For BE changes all FE must be closed. Instead of that you may want to work with a test BE. I don't. I rarely have to play around with my BE architecture.
'Hope this helps
Good luck,
Kuzz
"Time spent debating the impossible subtracts from the time during which you
can try to accomplish it."
split your DB in Front End and Back End.
Make sure your back end's architecture is complete. Your tables are properly designed, and you do not need to modify their design.
Install the front end on all your users computers to a set location. For support purposes you may map all locations of your users FE location as separate drive letters on your machine so that you can easily access the locations and do your FE updates whenever necessary.
Keep developing the front end on your machine, and when necessary update your users with it by simple copy operation. Before copy make sure the front ends are closed at locations you are copying to.
Always do a historical back up of your FE. make sure to back up the last working releases everytime major revisions are posted.
For BE changes all FE must be closed. Instead of that you may want to work with a test BE. I don't. I rarely have to play around with my BE architecture.
'Hope this helps
Good luck,
Kuzz
"Time spent debating the impossible subtracts from the time during which you
can try to accomplish it."
Do any of you know of a good way to update a frontend that is on the local machines remotely if the database is secured with an mdw file. I have found a few modules that work on unsecured databases, but nothing that seems to work other wise?
Thanks,
Shadd Parker
Thanks,
Shadd Parker
if you change the MDW just sets your users and group. The permissions to open certain forms, tables, etc. are embedded in your FE. You only need to one time set your users and groups, place the .mdw file in the right locations on the remote machines and just update your FE everynow and then with proper permissions, as per thread above.
Before publishing live data make sure to lock your BE tables accordingly.
Before setting security BACKUP YOUR FE AND BE. I locked myself out of my own DB FE once. It was not a pretty sight. I had to rebuild it all from scratch. Luckily my BE data was accessible.
Good luck,
Kuzz
"Time spent debating the impossible subtracts from the time during which you
can try to accomplish it."
Before publishing live data make sure to lock your BE tables accordingly.
Before setting security BACKUP YOUR FE AND BE. I locked myself out of my own DB FE once. It was not a pretty sight. I had to rebuild it all from scratch. Luckily my BE data was accessible.
Good luck,
Kuzz
"Time spent debating the impossible subtracts from the time during which you
can try to accomplish it."
- Status
Similar threads
- Locked
- Question