But does anyone have a good idea of how
to make changes to the back end of the database without making all users
exit
out of their front end copy?
Well, even before, when things where un-split, you could not modify the
application. (and, before you could not even work on a "copy" of the
forms+code part). So, you are a lot better off.
There is several approaches I use, and which one depends on the client, and
the particular situation.
The first case is that I ask everyone to exit the application (or, if off
site, have them email me the applications, and tell them not to work until I
return to them the new updated back end). However, this "time" lag is
usually quite small in most cases. The reason for this is the following:
When I work on a copy of the FE, I also of course grab a copy of the BE. If
I add a new field to a existing table, then I will open up a small text
document (or a word document), and make a note of this change
table : Contacts, add new field "CityLocation"
newtable: tblLocatons
(set relation from tblContacts to tblLocations)
So, as I update, and add new fields, or tables, I make a little list of
notes. Usually, that list is only going to be 3 or perhaps 5 changes. When I
am 100% happy with the new fields, ad changes, I THEN TELL the client the
update is ready, and I need a copy of their back end. They zip/email it to
me, and then I simply open up that "list" of changes, and work on the new
back end..
Hum...ok...oh yes, I added that new field...ok..done
Hum, a new table...ah, I just import that table from the development back
end ...ok done...
When I am all happy, I then ship back the new FE, and the new BE. The "down
time" is not going to be too large here, since I ONLY keep them shut down
for the time it takes me to "update" that back end, and that is typically
less then 15 minutes.
It is obvious by now that you should write, and implement some type of
re-link code that lets you "specify" the new location to link to, or at
least something that checks the link, and pops up the 'dialog' box to do
this. You can use the linked table manager, but from a customer service
point of view, you really should have something a bit better...
So, the above is a typical solution.
A 2nd approach is to development above way, but then write CODE to update
the changes you made. For new tables, in place of a whole whack of "ddl", I
simply include the new table in the front end, and have code to "transfer"
this table to the back end, and am done (the link is already there!!!). For
new fields, most of the time I can get away simply issuing some "alter
table" commands in sql, and I got new fields. So, you can use some code to
"update" the back end, but that code can be quite delicate to write. If you
got 5+ clients in another city in different locations running the software
and they are going to get the update, then this is the approach I use. (I
don't want to call up, and deal with 5+ clients etc...). Note that in this
case, all users have to exit anyway, and the "first" user to run will run
this "update" code. (oh, yea...in that on reocrd "config" table in the
FE...I also got a version number, and also a table in the BE has that
number).
One question/comment about FE changes-I
assume that once I do an update on the FE, I could very simply email the
new
FE to all users (with correct UNC links) and instruct them to save and
overwrite the old version.
Yes, but do note that you can't set the UNC links unless you got the same
path names on your computer. I do often use virtual pc, and do make the same
path name (thus, you *can* send pre-linked talbes...and you should if you
can). I also got a conig table with one record in the FE, and in there I can
put in a path name to "link to " on startup (this only runs once, and then
another field is set to indicate this was done).
Further, in place of a whole bunch of instructions, why not use winzip
(
www.winzip.com), and create a self extracting .exe file that copies the
file to the correct place. And, if you don't have a copy registered copy of
winzip to make self extracting .exe, you can still make a zip file with the
trial edition. I used a registered copy of winzip for years to do this for
clients. And, I throw the copy up on a web site. (lots of email clients
don't allow .exe files anymore, and lots more don't even allow mdb
extensions).
Now, I have a much more polished approach, as I use the free "Inno"
installer, and that does a zip + allows things like shortcuts etc. So, the
best approach is to adopt and start using inno installer, and then you don't
need to "send" clients some instructions that they can mess up, but simply a
file that does all the work...
At the end of the day, you are still miles ahead in terms of flexibility.
