Question

I have an InstallShield project that invokes an EXE written in C#, passing it some parameters, like so:

MyProcess.exe [serverName] [dbName]

Internally, this process opens a SQL connection, using the following connection string:

Data Source=[serverName];Initial Catalog=[dbName];Integrated Security=True

where [serverName] and [dbName] are the values passed in from the command line.

When I run MyProcess.exe directly from my own command line, passing serverName=localhost and dbName=myDB, it works perfectly. But when I invoke this exe from my InstallShield script with the same parameters, I get an error:

Cannot open database “myDB” requested by the login. The login failed.
Login failed for user ‘MYDOMAIN\myusername’.

But MYDOMAIN\myusername is a freakin’ admin on the local database! I’ve even put a log line in MyProcess.exe to verify that the connection string is, in fact:

Data Source=localhost;Initial Catalog=myDB;Integrated Security=True

So the big mystery is: why does it work when I run the command line directly, but not when the same command line is run from InstallShield (run by the same Windows user)? And how to fix this?

Answer 1

OK, I’ve worked it out.

The previous step in the installation was to do a restart of the SQL Server service. We never noticed a problem before, because the databases we were working on before were relatively small – but now the database I’m upgrading using this InstallShield script is a Big Mama of around 20GB.

So – it seems that when restarting a SQL Server, larger databases take a longer time to come back online. This also explains why MyProcess.exe ran perfectly with the same parameters later – because by then the DB was back online!

Solution: in the try-catch of the connection to the DB, let it try again (up to n times) after a Thread.Sleep().