ok men. here are a few rookie questions for you personally:
I produced a database for monitoring metrics, with a few automation methods (email, .doc,.ppt presentations, etc) having a large Primary-table, and a lot of forms/GUI. This is actually the very first time I've ever I concerned about an MDE/front-finish for the one thing. If you could be so kind to reply to a couple of questions, or offer any advice, it might be greatly appreciated (I'd hate for those the work not to be applied).
What's the first factor I have to do? It the 2000 version that must definitely be transformed into 03 to produce the MDE, but does that will get done before I personally use the database splitter?
Will the quantity of objects within the database effect a chance to do that? I've something similar to 80 forms, 70 queries, 20+ macros, 12 tables, etc...but does the quantity of objects prevent a number of this from working well when the front-end can there be?
after i split the database, can one still work/make changes and the like around the "back finish", and also have individuals changes directly effect the front-end?
These might be some fundamental questions, but I'm not sure the solution so.....Thanks!
Here's my 2 ¢.
Question 1 - I have not used the database splitter when i feel I've with additional control doing the work by hand. Should you choose it by hand it can be done to some version without a database splitter. But when you need to do make use of the splitter then--yes--you'll have to upgrade to some version which has a splitter before doing the work.
To get it done by hand listed here are the steps.
- Backup everything.
- Produce a copy of the file in to the same directory. If you come with an MyApp.MDB produce a copy in to the same directory with a brand new title, for example MyAppDATA.mdb.
- Open the brand new Computer file (MyAppDATA.mdb) and remove all the objects EXCEPT the TABLES.
- Open the Application file (MyApp.mdb) and remove all the tables.
- Also in MyApp.mdb...visit the File/Get Exterior Data/Link Tables menu to link the tables in MyAppDATA.mdb to MyApp.mdb. Choose All and make the hyperlinks.
Which should get it done. And when you ruin you've made a backup...right?
A few tips and gotchas...ensure that you visit Tools/Options which you aren't showing System and Hidden tables. You simply don't wish to remove system tables from MyApp. A different way to get it done is don't remove tables that begin with MSys or USys.
Question 2 - Is not important the number of object you've. Actually you do not have that lots of objects anyway.
Question 3 - Yes...you'll make after sales alterations in MyAppData.mdb so when you open MyApp.mdb individuals changes will auto-like magic be there to determine and query against etc. (Within the query designer you may want to save/close/reopen to determine new fields should you made the mod whilst in the query). The EXCEPTION to that's New Tables You'll have to make use of the File/Get Exterior Data/Link Tables choice to create links to new tables.
One factor to keep in mind (which I think you'll already realize) would be that the one problem with splitting the database is the fact that whenever you deploy the front-end file that always the relative road to the information will be different from machine to machine and there's no automatic re-connecting of tables in access. In case your target clients have full access you could use Tools/Database Utilities/Linked Table Manager to refresh the hyperlinks right location. If you cannot do this then you'll have to do among the following:
1. Write code that does the automated re-connecting for you personally. Essentially it'll look into the links...if invalid it'll prompt the consumer for that data location (or look up within an INI file) and re-link the tables.
2. Always deploy your application to same position on all machines. For those who have commercial visions for the application this will not work...I bring it up for academic reasons. It may be possible for any limited deployment where you've got a large amount of treatments for file positioning on each machine.
3. Place the Computer file (MyAppDATA.mdb) onto a network share and link the table over the network utilizing a drive mapping or UNC (myservermydataApplicationDataMyAppData.mdb). The second is preferred but each of them run exactly the same risks as # 2.
PS This answer assumes Access 2003.
PPS For those who have commercial visions for the application then your table connecting has to be REALLY robust. PPPS To be sure using the commenter that you might want to make the leap and do SQL if it's inside your expertise.