DB Instance Content Versioning System

Hello all, I am not sure if this is the correct medium of communication the following issue we (my place of work) have. We need to establish a system whereby we can identify the state of the DB (data,SPLs,etc). For example, if we are releasing a new sub-system, that includes DB components, we would like a method to identify that these DB components were released in this particular DB instance. Has anyone worked with such as system? Can you please elaborate on its inner-workings? TIA, George

AGS's Server Studio with Sentinel can snapshot your database schema periodically and compare one snapshot to another. Even if you do not purchase the Sentinel component Server Studio will let you do comparisons between the schema on two servers for differences and even generate a sync script, you just have to perform the operations manually. In the IIUG Software Repository, you will find several packages that can similarly compare schema between servers or compare one schema file to another. One is my utils2_ak package which contains a script, mydbdiff, which can do these comparisons (server -vs- server, server -vs- saved file, file -vs- file) using my dbschema replacement utility myschema which is also included in that package. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Thu, Dec 15, 2011 at 4:23 PM, George Karabotsos <karabot@gmail.com>wrote: > Hello all, > > I am not sure if this is the correct medium of communication the > following issue we (my place of work) have. > > We need to establish a system whereby we can identify the state of the > DB (data,SPLs,etc). For example, if we are releasing a new > sub-system, that includes DB components, we would like a method to > identify that these DB components were released in this particular DB > instance. > > Has anyone worked with such as system? Can you please elaborate on > its inner-workings? > > TIA, > George > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --e89a8f3ba6db95733d04b4293613

We have a dbversion table which we update with major and minor release = numbers. Based on those values we know what upgrade paths need to be = taken - and which have already been taken. We officially support = upgrades from two previous versions, although in fact that is a minimum = number and our last release would upgrade from 4 previous versions. We make a point of not making changes to schema or SPLs except at major = releases. Patches are used for minor fixes as needed. j. On Dec 15, 2011, at 4:23 PM, George Karabotsos wrote: > Hello all,=20 >=20 > I am not sure if this is the correct medium of communication the=20 > following issue we (my place of work) have.=20 >=20 > We need to establish a system whereby we can identify the state of the=20= > DB (data,SPLs,etc). For example, if we are releasing a new=20 > sub-system, that includes DB components, we would like a method to=20 > identify that these DB components were released in this particular DB=20= > instance.=20 >=20 > Has anyone worked with such as system? Can you please elaborate on=20 > its inner-workings?=20 >=20 > TIA,=20 > George=20 >=20 >=20 > = **************************************************************************= *****=20 > Forum Note: Use "Reply" to post a response in the discussion forum.=20= >=20