This sounds quite workable.
If you are saying that each "island" is a separate little network of PC's,
then you got the right idea.
So, that one particular data file (back end) would be placed on their LOCAL
server, and then the front ends on each pc in the office.
It is important to realize that you can't reliability use ms-access on a wan
(wide area network), but on each local "lan" (local area network), you can
use ms-access.
You can read about a LAN vs a WAN here:
http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html
For software updates, I often used a web page, or simply emailed them the
new FE's as you need (sending it as zip file with the correct dir set is
nice. In fact, I often use a self extracting zip file).
District but I need the capabilty
to control changes necessary to the structure.
Now, that seems strange? You can go out and purchase a very complex
accounting package, and it has all kinds of features like making new
inventory and job costing systems. Once company cost things by hours,
another by weight, and another might do costing by hours and wage. Yet, VERY
large number of companies purchase a off the shelf accounting system, and
the data designs are NEVER CHANGED! So, it is not clear what you mean by
"structure", but if you designed your software correctly, you should not
need (very often) to change your data structures.
With a split system, it is most certainly easy to add new forms, and add new
reports, send out bug fixes to your software etc. In fact, this is likely
one of the BEST features of splitting. You can simply send out a new front
end, and the data they been using does NOT get touched at all. Further, with
a split system you can work on the next great form, report, or add new code
etc, but they can safely continue to use their existing front ends (by the
way, those front ends for those users should be mde files). However,
changing the back end data strictures will require you to have the file sent
back to you for changes, and then it would have to be re-place on the server
(file share). During this time, users would not be able to add new data.
(you can write some complex code to modify the data structures for you..but
this quite difficult). Of course, during development process, the back table
structures will change (unless you nave a perfect design from day one!!).
So, you kind of want the development process to be reasonably far into the
project so as when you do finally deploy your application, then changes to
the data STRUCTURES is kept to a very min. In fact, often I wait till I am
about halfway or more through the project BEFORE I split (the reason for
this is I am NOT yet deploying the applications, so the advantages of
splitting are not yet going to be realized, and further making changes to
the back end is a bit more work). There is thus no hard and fast rule as to
what point in the he development process you will split, but the answer is
actually "you kind of just know!!". Essentially, when the number of changes
to the back end data structures drops down to min, then that is likely when
you split.
