Access Database Design
I am redesigning an Access database system and could use some advice.
Currently I have multiple self-contained databases being filled out by users at various locations. Monthly I import records from each database into a Master database. [I'm not able to setup and connect everyone to a shared MDB or SQL database.] This is working out fine.
However, each database has lookup tables that I wish to now update frequently and distribute to everyone. I was going to put all reference tables into a separate database, link these reference tables to the "input" database - so I could easily distribute a new reference database without having to go into each person's input database and change things.
My problem is that I can't set referential integrity to linked tables and I want to control what is entered into fields using these lookup tables.
Any suggestions?
- Methos
Currently I have multiple self-contained databases being filled out by users at various locations. Monthly I import records from each database into a Master database. [I'm not able to setup and connect everyone to a shared MDB or SQL database.] This is working out fine.
However, each database has lookup tables that I wish to now update frequently and distribute to everyone. I was going to put all reference tables into a separate database, link these reference tables to the "input" database - so I could easily distribute a new reference database without having to go into each person's input database and change things.
My problem is that I can't set referential integrity to linked tables and I want to control what is entered into fields using these lookup tables.
Any suggestions?
- Methos
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
<<My problem is that I can't set referential integrity to linked tables and I want to control what is entered into fields using these lookup tables.>>
It is true the data engine can't enforce referential integrity across databases. That does not mean that you can't write code that does. Before RDBMS's could enforce RI, I have to write code to do it. As JeffCoachman poited out there are times when you do not what the RDMS/database engine to enforce RI. I have apps where I enforce the RI with code not the RDMS/database engine.
When trying to keep remove sits in sync, you have to be very careful about deleting anything from your master tables. It is easy to add data to your master tables.
Back in the mod 90's I have a client with offices in many states. The remote office were set up to create an export databases that was then FTP'ed to the main office. The app also looked for updates on the FTP site. It would download the updater database and open it. It would auto run and update the master list tables. This allowed me to use a single back end oat each location. I also never delete records. Only mark then as inactive. To delete records from master list, you will first need to update all the existing data so it is not linked to the record that will be deleted. They still use this method toady.
My recommendation is to never delete records. Only mark then as inactive. You can easily filter out these records.
FWIW: I was fortunate to have learned never to delete records from the very start from some DBA masters. I have been doing it this with every application for 30+ years and it has served me well.
EDIT: Well ... I took to long to type my reply. Hope it helps anyway.
It is true the data engine can't enforce referential integrity across databases. That does not mean that you can't write code that does. Before RDBMS's could enforce RI, I have to write code to do it. As JeffCoachman poited out there are times when you do not what the RDMS/database engine to enforce RI. I have apps where I enforce the RI with code not the RDMS/database engine.
When trying to keep remove sits in sync, you have to be very careful about deleting anything from your master tables. It is easy to add data to your master tables.
Back in the mod 90's I have a client with offices in many states. The remote office were set up to create an export databases that was then FTP'ed to the main office. The app also looked for updates on the FTP site. It would download the updater database and open it. It would auto run and update the master list tables. This allowed me to use a single back end oat each location. I also never delete records. Only mark then as inactive. To delete records from master list, you will first need to update all the existing data so it is not linked to the record that will be deleted. They still use this method toady.
My recommendation is to never delete records. Only mark then as inactive. You can easily filter out these records.
FWIW: I was fortunate to have learned never to delete records from the very start from some DBA masters. I have been doing it this with every application for 30+ years and it has served me well.
EDIT: Well ... I took to long to type my reply. Hope it helps anyway.
ASKER
Both answers helped me equally... I split the points but can't pick both as "best solution".
Thanks -- I can move forward. I appreciate you quick answers back!