Re: How to Distribute a New Version

From: PC Data*** (spam_at_nospam.spam)
Date: 03/02/04 

Date: Tue, 02 Mar 2004 15:07:02 GMT

Hi Shelly,

<<Yikes! I can't write the kind of code that you are talking about that will
go out and import data from the back-end.>>

It's not as daunting as it seems!

Look at the TransferDatabase method in the Help file.

It only takes one line of code for each table and each line of code is the same
except for the names of the tables.

Go for it and earn another merit award!

Steve

"S Jackson" <jackson_shelly@hotmail.com> wrote in message
news:ekDT7QGAEHA.624@TK2MSFTNGP11.phx.gbl...
> Yikes! I can't write the kind of code that you are talking about that will
> go out and import data from the back-end. I do not have the expertise or
> training, unfortunately. (Just an FYI: I do have the db split already and
> yes it will be easy for them to replace the FE file.) The agency stuck me
> with doing this project even though I am a legal assistant, not a database
> developer! I've been floundering around ever since.
>
> Looks like I am stuck spending hours on the phone doing it the hard way
> having users import tables, do append queries to add the data to the new
> tables and then deleting the old tables. This is the only way I can see how
> to do this (I'm ignorant!).
>
> S. Jackson
>
> "Rick Brandt" <rickbrandt2@hotmail.com> wrote in message
> news:c2235g$1n6lkv$1@ID-98015.news.uni-berlin.de...
> > "S. Jackson" <sljack63@cox.net> wrote in message
> > news:BN_0c.20471$1k.2601@okepread01...
> > > How do you developers distribute a new improved copy of a database that
> > has
> > > already gone out to the user?
> > >
> > > I have sent out individual copies of my database across the agency for
> > users
> > > to tryout before we centralize it and begin networking it (this will be
> > much
> > > further down the road). Since then, I have made several design changes
> > to
> > > the tables and many changes to the FE and I want the users them out.
> > Most
> > > of the users are not trained and need a lot of hand-holding. Also, they
> > are
> > > spread out across the state so I do not have access to their pc's.
> > >
> > > Do I send complicated instructions for them to import all their old
> > tables
> > > into the new db, and run append queries?
> >
> > What I do...
> >
> > Split application so that changes to the front end are simply a matter of
> > replacing the file. Front end has a "first time run" routine that
> > establishes the links to the back end file automatically when first run.
> >
> > If the new revision also involves changes to the back end file (tables),
> > then I will do one of two things depending on which is deemed less work or
> > more reliable for the circumstances.
> >
> > 1)
> > My "first time run" code described above will apply all of the changes to
> > the back end file. This might be the creation of new tables, or the
> > modification of an existing table by adding/changing a field.
> >
> > 2)
> > When the back end changes are significant I might distribute a blank
> > template file for the new back end and have my "first time run" routine
> > link to the new file and then import all of the data from the old one.
> >
> >
> > --
> > I don't check the Email account attached
> > to this message. Send instead to...
> > RBrandt at Hunter dot com
> >
> >
>
>