Separate databases for data and logic

[train2]

I'm setting up a database in a school and need to keep the data separately for different year groups. However, I'd like to keep the logic identical for all years. Is it possible (without too much programming and difficult stuff) to set up a switchboard-type-screen listing the year groups which, depending on the button clicked, links that database just to that year group data? In advance, thanks for your response. I'm loaded with books etc. but can't find the answer.

 

[Isadore]

train2: At first glance it would seem like you'd want to keep all the tables in the same database; for simplicity and practicality. Is there any reason that this would not work, i.e., just make "different year groups" into their own tables if separation is required? In this way you could offer the user a combo box with year and they could go from there without having to open yet another *.mdb file.

 

[KornGeek]

It is technically possible to do something along the lines of what you want. There is code widely available on how to relink your back-end tables at runtime (which assumes that you've split your database into front and back ends). You could then set up a form that causes the database to relink the backend to one of a group of back-ends, depending on the button clicked by the user. The front-end would remain constant, and the back-end would be relinked to grab the correct data.

That being said, I am inclined to agree with Isadore that it seems like it would be better to store all of the data in one file, and then use queries and filters to use only the data you need. This would probably be the easier solution to implement also.

Good luck to you.

 

[train2]

Thanks for replies.
To put all data together would make sense, but there are other reasons why we want to keep data separate. The data model would be a lot more difficult, as would the queries and there is little expertise in the school and I'm only there temporarily. It's one of those things that is rushed into production with no time to perfect it.
Judging by your responses, it seems there's no easy solution. I'll keep thinking!

 

[KornGeek]

An easy-to-implement (but not efficient) method would be to use a separate copy of the database for each year. The logic would be the same, because the front-ends would be copies of each other, and using separate copies of the back ends would keep the data separate.

Just another idea to consider.