I am trying to install SQL Server 2012 via some command line parameters. I have a simple form that has a few buttons to install various projects. One is to install a SQL Server with set names and security for the databases. Here are the commands:
Private Sub btnSQLServer32_Click(sender As System.Object, e As System.EventArgs) Handles btnSQLServer32.Click
curPath = System.IO.Path.Combine(curDirectory, "SQLEXPR.exe")
System.Diagnostics.Process.Start(curPath, "/QS /ACTION=Install /FEATURES=SQL,TOOLS /IACCEPTSQLSERVERLICENSETERMS=""True"" /INSTANCENAME=""TestDatabase"" SECURITYMODE=SQL" & _
" /SQLSYSADMINACCOUNTS=""BUILTIN\ADMINISTRATORS"" /SAPWD=""********"" /SQLSVCACCOUNT=""NT AUTHORITY\NETWORK SERVICE"" /SQLSVCPASSWORD=""********""" & _
" /AGTSVCACCOUNT=""DomainName\UserName"" /AGTSVCPASSWORD=""*******"" /ASSVCACCOUNT=""DomainName\UserName"" /ASSVCPASSWORD=""********""" & _
" /RSSVCACCOUNT=""DomainName\UserName"" /RSSVCPASSWORD=""*******"" /ISSVCACCOUNT=""NT Authority\Network Service"" /TCPENABLED=""1"" /NPENABLED=""1""")
The installation goes through and gets through installing setup files. When it begins to install, it stalls for a second, then exits without further warning.
My question is if there is any kind of error log that I can look at to see if it is one of my commands that are causing this? Does anyone see something that is missing here?
Look in
C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\Log
on the server you're doing the install on.
I'd also look in the windows event log, getting to it is OS specific, and I'd look namely under application.
I've been trying to do this for the last few hours, and I have discovered that SQLEXPR.exe is just a self-extracting container.
Execute SQLEXPR.exe /x to extract the contents. You will find a Setup.exe in that directory, where you will be able to pass your command-line arguments.
Now, you might be wondering how to script the bit where you are prompted to extract the contents, and I can't answer that yet. I'm having a go at this now, because I need to make a totally unattended installer. We may just end up mirroring a zipped copy of the extracted directory on our servers internally somewhere.
Related
I have recently installed SSMS 2022 V18 on my D: drive to conserve some space on the C:
When I try to execute the .dtsx file it says that there is no program available to execute it.
Is there some way to make this work or do I have to re install SSMS on the default C: drive.
10/27/22
Loaded SQL server 19 developer version. included the Integration service. Now I can import my dtsx files and execute them. So far so good. What I would like to do is run the .dtsx packages using DTexec.exe. I follow the example of executing dtexec running a file dtexec /f "d:\documents\sql\hits.dtsx" and it complains about the version numbers.
Package migration from version 8 to version 3 failed with error 0xC001700A "The version number in the package is not valid. The version number cannot be greater than current version number.".
THe dtsx file was created while running sql server 19 SSMS v 18.12.1. Should I load the SSMS package from SQL19?
Any other info would great.
Thanks
SSIS packages are executed by
DTEXEC.exe for command line runs (requires installation of SQL Server Integration Services Service to pass a licensing check)
Custom code referencing the SQL Server assemblies
The managed object model in the SSISDB https://techcommunity.microsoft.com/t5/sql-server-integration-services/a-glimpse-of-the-ssis-catalog-managed-object-model/ba-p/387892
That's it, those are the three "runners" of SSIS packages. Using SSMS to run a package depends on "how" you were doing it versus what you're attempting now. Ultimately, you're connecting to a database and asking it to run a package.
If the package is in the SSISDB, it's using MOM.
It you were running a job, it's dtexec.exe
If you connected to the Integration Services connection node "thing" in SSMS, that's using dtexec, the 64 bit version I think?
If that's the case, changing SSMS likely also involved changing versions of SSMS which is version specific from what I can tell with that connector option.
OK so I came up with a solution for executing dtsx packages from another program.
the program that I want to run is DTExecUI.exe. In my case that's found in
"D:\Program Files\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Binn\DTExecUI.exe"
This program takes a parameter /f to indicate that is to get the data from a file and then the file location. example " /f D:\Documents\SQL\ipdata.dtsx.
Having figured all that out I wrote a little console app in VB that take the file name as a input parameter and launches DTExecUI to execute the file.
Imports System
Module Program
Sub Main(args As String())
Dim app As String = "D:\Program Files\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Binn\DTExecUI.exe"
Console.WriteLine(args(0))
Dim Arguments As String = "/f " & args(0)
LaunchProc(app, Arguments)
End Sub
Sub LaunchProc(fileNam As String, ByVal Optional arg As String = "",Optional wt As Boolean = True)
Dim p As New Process
p.StartInfo.FileName = fileNam
If arg > "" Then p.StartInfo.Arguments = arg
p.Start()
If wt Then p.WaitForExit()
End Sub
End Module
To make make it so I can run the dtsx file directly by double clicking on it. I associated the dtsx file extension with my little program. Works like a charm.
I am using the following command to generate to publish database changes using SSDT:
"C:\Program Files\Microsoft SQL Server\150\DAC\bin\SqlPackage.exe" /Action:Publish /sf:DB.dacpac /Profile:publish.xml
I would like to supply database connection string as an argument instead of using a hard coded connection string from publish.xml. Is there anyway I can override it?
I tried:
"C:\Program Files\Microsoft SQL Server\150\DAC\bin\SqlPackage.exe" /Action:Publish /sf:DB.dacpac /Profile:publish.xml /TargetConnectionString:$ConnectionString
where $ConnectionString is an argument from Jenkins. However, it still uses ConnectionString from publish.xml.
I had a quick look at the source code with reflector (Microsoft.Data.Tools.Schema.CommandLineTool.ValidationUtil) and what happens is that TargetConnectionString is read from the command line, then after that the value in the publish profile overwrites the value - that can't be changed I am afraid.
The interesting thing is that after it has the connection string from either /TargetConnectionString or the publish profile it then applies the individual properties such as /TargetDatabaseName so i think (untested but looks good from the code) if instead of passing /TargetConnectionString you pass the individual components such as:
/TargetUser, /TargetPassword, /TargetDatabaseName, /TargetServerName, etc.
Then I think it will override the connection string in the publish profile, it is quite hard to read so let me know how you get on!
ed
I'm trying to run an SSIS job daily using the SQL Server Agent. In my job step I have:
Type - Operating System (CmdExec)
Run as: Sql Server Agent Service Account
Command: "C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\DTExec.exe"/F"C:\Users\Administrator\Documents\SourceToTarget\SourceToTarget\TestSqlServerAgent\TestSqlServerAgent\GoogleGeocode.dtsx"
When I run this I get an error saying: "At least one of the DTS, SQL, ISServer or File options must be specified. Process Exit Code 6"
Does anyone know how to fix this?
The best way to chose your command is to open the package, go to commandline tab and copy the whole line. Then put this line in front of DTExec command. You do that you need to make sure your connectionstrings a properly set up. Fire the command like this and you'll be fine.
If your command line truly is
"C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\DTExec.exe"/F"C:\Users\Administrator\Documents\SourceToTarget\SourceToTarget\TestSqlServerAgent\TestSqlServerAgent\GoogleGeocode.dtsx"
Then the problem is that you need a space between the arguments
"C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\DTExec.exe" /F "C:\Users\Administrator\Documents\SourceToTarget\SourceToTarget\TestSqlServerAgent\TestSqlServerAgent\GoogleGeocode.dtsx"
Unfortunately, testing that on my machine doesn't yield the error message you've encountered.
In fact, searching for DTEXEC error code yielded this fine answer from William Salzman which reinforces my guess that the supplied arguments for your agent job have been simplified/obfuscated for posting.
I'm not sure why but it looks like sql server is using a different path environmental variable then the rest of my system. When i add the cmd as an external tool in sql, by going to
Tools->external Tools and adding cmd.exe as the command i get a different path.
the shell from sql gives me
echo %PATH%
c:\Program Files (x86)\Microsoft SQL Server\100\Shared\;C:\Windows\system32\NV;.;
This does not reflect my path variable at all
when I echo the path from a regular command prompt I get my full path.
When SQL starts up it looks like it is using its own environmental variables. Does anyone know where these are defined or if I can have my system path appended to this "special" SQL path?
Looks like it's very rare problem. I found only this topic and it without solution.
I faced same problem.
Stopping all services that on the screenshot (in running state) and start them again one by one solved my problem.
I think your SQL Source Control issue may be related to something else. You may want to check your path and make sure that it doesn't have extra backslashes or double-quotes in it -- DOS is fine with that but the dox for ProcessStartInfo in .NET say this will not be a recognized path. For instance
c:\windows;c:\git;"c:\program files\git\bin"
With Git.exe in any of the latter two path components, you could launch Git.exe from the command prompt but the command would fail in SQL Source Control.
I've got a web application that uses Microsoft Sql Management Objects (SMO) dll's. I'm wondering how I go about redistributing the libraries for a remote machine.
As I understand it, these come with SQL server or Sql express - which isn't on the remote (shared) webserver. Asking the host to install them, is probably out of the question, so is it possible to dynamically load them?
See below error-
Could not load file or assembly 'Microsoft.SqlServer.Smo, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.
Alternatively, if anyone can provide a workaround for the below snippet that would also be useful. The script variable is a SQL install script which has been read to the end. The nice thing about this is the outputting of each of the execute strings from SQL. I could of course just execute it all in one chunk, but that provides no visual feedback to the user line by line, that the sql is executing ok.
Is there a stored procedure that could perform this sort of thing? Or an alternative way to execute an install script without full permissions.
Dim connection As New SqlConnection(Me.ConnectionString)
connection.Open()
connection.Close()
Dim server As New Server(New ServerConnection(connection))
server.ConnectionContext.SqlExecutionModes = SqlExecutionModes.ExecuteAndCaptureSql
Dim commands As StringCollection = server.ConnectionContext.CapturedSql.Text
server.ConnectionContext.ExecuteNonQuery(script, ExecutionTypes.ContinueOnError)
Dim s As String
For Each s In server.ConnectionContext.CapturedSql.Text
AppendMessages(s)
Next
http://www.mattberther.com/2005/04/11/executing-a-sql-script-using-adonet/
from
http://coolthingoftheday.blogspot.com/2006/11/execute-t-sql-scripts-with-gos.html
Was what I was looking for, and did the trick.
you can try using sqlcmd utilty that comes with sql server
No, you can't dynamically load them, and no, you can't install them without permissions. Sorry about that, but no dice there.