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.
Related
First the basics: I'm using VS2015 SSDT to create a SSIS Package to pick up two files on a DFSR share (Windows 2012 R2) that are then imported into a SQL Server 2016 database. The package is run via SQL Server Agent. The SQL Server Agent is running under a domain account that has permissions to the DFSR folder and subsequent files.
The Problem: I'm getting a weird issue that I seem to have dwindled down to having SSIS script tasks being unable to change the value of a SSIS variables.
I've got a script task that uses VB2015 to check if two files exist. The file paths use variables to build the full path and then checks that both are present. If they are both present, it sets a variable to "True" and then exist. This runs just fine in VS2015 SSDT while testing the functionality, but the variable doesn't change when running under SQL Server Agent.
Here's the code:
Public Sub Main()
Dim filepath As String = CStr(Dts.Variables("User::varFileDirectory").Value)
Dim emplfile As String = filepath + CStr(Dts.Variables("User::varEmployeeCSVFile").Value)
Dim histfile As String = filepath + CStr(Dts.Variables("User::varHistoryCSVFile").Value)
If (File.Exists(emplfile) AndAlso File.Exists(histfile)) Then
Dts.Variables("User::varFilesExist").Value = True
Else
Dts.Variables("User::varFilesExist").Value = False
End If
Dts.TaskResult = ScriptResults.Success
End Sub
If the files are found in the folder it set User::FilesExist to "True" and then is used in the subsequent constraint as an expression:
I pass this constraint while testing from SSDT 2015, but once it's deployed over to the SSIS repository on SQL Server 2016, it no longer get's passed this constraint when there are files there.
I've verified my package runs by simply setting the default value of "User::varFilesExist" to "True". The pakage runs flawlessly from SQL Server Agent when this is done. On the first run, it deletes the files that have been loaded, so when it runs a second time, it fails since those files are not present.
I feel like I'm missing something simple, but it appears that the script is not changing/updating the value of "User::FilesExist" within the script. I believe my VB2015 code is correct because it tests just fine when run within VS2015 SSDT
Today I installed SSDT 2017 and brought over my packages. Tested and then deployed and everything is working as expected. Not sure what was going on.
I have build SSIS packages on Server (suppose A) defining it's configuration in a XML. I have copied the package and the config file to a different server (suppose B) and run it using a Batch command as below:
echo "Running SSIS Load" >D:\samplessis\log\Mylog.log dtexec.exe /f "D:\samplessis\ag_data_import.dtsx" /CONFIGFILE "D:\samplessis\config\AgDataLoad.dtsConfig" /MAXCONCURRENT " -1 " /CHECKPOINTING OFF >>D:\samplessis\log\Mylog.log
This package seems to be using the configuration defined in package but not the xml(config file)
When DTEXEC is given an XML config file in MSSQL 2008 R2 or later, it configures itself in this order when run:
The utility first applies the design-time configurations.
The utility then applies the run-time options that you specified on the
command line when you started the utility.
Finally, the utility reloads and reapplies the design-time configurations.
(source: https://technet.microsoft.com/en-us/library/bb500430(v=sql.105).aspx)
This means that the configuration in the package at runtime is Design - XML - Design. If you were to change the contents of the XML file and run the DTEXEC command on your dev-box, you would get the same results...
To get around this, after setting up the configurations in the designer, clear out the initial values. For instance, if you have a connectino string as a parameter, design the Connection Manager, add the Connection String to the XML File, then in the Connection Manager's properties, clear out the connection string.
When there are no values specified in design-time, the designer will configure itself based on the XML file, as well as applying that XML file when run with DTEXEC.
I am using the SQL Server Import/Export Wizard to import data from an Excel file into a table. I will need to do this exact import many times so I selected the option "Save SSIS Package."
I tried saving to SQL Server and I tried saving to File System.
Either way, I cannot figure out how to use the package in SQL Server. I read that I need to use Agent Job Task to do it but I cannot find that anywhere in the SQL Server program.
I also looked for Integrated Services in SQL Server and I found an icon that doesn't seem to do anything.
How do I go from having a .dtsx somewhere on my computer to executing the import (in a query preferably) without having to go through the whole wizard process again and again?
Thank you
The Import/Export Wizard creates a file called .DTSX. This is your SSIS package. An SSIS package is a text file filled with a bunch of XML. Contrast this with something that ends in .EXE/.COM which is an executable that any windows machine will be able to run.
We need something to consume that .dtsx file and perform the ETL operations described therein. There are three options open to you: dtexec.exe, dtexecui.exe, and custom .NET code. dtexecui is just a graphical wrapper to the command line so really, your choices for running packages are the prebuilt command line utility or custom code. Running a package via dtexec can be as simple as dtexec.exe /file C:\MyPackage.dtsx
Since you want to run this from the context of SSMS, then you'll need to either Create a SQL Agent Job or create a stored procedure that calls dtexec. Since you're new to the whole business, the Job will provide the lowest barrier of entry.
In your SSMS, connect to an instance and navigate to the bottom. You should see "SQL Server Agent" Expand that node and Right-Click on "Jobs" and choose New Job. In the Steps tab, click New.... Change the Type to "SQL Server Integration Services Package"
Pick your source (file system or SQL Server) Fill out the server name or where the package lives and you should be good to go.
One very important thing you will need to know is that Excel drivers are only going to work in 32 bit mode. This means you will need to use the dtexec.exe that exists at C:\Program Files (x86)\Microsoft SQL Server\XXX\DTS\Binn\dtexec.exe To get that behaviour from the SQL Agent job, then you will need to add the /X86 option to the command line like
The x86 flag only works for SQL Agent job calls. From the command line, you must use the correct version of dtexec.exe
Yeah I did add the 4 dlls, found in:
C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies
Which are these:
Microsoft.SqlServer.ConnectionInfo.dll
Microsoft.SqlServer.Smo.dll
Microsoft.SqlServer.Management.Sdk.Sfc.dll
Microsoft.SqlServer.SqlEnum.dll
And modified app config so it accepted the version the dlls had:
<startup useLegacyV2RuntimeActivationPolicy="true">
</startup>
And imported from VB.NET:
Imports Microsoft.SqlServer.Management.Smo
Imports Microsoft.SqlServer.Management.Common
And the program recognizes every word except Server:
Dim fileInfo As New FileInfo(fi.FullName)
Dim script As String = fileInfo.OpenText().ReadToEnd()
Dim connection As New SqlConnection(sqlConnectionString)
Dim server As New Server(New ServerConnection(connection))
server.ConnectionContext.ExecuteNonQuery(script)
It says:
'Type Server is not defined'
Thus the program fails. Any ideas of what is going on? I'm pretty sure an identical scenario is working on a test project on another computer, I don't know why this isn't working. Thanks.
UPDATE:
I tried bringing the dlls from the computer that has this program working to here, and Smo contained Server, so there were no errors. But when I built the program it's like the dlls changed during runtime or something, because suddenly Server is marked as an error again and Smo doesn't contain it anymore, why is this happening?
SMO is unfortunately not something that can be deployed by just copying the DLLs. We have this in our app (along with RMO and others), and it is a right pain to deploy to production. It needs the appropriate MS installers run.
You can get them from here:
http://www.microsoft.com/en-us/download/details.aspx?id=16978
Or, the 64bit installer:
http://go.microsoft.com/fwlink/?LinkID=188439&clcid=0x409
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.