Hi there Fredrik, Thanks for sharing your valuable experience.
Answering to your question and after talking to my boss is that the upgrades on database will be handled by our support team. We have the current scenario. We have nant tasks that produce two installers. One is the main installer to be applied on a clean machine and the other one is the upgrade to the components current version. The first one will install the database, and never drop it on uninstall. The idea of the second one is to update only application components, i.e, Dlls and website pages. The settings files and the database upgrades will be handled by our support team now. In a future we can include the upgrades in the upgrade installer, but this is a little more tricky because it will affect the automatic process of generating our MSI, because from one version to other we can apply one or several sql files to change DB structure. Finally to know the database version as we don't put it under windows installer we decided that the upgrade sql scripts will write on a log data table the history of upgrades. I hope that I've answered your question Regards, Tiago On 9/11/06, Fredrik Grohn <[EMAIL PROTECTED]> wrote: > 1. You probably don't want to leave the component behind on the system on > uninstall in any case. It sounds like what you really want to do is make the > removal of the database conditional. That sounds like a perfectly valid > feature request to me. Unfortunately I can't think of a way to do it with > the current implementation though. (You can only hard-code if the database > should be dropped on uninstall.) > > 2. This bug has been puzzling me for a while. I agree that it is a valid > assumption that a rollback should attempt to leave the system in a state as > close to the original state as possible. The problem I believe is that the > assumption when a CA finds an entity that it is meant to install itself > already present on the system, is that it is the result of a failed > installation or similar. It will then "tolerate the error" by proceeding > anyway ignoring the fact that the entity was present on the system. The > result of cause is that it will behave like it actually installed the given > entity when performing a rollback and clean the entity up. It could be > argued that the proper behavior is to fail instead in this situation instead > of accepting the error. > > The problem with making this behavior fully transactional and never delete a > resource we didn't create in the first place is that it is a lot more > difficult to implement. Also I think that the general convention used by the > Windows Installer is the current behavior of the SQL CA's. > > User data is handled a bit different by the Windows Installer though. And > after writing this little essay I have convinced myself that the correct > thing to do is to make the SQL CA's not drop the database on rollback if it > was present before the installation. > > Just a small question: Have you given any thought to how you want to handle > upgrade scenarios? Would you ever need to do modifications to a database > left behind by an older version of your software when you are installing a > new version? > > Fredrik > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson > Sent: Monday, September 11, 2006 6:49 PM > To: Tiago Silva > Cc: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Components and SQL Issues > > Tiago Silva wrote: > > 1. My boss wants that the current setup of our application ask to the > > user if he wants to keep the application database and settings. I have > > two separated components and I evaluate if the components are to > > uninstall or not. The problem is that the Components uninstall run > > always no mather the Condition values that are set. I saw the property > > named Permanent but is no good for me because I want to give the > > choise to the user. > > > Component conditions kick in only during installation. They don't affect > uninstallation. You can make them features so the user has visible > control over them. > > 2. This one I think that is a known Bug, but sincerely I don't know > > the state of it. If I install a database on a server that already have > > a database with the same name, and after the sql authentication is > > performed an install error occur, the database is dropped from the > > server. Any news of it? > > > That bug (#1212275) is still open. > > -- > sig://boB > http://bobs.org > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
