Reputation: 37993
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?
Upvotes: 0
Views: 409
Reputation: 37993
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()
.
Upvotes: 1