Re: Distribution of a split db as a runtime
- From: "Dave" <noone@xxxxxxxxxxx>
- Date: Fri, 27 May 2005 16:28:33 -0000
"Kevin Hughes" <spamsuxthe@xxxxxxxxxx> wrote in message
news:FN6cnaRRr4Gu2ArfUSdV9g@xxxxxxxxxx
> The topic covers it pretty well. I have a database that I plan to
distribute
> as a runtime. Splitting it allows for code module upgrades while keeping
the
> tables and data from the old version intact. Table designs are ~real~
mature
> (app has been out in my field as a .mdb for years), no worries about
> structures needing to be changed.
>
> Can someone provide either a link to the step-by-step for making a split
> runtime, or post it here?? While I wrote every line in the DB, this is
> uncharted territory for me, and MS' help files in this area ... are as
good
> as most MS help files ;)
ah yes, split and run... great fun, but there are some gotcha's in it.
first, and always, save a copy of the unchanged one!
1. split it, this is easy and works fine.
2. make installation package with the packaging wizard, select the front end
file as the target. it should find the backend automatically but if not add
it manually as a file.
3. voila! all is well in the world. or so you would think...
gotcha 1... sometimes you want to redistribute some data when you change the
code... or you need to distribute certain parts of the data that you control
separate from the parts the user enters. after you do the split you may
want to move certain tables back into the front end so that you can prevent
users from changing them or so you can easily replace them by just sending a
new front end file.
gotcha 2... updates are strange. i have asked a couple times about this and
haven't gotten an answer yet. the first installation goes fine, but then
when installing a new front end over the old one the installer pops up that
message box saying the existing one is newer than the new one you are
installing and the user has to allow the new one to replace the old one.
there must be somewhere that you can set revisions that the installer knows
how to read so that it knows which one is really the old one, but i haven't
found it yet.
gotcha 3... if the user doesn't install it to the same drive/folder that you
did the split in the linked tables won't be found. very ugly. if this
happens you have to figure a way for either your startup code to find the
back end or for the user to find it for you. then use code like this to
relink the backend tables:
Dim Dbs As Database
Dim Tdf As TableDef
Dim Tdfs As TableDefs
Set Dbs = CurrentDb
Set Tdfs = Dbs.TableDefs
For Each Tdf In Tdfs
If Tdf.SourceTableName <> "" Then
Tdf.Connect = ";DATABASE=" & mdbfilename
Tdf.RefreshLink
End If
Next
where mdbfilename is the backend file name. note that this must be done
before opening a form that uses data from the backend!
think ahead 1... maybe your app is nice and mature, but i found it useful to
embed a revision number in a table in the backend. this way when you start
up you can query the table and find out if the table is the latest version.
if it isn't then you can do things like changing table structures, updating
data, any other type of maintenance that might be needed to bring a user's
old data up to current needs of your app. after fixing the backend you then
update the rev in the table so you don't try to do it again.
think ahead 2... splitting the database makes it possible to use multiple
backends with the same front end... by providing the user with a way to
select the backend they want to use they can have separate databases for
each of their possible uses. maybe this won't apply in your case, but it
can be very handy. use the same code as above to relink to a different
backend.
have fun in the wild world of split databases!
.
- Follow-Ups:
- Re: Distribution of a split db as a runtime
- From: Kevin Hughes
- Re: Distribution of a split db as a runtime
- References:
- Distribution of a split db as a runtime
- From: Kevin Hughes
- Distribution of a split db as a runtime
- Prev by Date: Distribution of a split db as a runtime
- Next by Date: Re: Duplicating information
- Previous by thread: Distribution of a split db as a runtime
- Next by thread: Re: Distribution of a split db as a runtime
- Index(es):
Relevant Pages
|
