Mittwoch, 25. April 2012 12:20
I have a setup file which copies the primary database files (.mdf and .ldf files) to the machine and will attach this database to the selected instance of the SQL Server running on the machine. For attaching it uses SQLCMD commands as part of the C++ custom actions in the Install Shield. This is working fine with SQL Express versions 2005 and 2008. But when trying to attach with SQL 2012 instance, it is failing with the error "CREATE DATABASE permission denied in database 'master'". But if I run the same commands from the command prompt (not with the admin previlege), it is getting attached to the SQL Server successfully. The SQL 2012 instance is configured with Windows authentications ( DOMAIN\Administrator).
When I have tried the same c++ custom action code in a sample C++ application, it is getting attached successfully.
Please help me in resolving this issue. I tried all the similar helps provided in this forum ( for other SQL versions) and no luck still. Please help ASAP.
Mittwoch, 25. April 2012 12:42
I doubt that there is a difference between SQL 2005/2008 on the on hand and SQL 2012 on the other in this regard. Rather I would assume that this is a difference of different settings between your installations.
An important thing when you install SQL 2008 or SQL 2012 is that you are required to enter a user which is to have sysadmin rights. If you run you Install program with a different users, you may have permissions problems.
One thing to check is the output from "SELECT * FROM sys.login_token" in the different situations.
Erland Sommarskog, SQL Server MVP, email@example.com
Mittwoch, 25. April 2012 19:11
use SQL Server Profiler to see what statement is executed by InstallShield and what account is used to execute the commands.
Start SQL Server Profiler, start a new profiling session and connect to your SQL Server 2012. Than start your setup.
Assuming that your Install Shield does use Windows Installer in the background, than the command executed against the SQL Server 2012 are probably the system account use to run msiexec.exe and the account is likely not having sysadmin privilege on SQL Server 2012 if you're using Windows authentication and not SQL Authentication for the creating the database.
You would see the error in the SQL Server log too which listens the account name too.
If the system account (NT System or the like) is used than you need to check if you can specify a SQL login to create the database and that account needs sysadmin privilege (at least privilege to create a database)
Mittwoch, 25. April 2012 21:11
Well, there is no sample code and no error message to read so I'm working on pretty much nutt'n.
Consider creating a trace or server-audit to see what's happening on the engine side:
Just based on what you wrote, I tend to agree with Erland; the session's user-context is the problem. I vaguely recall something about custom actions working under a different context than the installer's process: possibly "NT AUTHORITY\SYSTEM". To rule this out, double-check the session's context when launching SQLCMD by running something like "SELECT suser_sname()" and capturing the output to confirm you are who you think you are. Make sure you do this thru an Install Shield custom action not a C++ test program.
Freitag, 4. Mai 2012 04:13
Thanks for your time to post the replies...
And the replies infact helped me in fixing the issues... And from these I came to know that the issue is because of the privilege settings.
The custom action type in the installshiled was set for "Defered excution in System context" and the type ID was 3073.
I have changed this to just "Defered Execution" (1025) and the SQLCMD started running in Admin mode and hence solved my issue in creating the database.
Thanks once again to Erland, Daniel and Adam.