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 SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

DataBase Design Philosophy.... I

Status
Not open for further replies.

armstrong722

Technical User
Feb 26, 2002
32
0
0
US
DataBase Design Philosophy....

I seemed to have read somewhere in here that its better to somehow divide your database into two separted files.

One Just the tables and (queries?) and the other all the forms and reports modules etc.

I'm not sure about anything I just wrote but..

If anyones knows where there might be a good white paper on design philosophy I sure would appreciate the link.
 
IN access, what you are talking about is the database splitter. It divides the db into 2 parts:The Tables, and then the forms querys etc.

To get to the wizard, it Tools/Database utilities/Database Splitter. The splitter option may be hidden and you'll have to hit the double arrows at the bottom of the dropdown.

This will let you put the tables up on the network and then put a copy of the Forms/Queries on each workstation. My method is to put the DB(whole) where you will be keeping the table parts(on the network) then split the db. The Forms component will be pointing to the correct tables when you copy it down to a workstation. If you have to change the location of the tables, use the table linker utility, under DB Utils as well. Hopefully that makes some sense Sam Greene
anyone in need of a rock induced headache? if so
 
I don't have any links for you, but I'm sure you'll get some good ones from this forum.

However, I can answer the question about splitting databases. I usually split my tables into a backend database and leave all the forms/queries/etc in a frontend database just because it's easier to make mods and to prevent losing data in the event of a crash/delete/catastrophe.

When you have to change a form (and you will) it's easier to just go into the front end DB and replace the form without having to worry about porting data into a new db. Also if someone bad happens to the frontend you can easily replace it from your backup copy without worrying about lost data. (And the reverse, if something happens to the data <cringe> at least you still have the db design intact)



Maq B-)
<insert witty signature here>
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top