[ wix-Bugs-1212275 ] SQL database always dropped on rollback

Bugs item #1212275, was opened at 2005-05-31 14:13
Message generated for change (Settings changed) made by robmen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1212275&group_id=105970

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: CustomActions
>Group: v2.0
Status: Open
Resolution: None
Priority: 5
Submitted By: anfortas (anfortas)
Assigned to: Scott Kurtzeborn (scotk)
Summary: SQL database always dropped on rollback

Initial Comment:
Say an installer has a SqlDatabase with 
DropOnUninstall="no" and a SqlString used to initialize 
the database. Now say this installer is run on a 
machine where the database already exists, and 
executing the SqlString fails. During rollback, the 
existing database is dropped!

For a database to be unexpectedly dropped is very, very 
bad!

----------------------------------------------------------------------

Comment By: anfortas (anfortas)
Date: 2005-07-06 08:10

Message:
Logged In: YES 
user_id=1203922

I envision two common usage scenarios: either the database 
comes and goes with the rest of the product, or else the 
product ensures that the database is there but the database 
should never be removed. RemoveOnUninstall is already a 
pretty good indication of the author's intention, so I would 
suggest that the rollback be considered an uninstall and use 
that attribute to decide what to do. 

Leaving behind a database after a failed installation is 
typically no big deal if a successful install and uninstall would 
have left it behind anyway. The important thing is to not 
destroy vital data. 

----------------------------------------------------------------------

Comment By: Scott Kurtzeborn (scotk)
Date: 2005-07-05 23:14

Message:
Logged In: YES 
user_id=1296992

About the only way to fix this is to add an attribute like 
DropOnRollback="no" or something.  Is this an acceptable 
solution?

The problem is that we don't crack open a SQL connection 
during the immediate action ConfigureSql.  Therefore we can't 
tell whether the database already exists or not.  The best we 
can do is allow you to author whether or not the database 
should be cleaned up if an error is encountered.  This would 
mean that if you set the flag and the database didn't exist, 
that it wouldn't be cleaned up.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1212275&group_id=105970


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642