Yeah, we decided that upgrading our database needs to be a linear operation for now. If you want to support patching, you also would need a way to keep track of which patches are present in the database and condition future components very carefully. We could also just make sure that the patch bumps the version number in our database and only allow patches to be allowed sequentially or have them be roll-up patches which include all previous updates, too.
Dana On Thu, Sep 25, 2008 at 10:41 AM, Michael Osmond <[EMAIL PROTECTED]>wrote: > Dana, > > Are you always using a Major Upgrade? > > Michael > > ________________________________ > > From: Dana Gutride [mailto:[EMAIL PROTECTED] > Sent: Fri 26/09/2008 12:12 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] SQL scripts and Upgrades > > > > We just use a simple version number stored in a table in the db. We read > it > on upgrade using a custom action scheduled before CostInitialize and then > only components which are greater than that version number are installed > based on a component condition like what's below. > > <Condition><![CDATA[DATABASEOPTIONS="upgrade"]]> AND > <![CDATA[DB_VERSION<3]]></Condition> > --3 is the version this particular component upgrades to > > Dana > > On Thu, Sep 25, 2008 at 2:51 AM, Michael Osmond <[EMAIL PROTECTED] > >wrote: > > > Hi Eitan, > > > > I also would be interested in knowing what people are doing here. > > > > We do something akin to yours, but have put the logic in the database > > itself. We build an "update package" which is a set of database > > changes. Each update package is given a GUID and as we apply the change > > package we write the GUID to a table in the database, each step in the > > update package must test for the existance of its GUID in the table. > > > > So far I have not found anything in MSI or WIX that allows you to really > > do what you have said here. In part I think it is because a database is > > something fundimentally different to a dll or exe. You can't just > > replace it. > > > > But I would be very interested in being told I am wrong. > > > > Michael > > > > -----Original Message----- > > From: Eitan Behar [mailto:[EMAIL PROTECTED] > > Sent: Thursday, 25 September 2008 4:42 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: [WiX-users] SQL scripts and Upgrades > > > > Hi, > > > > I have a big fat setup with several baseline SQL scripts, and after it's > > released, I get delta SQL scripts that fix the released database. > > > > The scenario is as follows: > > > > When doing a first installation, I do the baseline (v0), plus all the > > deltas (i.e. v1, v2, v3) > > > > If doing an upgrade, I do check which version is installed and run only > > the corresponding delta (i.e. if v1 is installed, run v2, and v3). I do > > all this process using custom actions. > > > > I wonder if there is a better way to do this. Can I set a condition that > > does not reinstall a particular component if it's already installed? > > > > Thanks, > > > > Eitan > > ------------------------------------------------------------------------ > > - > > This SF.Net email is sponsored by the Moblin Your Move Developer's > > challenge Build the coolest Linux based applications with Moblin SDK & > > win great prizes Grand prize is a trip for two to an Open Source event > > anywhere in the world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > ------------------------------------------------------------------------- > > This SF.Net email is sponsored by the Moblin Your Move Developer's > > challenge > > Build the coolest Linux based applications with Moblin SDK & win great > > prizes > > Grand prize is a trip for two to an Open Source event anywhere in the > world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
