Albert D. Kallal said:
So far what you describe is absolutely correct in seems 100% on the mark.
The databae split wizard does not create a mde for you. In fact it would
be a bad idea if it did this, since then you would not be able to make
modifications to your new front end now. Remember a mde is what you
distribute to your end users, but you can't makes changes to that mde.
This would mean that you have to go back to your original mdb, but it is
not split now. If you were to split the orginal mdb again, it would create
both the new front end, and a backend, which presumably could accidentally
overwrite the old one.
So from this point onwards, you'll be developing in a split environment.
on this point onwards any new modifications you make your application who
will be done to this new front and that was just created.
The idea here is now you can freely distribute this new front end to all
of your users computers and the office, place the backend data on your
stable server machine, or least on a shared folder on one of your
computer's.
At this point in time you can take a copy of this front end, and a copy of
the backend home, and begin to work on the next great version of the
software (and the beauty of this, is you can even do this off site, or
away from your work location).
As a general rule though, you should distribute a mde front end to each pc
in the office. This is not a requirement, or something that you must do,
it's just a good suggestion because your end users cannot play around
with, modify, or change the design that you've delivered to them when you
use a mde. If you give them a mdb, then they can modify it.
So the wizard does not produce a mde, because that new front is the front
end that you be making modifications to from now on. Hence, you still need
to have the ability to change and make modifications to this front end (if
it was a mde, you would not be able to change the desing).
Keep in mind that after you split, it's extremely easy to make
modifications, change the code, and build new report's and modify forms,
and fix bugs in your application even if you're off site. In other words
all the users in your office can continue to work with their version at
work, and you are happily developing the next great release of your
software at home.
However, the one area that poses difficulties and challenges is modifying
the table structures. Note that any time you add a new field, or modified
table structures, you'll now do this from the database back end, NOT the
front end. What this means is that in a production environment, you can
not really modify the backend database when uses are working.
Furthermore, if you're working off site (at home), and you add a few new
fields to a table, or modify a table, you better take out your notebook
and make some notes as to exactly what you did. When you get back to work,
and you plan to deploy you next great version of your software, you'll
have to schedule some down time for your application, make sure no users
are working, and then open up the back end and make the SAME modifications
that make to your copy of the back end while away.
While a split database makes fixing and modifying the front and a snap
(and it facilitates the ability for you to write and modify code off
site), modifying the backend database structure presents the same
challenges it did before, and you can't do it while users are running the
application.
What I usually do is simply make a little text file that I make detailed
notes about the changes I've made. When I get back to the client site,
just before I deploy the new front end I've been working on for a long
time, I will open up their backend and add the new fields and make the
same table structures changes that I did while offsite.
Another more advanced technique is to actually write code to modify the
tables (add fields etc). This approach allows to deploy new updates to
clients that you've never seen before, or can not even be on their actual
work site when you give them the update (via email, or a web download for
example).
