Bugs item #1212275, was opened at 2005-05-31 14:13 Message generated for change (Comment added) 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: extensions Group: v2.0 Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: anfortas (anfortas) Assigned to: Rob Mensching (robmen) 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: Rob Mensching (robmen) Date: 2007-01-11 23:41 Message: Logged In: YES user_id=991639 Originator: NO All of the SQL CustomActions, immediate and deferred, are impersonating. That means they are always going to connect to SQL as the user doing the install (unless you use SQL authentication, of course). That is the way it is today. This fact made it possible to do the simple fix. Elevation in Vista matters none because all the impersonated CustomAction servers have the protected token. My understanding is that SQL Server doesn't care and if it does then we're totally hosed on Vista SQL Server integrated-auth communication in CustomActions (immediate and deferred). I'm working on the ability to pass data between deferred/rollback CustomActions now for the "User deleted on rollback" bug that is basically the same as this bug. But as noted above, that functionality isn't necessary for our SQL connections. ---------------------------------------------------------------------- Comment By: Kalle Olavi Niemitalo (kal-le) Date: 2007-01-11 23:36 Message: Logged In: YES user_id=20705 Originator: NO How did you make this work? If Windows authentication (integrated security) is specified for the database connection, and either a non-privileged user is installing a package advertised by an administrator, or on Vista the user is a protected admin, then I think immediate custom actions might not have permission to connect to a database that elevated deferred custom actions do have permission to drop. In this scenario, I think you'd have to do the check in an elevated deferred custom action; but then it wouldn't be so trivial to pass information to the rollback script: you'd need either an InstallExecute between scheduling the check and scheduling the rollback, or a temporary file or non-volatile registry key that would be written by the check and read by the rollback. On MS SQL Server, I suppose one could generate a GUID in an immediate custom action, write it to an extended property of the database if the create succeeds, and drop the database on rollback only if the same GUID is still there. That would be awfully DBMS-specific though. ---------------------------------------------------------------------- Comment By: Rob Mensching (robmen) Date: 2007-01-08 15:23 Message: Logged In: YES user_id=991639 Originator: NO I found that it was possible to connect to the master database before installing to check if the database exists. If the database exists, then we do not schedule a drop for rollback (to preserve what was there before installing). If the database does not exist, then we assume we'll create it and drop it on rollback. ---------------------------------------------------------------------- Comment By: Scott Kurtzeborn (scotk) Date: 2006-12-19 21:09 Message: Logged In: YES user_id=1296992 Originator: NO DropOnUninstall="no" is what I'll implement here then. ---------------------------------------------------------------------- Comment By: MKCline (mkcline) Date: 2006-07-12 08:11 Message: Logged In: YES user_id=1547715 I think a tag such as DropOnRollback="no" would be a great solution as this specifically states what you want to do and eliminates the installer 'unknowingly' dropping a database just because they don't want to use it in their installer. ---------------------------------------------------------------------- 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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ WiX-devs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-devs
