I'm creating an MSI installer using Installshield Spring 2012. My installer works well except for one issue. If I delete a certain file in my install, and run repair from Add and Remove Program, the repair fails with error:
我正在使用Installshield Spring 2012创建一个MSI安装程序。除了一个问题，我的安装程序运行良好。如果我在安装中删除某个文件，并从“添加和删除程序”运行修复，则修复失败并显示错误：
Error 27506. Error executing SQL script SqlScript1.sql. Line 10. A file activation error occured. The physical file name 'SEICube.mdf' may be incorrect. Diagnose and correct additional errors, and retry the operation. (5105)
错误27506.执行SQL脚本SqlScript1.sql时出错。第10行。发生文件激活错误。物理文件名“SEICube.mdf”可能不正确。诊断并更正其他错误，然后重试该操作。 （5105）
If I run the repair from within the installer, so, if I double click on my installer again, and choose repair, it works perfectly and I don't get any errors.
如果我从安装程序中运行修复，那么，如果我再次双击我的安装程序，并选择修复，它可以正常工作，我没有任何错误。
Any ideas?
有任何想法吗？
Thank You.
谢谢。
1 个解决方案
#1
2
Log the installer in both scenarios and compare. The main difference I can think of is that the Repair Button in ARP/PF will run it in silent mode so the Install UI Sequence never runs. The Modify button (or double clicking the MSI ) will start the UI sequence and then you select repair. It may be a custom action is firing in the UI that makes it work. In reality it should work silently so the custom action would be inappropriate.
在两种情况下记录安装程序并进行比较。我能想到的主要区别是ARP / PF中的修复按钮将以静默模式运行它，因此安装UI序列永远不会运行。 “修改”按钮（或双击MSI）将启动UI序列，然后选择修复。它可能是在UI中触发的自定义操作，使其工作。实际上它应该静默工作，因此自定义操作是不合适的。
Other possibly related thoughts are that MSI doesn't persist properties but InstallShield will in the case of connection string properties. If you are using SSPI instead of database logins this can cause all kinds of problems depending on who is running the installer.
其他可能相关的想法是MSI不会保留属性，但InstallShield将在连接字符串属性的情况下。如果您使用SSPI而不是数据库登录，则可能会导致各种问题，具体取决于运行安装程序的人员。
Another thought is becaue the database tier could be another server, the use of MDF / LDF files in an installer is not good. The database should be fully scripted and created by the connection. Also the scripts should be so robust that they support install, uninstall, reinstall, repair and upgrade from any previous schema to the current schema.
另一个想法是因为数据库层可能是另一台服务器，在安装程序中使用MDF / LDF文件并不好。数据库应完全编写脚本并由连接创建。此外，脚本应该非常强大，以支持从任何先前架构到当前架构的安装，卸载，重新安装，修复和升级。
#1
2
Log the installer in both scenarios and compare. The main difference I can think of is that the Repair Button in ARP/PF will run it in silent mode so the Install UI Sequence never runs. The Modify button (or double clicking the MSI ) will start the UI sequence and then you select repair. It may be a custom action is firing in the UI that makes it work. In reality it should work silently so the custom action would be inappropriate.
在两种情况下记录安装程序并进行比较。我能想到的主要区别是ARP / PF中的修复按钮将以静默模式运行它，因此安装UI序列永远不会运行。 “修改”按钮（或双击MSI）将启动UI序列，然后选择修复。它可能是在UI中触发的自定义操作，使其工作。实际上它应该静默工作，因此自定义操作是不合适的。
Other possibly related thoughts are that MSI doesn't persist properties but InstallShield will in the case of connection string properties. If you are using SSPI instead of database logins this can cause all kinds of problems depending on who is running the installer.
其他可能相关的想法是MSI不会保留属性，但InstallShield将在连接字符串属性的情况下。如果您使用SSPI而不是数据库登录，则可能会导致各种问题，具体取决于运行安装程序的人员。
Another thought is becaue the database tier could be another server, the use of MDF / LDF files in an installer is not good. The database should be fully scripted and created by the connection. Also the scripts should be so robust that they support install, uninstall, reinstall, repair and upgrade from any previous schema to the current schema.
另一个想法是因为数据库层可能是另一台服务器，在安装程序中使用MDF / LDF文件并不好。数据库应完全编写脚本并由连接创建。此外，脚本应该非常强大，以支持从任何先前架构到当前架构的安装，卸载，重新安装，修复和升级。