NSIS- Error handling

I have written an installer and uninstaller in NSIS which creates and dr开发者_如何转开发ops 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?

---

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.

---

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.

---

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.