NSIS-错误处理
我在 NSIS 中编写了一个安装程序和卸载程序，它创建和删除一个 sql 数据库，工作正常。我编写了一些 .bat 和 .sql 文件来创建和删除数据库，然后从 NSIS 脚本调用这些文件。我的问题是，如果我在 SQL Server Management Studio 中保持此数据库打开并运行卸载程序，理想情况下它应该给出数据库已打开的错误消息。就我而言，它显示卸载程序的成功消息，但没有正确删除数据库。我该如何处理 NSIS 中的这个错误？
I have written an installer and uninstaller in NSIS which creates and drops an sql database, which is working fine. I have written some .bat and .sql files to create and drop the database and then just call these files from NSIS script. My problem is if I keep this database open in SQL Server Management Studio and run the uninstaller ideally it should give an error message that the database is opened. In my case it shows the success message of uninstaller but dosnt drop the database properly. How can I handle this error in NSIS?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这取决于您如何从 NSIS 调用这些 sql 文件。假设您使用 SQL 命令行，则可以使用 nsExec::ExecToStack 来捕获输出。请注意字符串长度的限制（可以使用 NSIS 的特殊版本之一进行修改）：
http://nsis.sourceforge.net/Docs/nsExec/nsExec.txt
检查堆栈顶部是否有错误，该错误指示命令行是否返回非零返回代码。如果没有错误，您仍然需要解析 sql 命令的输出以查看那里是否记录了错误。您可能需要将参数传递到 sql 命令行以指定详细错误输出等。这将取决于您进行试验并查看什么场景会产生什么输出。我通常会记录 ExecToStack 的输出，以便我可以在事后查看返回的内容。
It depends on how you are calling these sql files from NSIS. Assuming you are using the SQL command line, you could use nsExec::ExecToStack to capture the output. Note the limitation on string length(which can be modified with one of the special builds of NSIS):
http://nsis.sourceforge.net/Docs/nsExec/nsExec.txt
Check for error on the top of the stack, which indicates if the command line returned a non-zero return code. If there is no error, you still need to parse the output of the sql command to see if there were errors logged there. You may need to pass paramters to the sql command line to specify verbose error output and whatnot. That will be up to you to experiment with and see what scenarios produce what output. I normally log the output from ExecToStack so that I can go back and see after the fact what was returned.
您的 .bat 文件应该退出并带有错误代码（例如 1）。当您调用 .bat （我认为使用 ExecWait）时，您可以捕获返回代码。然后，将返回代码与错误进行比较，如果相等则调用 SetErrors 函数。如果您愿意，我可以给您一个示例代码。
Your .bat files should exit with a error code (such as 1). When you call the .bat (with ExecWait I presume) you can catch the return code. You then compare the return code with the error and call the SetErrors function if they're equals. I can give you an example code if you wish.
根据我的经验 - 处理 SQL 和 RDMS 或其他数据库类型非常不方便，并且您总是会遇到数据库引擎供应商不会简单说的某种问题。
目前 - 最合适的处理方式（在我的生产环境中，如果与调整它的所有可能性相比，这是非常通用的）是在 NSIS 插件中处理它们并让面向对象编程（例如，如果您编写C# / C++ / Delphi / .NET / 等中的代码）关心错误处理，而不是安装程序。事实上 - 安装程序只应该关心（如果您想让插件重用，但不完全绑定到其他闭源产品）系统状态/事实，而不是为您提供处理捆绑产品配置的逻辑。
正如其他评论者所说，以我的拙见，您必须关心影响安装程序代码库本身的太多选项和设置。您希望实现 SQL 文件利用所需的逻辑，而不是浪费时间重新编译 NSIS，对吧？ :)
当然，使用 nsExec 是做到这一点的一种方法，但是如果您经常使用 NSIS，我想您可能也会得出这样的结论：添加基于插件的堆栈管理与插件分开，负责捆绑软件安装或任何其他所需的逻辑，只会使您的实现和代码库变得不一致且不可靠。
答案 - 不要这样做，但如果你只有这个选项，那么就基于某种回调方法，而不是 shell 脚本或其他依赖于操作系统的功能。
From my experience - handling SQL and RDMS or other database types is pretty unhandy and you can always hit some kind of issues the database engine vendor would mnot simply say.
Currently - the most appropirate way ( in my production environment, which is very generic, if compared to all the possibilities of tweaking it ) of handling things is to handle them in NSIS plugin and let the Objecy Oriented Programming ( for example, if you wrote code in C# / C++ / Delphi / .NET / etc. ) care about error handling, not the installer. In fact - installer only should care ( if you want to make plugin reusbale, but not fully bounded to other closed-source product ) about system state / factology, not provide you with the logics to handle the configuration of bundled product.
As other commenters have stated, you have to care about, in my humble opinion, too much options and settings affecting the installer code-base itself. You want to achieve requiered logics for SQL file utilization, instead of messing around with recompilation of NSIS, right? :)
Of course, using nsExec is one way of doing that, but if you have had played a lot with NSIS, I guess you alsmo might have conclusion that adding plugin-based stack managament seperate from Plugin, taking care of bundled software installation or any other requiered logics, just makes your implementation and code-base preety inconsistent and unreliable.
Answer - do not do that, but if you have it only option, then make it based on some callback methodology, not shell scripting or other OS-dependant features.