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).
