Hi All,

Can you use SageKey to track changes to tables, new tables added, etc. and have it make those changes to a client’s backend by running an update script?

Cheers,
Barry

SageKey is an set of install scripts and installing programs.

In the case of Access, you could simply copy a new front end off of your
jump drive manually and you get the same result - your program is placed on
the target machine.

So to update a Access application, it is a simple "ACT" of copy in regards
to the code.

Changing database structures is a different issue. No doubt often during a
upgrade one might want to "modify" database structures, but as such this is
not something that installers do today, or have done for the last 30+ years
in our industry.

So the "act" of using an installer has very little to do with making changes
to a database.

So no, I don't believe any installer in the marketplace to my knowledge has
some "ability" to track changes to a database structure during the
development process.

It is in fact not really known what database you going to use with a
developer tool like Access. The database might be JET, ACE, MySQL, Oracle,
SQL server etc.

So the "act" of installing your software and the use of a installer has
little if anything to do with something that will modify and maintain
database structures.

Usually the approach for updating structures is that during the development
process you do one of the following:

a) Make changes to the data structures, and then "save" the changes as DDL
(sql) scripts. The management tools for SQL server are nice in that RIGHT
AFTER I make a change to a table (using a GUI that very much like the one in
Access), then I right click and choose "script changes to clipboard". I then
paste that change into a "version.sql" document. So this document is then
"run" during the upgrade process.

b) Always use some scripting system in the first place to MAKE the changes
to data structures and then save that scripting. Since Access when using the
native data engine does not have option "a)" above, then this approach is
quite much what I use. In other words, any structure change is added to a
"upgrade" routine for this version. Usually this is DDL scripts, but it
often can be DAO code. In fact I have a "table" driven system that lets me
add the easy things like new columns, new indexes etc. so I don't have to
write code each time. This "table" becomes part of a version update in the
front end, and this table thus is processed by my routines to update the
back end.

So there are more ways of updating the database structures then there are
flavors of ice cream in the world - what works for me may well not work for
you, but if you talking about a split application (a near must if you going
to issue upgrades), then you have to adopt some kind of approach to tracking
changes made to tables during the development process, and then "run" +
"deploy" those changes to the back end file.

--

Albert D. Kallal
Edmonton, Alberta Canada
PleaseNoSpam_kallal (AT) msn (DOT) com

Barry Edmund Wright wrote:
I cannot vouch for this as i have never used it but it seems to do what you
want.

http://www.ssw.com.au/ssw/DataPRO/

David

Thanks Albert, guys like you are amazing and you are are Canadian like me, eh! Obviously, you have developed methods to meet your needs and know much more that I do about what's under the MS Access hood.

I am going to look at Peter's Backend Updater - I expect it has the DAO code that you referred to.
http://www.peterssoftware.com/beu.htm

Thanks again for your reply, I have a lot of respect for you and your willingness to share your knowledge.

Cheers,
Barry


On Sunday, July 15, 2012 7:21:31 PM UTC-4, Albert D. Kallal wrote: