Working with a Split Database

[R Marko]

I have split our database with a font end and back end. The back end
contains all of the tables and resides on the file server. Each user has a
copy (not a shortcut) of the front end which contains all of the forms,
queries and reports. Now I have a few questions:

1. I update this database regularly. Each time, I must email everyone to
make a new copy of their computer. Is there an easier way? Should everyone
work on a shortcut instead?

2. I backup the database regularly to my own computer. Is there a way for
me to rejoin the fron and back ends into a single database. I opened the
back end and imported all of the forms, queries reports and macros into my
back end and it now has "quirks." Is there another way for me to do this?

Thank you,
Rhonda Marko

 

[Rick Brandt]

I have split our database with a font end and back end. The back end
contains all of the tables and resides on the file server. Each user
has a copy (not a shortcut) of the front end which contains all of
the forms, queries and reports. Now I have a few questions:

1. I update this database regularly. Each time, I must email
everyone to make a new copy of their computer. Is there an easier
way? Should everyone work on a shortcut instead?

Yes, there are easier ways and NO they should not be using a shortcut to a
common front end.
One way is to use the free utility created by Tony Toews which will
automatically update a user's copy of the front end if you have changed it.

2. I backup the database regularly to my own computer. Is there a
way for me to rejoin the fron and back ends into a single database.
I opened the back end and imported all of the forms, queries reports
and macros into my back end and it now has "quirks." Is there
another way for me to do this?

Why would you need to recombine them to make a backup? What you did should
work or you can go the other way and take a front end, delete all the links
and then import all the tables.

 

[R Marko]

I want to reconnect the back and front ends because I'm going to use the
database, minus the information, for other purposes..where there is only one
user.

Thanks for the information about the free software. Is this something
MicroSoft is working on for future updates?

R Marko

 

[Douglas J. Steele]

I wouldn't expect Microsoft to be building such a solution into Access,
because it's not something everyone needs, and because it's so simple to
implement a solution (using Tony's program, or rolling your own)

BTW, in case you haven't found it yet, Tony's program is at
http://www.granite.ab.ca/access/autofe.htm

 

[R Marko]

Thank you

I wouldn't expect Microsoft to be building such a solution into Access,
because it's not something everyone needs, and because it's so simple to
implement a solution (using Tony's program, or rolling your own)

BTW, in case you haven't found it yet, Tony's program is at
http://www.granite.ab.ca/access/autofe.htm

 

[Chris Mills]

where there is only one user.
Humm...I've just written a standalone program for the secretary of a local
hobby club (How small is THAT!!!)

And it's separated into 2 mdb's, Frontend/Backend or Program/Data, both in the
same folder.

There is STILL at least one pressing reason to have 2 separate files.

I can modify the program and e-mail the latest "program" to them without
overwriting their data. If it was one file, they would have to Stop Work,
E-Mail me the mdb for mods, and wait for me to get it back to them.

Also, in case they were sensitive about the data, I only need "test data", not
their whole live stuff.

Chris

 

[R Marko]

How do you add a table (and relationship) to a split database. I couldn't
figure it out.
Rhonda

 

[Chris Mills]

I think relationships should be put in the backend database, since that's
where the data tables are. Someone might correct me on this.

I've just tested (again) that you can put relationships in the Frontend for
all I care, including between linked and unlinked(frontend) tables. Maybe
that's a more sensible place. I don't see that it matters where you place a
relationship (FE or BE), provided of course if it's always going to be run
from the FE.

(I have SOME tables in the front end. These are "configuration tables" such as
allowed status: Financial, Unfinancial for a club, things like that. But those
are to do with the program and allowed values, they aren't "customer data")

You add a table by adding a table, in this case to the Backend (by opening it)
plus a link in the Frontend to it (by opening that). Then put any
relationships where you like (none of them give errors I can see). I suspect I
may not have understood the question.

To me, it makes hardly any difference (inconvenience-maintaining-wise) whether
a file is split into two or it's just one. Just choose whichever file the
object you want to modify is in! And if it's split into two, you can use the
same style for a single-user up to a mega-database! I mean, do you think I
wrote that app I mentioned from scratch? No I didn't, I borrowed one of my
other commercial apps and "just modified it". All the logic (menus, split
database, security if used, print toolbars for runtime and things like that),
were ALREADY WRITTEN!

It is true that I live in fear of some customer moving from one
field-of-endeavor(ie business) to another and comes across one of my other
programs. THEY ALL LOOK AND BEHAVE THE SAME!!! (well, saves a lot of
programming doesn't it?)

HTH
Chris

 

[Rick Brandt]

How do you add a table (and relationship) to a split database. I
couldn't figure it out.
Rhonda

Open the back end file and make the changes there. Then link that table into
your front end.

 

[Douglas J. Steele]

I think relationships should be put in the backend database, since that's
where the data tables are. Someone might correct me on this.

They have to be in the backend: while you may be able to put them in the
frontend, they do nothing there.

 

[Chris Mills]

Sorry - you're quite right.
Chris

They have to be in the backend: while you may be able to put them in the
frontend, they do nothing there.

 

[R Marko]

Thank you. In my haste, I took the back end, imported all forms, reports,
etc , made my changes and split. Not the most efficient way, but it worked.

Thank you,
Rhonda