Why don't you just install it properly to begin with?
setup.exe /qb ADDLOCAL=SQL_Engine,SQL_Data_Files,SQL_Replication,Client_Components,Connectivity,SQL_SSMSEE INSTANCENAME=@@InstanceName@@ SAVESYSDB=1 SQLBROWSERAUTOSTART=1 SQLAUTOSTART=1 AGTAUTOSTART=1 SECURITYMODE=SQL SAPWD=@@Password@@ DISABLENETWORKPROTOCOLS=0 ERRORREPORTING=1 SQMREPORTING=0 ADDUSERASADMIN=1 INSTALLSQLDIR="%ProgramFiles%\Microsoft SQL Server\"
sknake
Industrious Poster
4,954 posts since Feb 2009
Reputation Points: 1,764
Solved Threads: 735
....what I do is have a front-end application that lets the user defines the parameters. The application then writes that command out to a "install.bat" file and ShellExecute() 's the file so the user doesn't have to run the command. I suggest you do the same. This is delphi/pascal code:
procedure TMSDE2005Fm.ButtonInstallClick(Sender: TObject);
Var
txt: TextFile;
aFileName, s: String;
begin
aFileName := GetTempDir + '\PROD_Name.bat';
AssignFile(txt, aFileName);
ReWrite(txt);
s := GetSetupString;
WriteLn(txt, s);
CloseFile(txt);
MessageDlg('Setup will now begin for SQL Server 2005 Express.', mtInformation, [mbOk], 0);
ShellExecute(0,'open',PChar(aFileName),nil,nil,SW_SHOW);
ButtonCancel.Caption := '&Finish';
end;
function TMSDE2005Fm.GetSetupString: String;
begin
Result := '"' + Trim(wwDBEditSetup.Text) + '" /qb';
Result := Result + ' ADDLOCAL=SQL_Engine,SQL_Data_Files,SQL_Replication,Client_Components,Connectivity,SQL_SSMSEE';
Result := Result + ' INSTANCENAME=' + Trim(wwDBEditInstanceName.Text);
Result := Result + ' SAVESYSDB=1';
Result := Result + ' SQLBROWSERAUTOSTART=1';
Result := Result + ' SQLAUTOSTART=1';
Result := Result + ' AGTAUTOSTART=1';
Result := Result + ' SECURITYMODE=SQL';
Result := Result + ' SAPWD=' + Trim(wwDBEditPassword.Text);
Result := Result + ' DISABLENETWORKPROTOCOLS=0';
Result := Result + ' ERRORREPORTING=0';
Result := Result + ' SQMREPORTING=0';
Result := Result + ' ADDUSERASADMIN=1';
Result := Result + ' INSTALLSQLDIR="' + Trim(IncludeTrailingPathDelimiter(wwDBEditTargetDir.Text)) + '"';
end;
sknake
Industrious Poster
4,954 posts since Feb 2009
Reputation Points: 1,764
Solved Threads: 735
Yes it is but why do something wrong from the start and go back and fix it? Why not just do it properly to begin with. You can add a custom installer action and create a class in your assembly to execute which contains the script. You're adding a lot of un-needed complexity to the situation.
sknake
Industrious Poster
4,954 posts since Feb 2009
Reputation Points: 1,764
Solved Threads: 735
Yes but you cannot guarantee the SQL Server will be set up properly once it is on the client machine. I have deployed thousands of SQL Server instances and constantly a machine has AV or firewalls that bugger up the install. Likewise I have never tried to send SQL Configuration parameters to an existing installation.
You are going to create a support nightmare for yourself because you are almost there and don't want to go back to the beginning and do it properly. I'm not going to help with that :( McAfee and a few other AVs are guaranteed to bust an SQL Server installation.
Good luck and I wish you the best!
sknake
Industrious Poster
4,954 posts since Feb 2009
Reputation Points: 1,764
Solved Threads: 735
The parameters in setup.exe that I posted in:
http://www.daniweb.com/forums/post960476-2.html
are what you want to use to install the SQL Server. It will accept named pipe/remote connections.
You could call Process.Start() with all of the arguments but I write out a batch file so the user can see the command window with the arguments. I also write out the batch files because if the installation fails they may want to manually change or configure the options. It gives you a last-chance user-override.
It will not add SQL Server to the Windows Firewall Exceptions that I know of. However I have never had an issue with Windows Firewall blocking an SQL Server by default. AVG firewalls will block it though.
sknake
Industrious Poster
4,954 posts since Feb 2009
Reputation Points: 1,764
Solved Threads: 735