Re: Distribution of a split db as a runtime
- From: "Dave" <noone@xxxxxxxxxxx>
- Date: Sat, 28 May 2005 14:28:25 -0000
i know you can make the backend into an mde, not sure about the frontend off
hand. but again of course make sure you keep a normal copy before you try
making an mde out of it!
"Kevin Hughes" <spamsuxthe@xxxxxxxxxx> wrote in message
news:C-OdnRw_9ebG6gXfUSdV9g@xxxxxxxxxx
> Thanks Much, that covers 99% of the things I wasn't sure about.
>
> One follow-up though. Previously, one could secure code from prying eyes
by
> making the project into an MDE. Does a similar protection exist for
runtime
> code ... as anyone with a full version could then go poking around??
>
> Thanks again:
>
> Kevin
> "Dave" <noone@xxxxxxxxxxx> wrote in message
> news:uGOAlktYFHA.4024@xxxxxxxxxxxxxxxxxxxxxxx
> >
> > "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: Douglas J. Steele
- Re: Distribution of a split db as a runtime
- References:
- Distribution of a split db as a runtime
- From: Kevin Hughes
- Re: Distribution of a split db as a runtime
- From: Dave
- Re: Distribution of a split db as a runtime
- From: Kevin Hughes
- Distribution of a split db as a runtime
- Prev by Date: Re: Distribution of a split db as a runtime
- Next by Date: Re: Distribution of a split db as a runtime
- Previous by thread: Re: Distribution of a split db as a runtime
- Next by thread: Re: Distribution of a split db as a runtime
- Index(es):
Relevant Pages
|
