I have a command line as following, with DTEXEC to launch the execution of a package and to set a value (13335) of an user variable called CIB (string type):
But I have got an error message saying that the object is not known in the package. My variable does exist in the variable window of the dataflow part.
Thank you for telling me what to set so that the variable can be set by the command line.
I have a serious problem with my SSIS Package while executing using 32-bit DTExec and 64-bit DTExec.
Here are the details:
Environment:
Windows Server 2003 64-bit (Build 3790: Service Pack 2) SSIS 32-bit & 64-bit installed SQL Server 2005 (Microsoft SQL Server 2005 - 9.00.1399.06 (X64) - RTM)
SSIS Package details (compiled in 64 bit)
Script tasks only Microsoft Visual Basic .NET (using TRY...CATCH block) PreCompileScriptIntoBinaryCode = TRUE Run64BitRunTime = TRUE
Execution
Batch file that uses DTExec to execute the Package.
SCENARIO I am trying to exeucte the above SSIS package using both 32-bit and 64-bit DTExec to make it failure by providing invalid connection string. Here are the details,
Wrong connection String using 32-bit Execution
While establishing the connection the error message has been nicely captured in to my Exception block and writes into the log file.
Wrong connection String using 64-bit Execution
While establishing the connection the error has not been catpured anywhere (although I have TRY CATCH block) and it haults there itself with the message "Process is terminated due to StackOverflowException". Later I found that the error is due to the connection string along with the unhandled exception.
Please suggest any one of the following my findings, also if you have any other advice would be very much appreciated.
1. Shall I go ahead and fix the issue by handling those unhandled errors? (e.g Appdomain, application). I tried several but still not working using 64-bit DTExec.
2. Shall I go ahead and use 32-bit DTExec to execute the package? If so, is there any other major issue...like performance or anyother bug?
P.S: We cannot apply any service pack for SQL Server 2005 at the moment. Sorry abt it. If you have any specific hotfix for DTExec (without affecting SQL Server) then we can decide.
Sorry for the lengthy one and Thanks very much for you help in advance .
I understand to schedule an SSIS package to run, I need to use the dtexec utility. I want to schedule the job right within SQL. I walked through how to set up the job, but I really could not decipher the proper syntax to use as a Step.
I have the following:
dtexec /File "C:...file.dtsx"
Is the the proper way to schedule and execute an SSIS package or is there some other way I should be doing this. The pacakge will run unattended nightly. I am using SQL Server 2005.
I have lots of Stored procedures in which we use 'dtsrun' to run DTS Packages. Now, after I upgrade the server to SQL 2005 will I have to change all the Stored procedure's to reflect 'dtexec' instead of 'dtsrun'?
Hi I have a SSIS package which pulls files from a network share and loads data into SQLServer Database. When I execute the application using DTExecUI , It runs fine without any issues , but where as when I run it using the command line arguments, It seems to go in sleep mode and nothing happens. I need to kill the package from Task manager. Following is the command I use to run my application
(Optional). Specifies a configuration file to extract values from. Using this option, you can set a run-time configuration that differs from the configuration that was specified at design time for the package. You can store different configuration settings in an XML configuration file and then load the settings before package execution by using the /ConfigFile option.
Does this mean that I can specify which configuration file to use during runtime? Or is just because I'm too desperate for that, I understood that way
The DTEXEC Utility has the capability of returning ReturnCodes which have specific meanings e.g.
ReturnCode=3 means: The package was canceled by the user.
Is it possible to set my own ReturnCode values?
For example, my Package contains a Script Task which contains code to search a folder for a file. If the file cannot be found then I make the Script Task fail and hence the Package fails. But, when the Package is invoked by the DTEXEC utility, then the ReturnCode is always set to 1. Is it posssible to set the ReturnCode from within the Package (in, say, a Script Task in the Event Handler) to a different value?
It is necessary to be able to set custom application-specific return codes because these return codes are passed to the Batch Scheduler which alerts Operations (Support) staff in the event of failure. Meaningful (custom) ReturnCodes expedite problem solving and are (usually) mandatory in large production environments.
If it is not possible to make a Package return my own returncodes via DTEXEC then can you suggest alternative solutions, please?
I'm trying to execute DTExec from a workstation and I got some help from a different group without luck maybe someone here can help me.
This is what I try so far.
1. My package run in command line from my sql box using dtexec with parameters. 2. Set the package with DontSaveSensitive and import into IS under MSDB with the same option setup. 3. Set package role to public. 4. Share DTS folder with everyone permission just for testing. 5. Execute the package from a workstation using //sqlServerbox/DTS/BINN/dtexec /dts "msdb/mypackage" /SER "MySQLServer" /set package.variables[myvariable].Value;"myvalue1,myvalue2" (myvariable is string and I can pass multiple values separate by commas) 6. Still getting error: Error: 2007-02-09 10:31:34.31 Code: 0xC0010018 Source: Execute DTS 2000 Package Task Description: Error loading a task. The contact information for the task is "E xecute DTS 2000 Package Task;Microsoft Corporation; Microsoft SQL Server v9; ? 2 004 Microsoft Corporation; All Rights Reserved;http://www.microsoft.com/sql/supp ort/default.asp;1". This happens when loading a task fails. End Error
I can't crack this problem and my Google-Fu is failing me. I am using DTEXEC from a stored procedure to set a global variable in an SSIS package and execute the SSIS package, but I am getting an error. I will include the SQL code and the error that I am getting:
Microsoft (R) SQL Server Execute Package Utility Version 9.00.1399.06 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. NULL Started: 3:17:02 PM Warning: 2008-03-13 15:17:02.76 Code: 0x80012017 Source: ProductionToDevelopment Description: The package path referenced an object that cannot be found: "Package.Variables[User:electMail].Properties[Value]". This occurs when an attempt is made to resolve a package path to an object that cannot be found. End Warning DTExec: Could not set Package.Variables[User:electMail].Properties[Value] value to 1. Started: 3:17:02 PM Finished: 3:17:02 PM Elapsed: 0.375 seconds NULL
All the examples I find over DTEXEC seem to follow what I am doing in the code and making variables in an SSIS package isn't rocket science, so I don't understand where I am going wrong.
I have seen people suggest indirect configuration as a solution, but when I set it up (using the environmental variable TEMP from the dropdown) it doesn't seem to help anything. I have used the exact path from the configuration wizard, though, so I'm pretty sure I have the path right.
HI, with a dataflow that has delay validation property = true, DTExec will not try to validate it when I call it with /validate option. Is there a way to see if the dataflow validate even though the delay validation property is set to true?
It was quite strange with dtexec.... The problem started with my package being scheduled under the SQL Agent. I have two packages... one with simple SQL tasks and another with complex loop,sql tasks and activex scripts. Both using the XML configuration files for those DB Connection strings, user names and passwords. First I tried to schedule the two packages under Sql agent using SSIS steps. Both failed and I found out that I should set the ProtectionLevel to non-default. So I set the protection level to 'DontSaveSensitive' and it works fine with the first package but the second package failed. After I tried many way (changing configuration files, setting and reinstalling the packages inside SQL DB etc..) I found a blog that I should try with CmdExe step in Sql agent scheduler rather than SSIS step. So I tried but still failing. the message said dtexec could not find the configuration xml file. Even I tried in the command prompt with the same command, it couldn't find the configuration. If I went into the directory where the configuration files are stored and run the command, it run fine. Seem like dtexec could not read the configuration from other directory. but still the sqlagent is failing... Somebody have a clue?
In my previous post here: https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1044739&SiteID=1 Michael Entin provides a number of responses to my questions regarding programatic execution of remote SSIS packages.
Having experienced some significant reliability problems with the Microsoft.SqlServer.Dts.Runtime components from an ASP.NET process (the page either times out, or inevitably just stops responding), I have been prototyping the DTExec command option which Michael suggests as being a better approach to remote programability.
So, off I've been prototyping this all day today...
I have a stored procedure that wraps a call to xp_cmdshell which takes the DTS (DTEXEC) params as a big long argument. This scenario would hopefully allow me to call the sproc from an ASP.NET application.
The proc is deployed to a SQL 2005 machine running SSIS (which I now understand is a REQUIREMENT for targetting SSIS "remotely"). The package targets a seperate SQL 2000 machine and includes two connection managers which are set to use SSPI. I use configuration option files to allow for configurable connection manager target/sources.
In this scenario, it does not seem that the DTEXEC command runs in the same context as the caller. and as a result, a peculiar account called MACHINENAME$ is used (where MachineName is literally the name of the SQL 2005 machine). The account authentication fails (obviously) when the package tries to establish a connection to any of the connection managers because MACHINENAME$ does not exist on the connection manager servers.
Based on the following excerpt from the MSDN doc on xp_cmdshell, it would seem that MACHINENAME$ is probably the LOCAL SYSTEM, which is the process tha the SQL Server Service is running under:
When xp_cmdshell is invoked by a user who is a member of the sysadmin fixed server role, xp_cmdshell will be executed under the security context in which the SQL Server service is running. When the user is not a member of the sysadmin group, xp_cmdshell will impersonate the SQL Server Agent proxy account, which is specified using xp_sqlagent_proxy_account. If the proxy account is not available, xp_cmdshell will fail. This is true only for Microsoft® Windows NT® 4.0 and Windows 2000. On Windows 9.x, there is no impersonation and xp_cmdshell is always executed under the security context of the Windows 9.x user who started SQL Server.
Obviously, settting the ENTIRE SQL Server service to run as a fixed account or even a domain account is probably not appropriate for client sites. Any opinion to the contrary is welcome.
In reading Kirk Haselden's walkthrough for setting up a SQL Agent Proxy, this seems incredibly involved. Before I go through this exercise, can anyone validate that this is the way to go for doing SSPI?
A work-around is to use SQL Server Auth for the connection managers and use configuration files to try to obfuscate these details, but my preference would be SSPI/Windows Integrated.
Hi, I have a package which has 2 file system tasks and 2 data flow tasks all in a for each loop container. if i execute the package from the development studio its executes fine but when i try to run it from the command prompt using the dtexec utility..it just runs upto the first data flow task and then it hangs unexpectedly. Any help on this would be really appreciated.
I have a legacy extraction ("E") .NET 1.1 application that is still going to be the driving force for our ETL process. We are going to be utilizing SSIS for "T" and "L". Now, the "E" phase is running on an application server where we have .NET 1.1 framework installed and working. The SSIS packages are running on a separate SQL Server. The problem here is - how do we call the SSIS package and be able to pass in the right parameters from this .NET app that runs on a separate box? We would like to use DTEXEC to call the remote SSIS packages through Integrated Security. The SSIS packages are stored as File System packages.
When I try to execute a package (in sql server) using DTEXEC I get the following error. The creator of the package is different from the executing user of the package. But I have also set EncryptionLevel FROM EncryptWithUserKey TO DontSaveSensitive (Which I assume should resolve this issue), re-imported the package to sql server, but the error remains the same. Any pointers?
The utility was unable to load the requested package. The package could not be loaded.
Microsoft (R) SQL Server Execute Package Utility Version 9.00.3042.00 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
Started: 3:18:56 PM
Could not load package " est1" because of error 0xC0014062.
Description: The LoadFromSQLServer method has encountered OLE DB error code 0x80040E14 (Only the owner of DTS Package 'test1' or a member of the sysadmin role may create new versions of it.). The SQL statement that was issued has failed.
A colleague of mine is having problems when trying to schedule package execution via a .bat file that executes a .dtsx on a sql server (not file system). The scheduling system that is employed by the company requires a .bat file to execute the package. The packages themselves move data from AS400 servers to SQL Servers. Occasionally (very randomly) when the scheduling system runs the statement in the bat files, the package prompts for password information (for connectivity).
We've tried a number of solutions to this, mostly on the "ProtectionLevel" property of the package itself. We did some research and it seems as though there are a few options.What is the best solution to eliminate this from happening? We certainly don't want to have people checking to make sure the packages don't prompt for passwords.
When I was trying to execute an SSIS package from DTExec using xp_cmdShell, it is giving an error message saying "unrecognized command,...". This error I am getting only in my Staging Environment. But at the same time, it is working fine with Development and Production servers.
I suspect the issue should be with config or access issues. So if anyone of you faced the same problem or if anyone have any solution, please share with me.
does anybody know if it is possible to use environment variables when calling dtexec utility?
I'd like to run packages stored on server's file system from directory that I've had specified in an environment variable called SSIS_PackagesPath.
Now, I'am trying to write dtexec command, where path to the actual SSIS package would be concatenation of environment variable (i. e. path to package directory) and name of package itself (written explicitly). Is this syntactically possible?
The reason behind is to be able to easily modify package storage directory for multiple scheduled jobs that run SSIS packages.
I receive the error below when running a package using dtexec. The package itself runs ok, however. That is, my data loads into the table.
All this package does is execute 3 separate Execute SQL tasks that are simple insert statements into a table.
There are NO script tasks or components in the package. So what is this weird error about?
Error: 2007-06-18 18:01:49.36 Code: 0xC0012024 Source: Script Task Description: The task "Script Task" cannot run on this edition of Integration Services. It requires a higher level edition. End Error Warning: 2007-06-18 18:01:49.36 Code: 0x80019002 Source: OnPostExecute Description: The Execution method succeeded, but the number of errors raised (2) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the M aximumErrorCount or fix the errors. End Warning
We've hit a weird problem that we can't resolve. We have a package using ODBC to extract from an AS400. When running the package through DTEXECUI, the package executes successfully. However, it chokes when executing through DTEXEC or as a SQL Agent job on our 64-bit machine. Seems like DTEXECUI is using the 32-bit ODBC driver while DTEXEC and SQL Agent is trying to access an non-existent 64 bit ODBC driver. We're using a DSN-less connection string (Driver={Client Access ODBC Driver (32-bit)};system=AS400;....) so that's not the issue. Anyone else seen this weird error? Any possible workarounds?
Currently, we are running a Master Package with sub-Packages that are executed as a result. We run multiple days by executing a .bat file of DTExec commands. For Example:
Date values are incremented for as many days as we want to run. The log gives progress information and the Started, Finished, Elapsed time for the the Master package.
We are interested in manipulating the script entries to get the Start, Finished, Elapsed time for the sub-Packages that are initiated by this script. I think that I could use the Reporting option:
Of course I can't find a good example to model the script. Is there anyone else using DTExec to get the run time statistics for each and every package? If so, can you forward that part of the script that accomplishes this task? BTW, we are going to implement run-time auditing to a table at some point but we are not there yet. Of course, my manager would like statistics now.
When the package runs, one of the first things it reports is that the configuration file, 'customersite.dtsconfig' cannot be found:
...
Description: The package is attempting to configure from the XML file "CustomerSite.dtsConfig".
...
Description: The configuration file "CustomerSite.dtsConfig" cannot be found. Check the directory and file name.
...
Description: Failed to load at least one of the configuration entries for the package. Check configurations entries and previous warnings to see descriptions of which configuration failed.
The package hapilly executes (and, somehow does grab the appropriate values from config (in this case, it is the SQL Login passwords).
Can anyone provide some insight into this or is this a bug that should be ignored?
I have a DTS Package that I am running from a command line via .bat file. Does anyone know if there is a command to have the command window minimized or running in the background? I used the /Rep N command but that still leaves the window open until the package has executed.
I've working a while, not at full time, but seeking the solution...Here what I want to do and what I've done till now:
I want to build a sql job, so I can run a package (witch loads 2 excel sheets into 2 tables) passing "dynamic" parameters, like convert(varchar,getdate(),112) in the format YYYYMMDD. From what I've found, I can do this with an Stored Procedure, which first set this variable, building a statement so it can be run by xp_cmdshell. For example:
And this statement runs with no problem in the SP until it reaches the step of loading the Excel Sheets into tables. Here it gives an error. It's about the JET driver. From what I've read in the forum and from the output error the problem seems to be that this statement executes the dtexec.exe 64bits, even the suggestion to change the property Run64BitRuntime set to False, it stills running from the dtexec.exe 64bits.
So, I changed the statement to point to dtexec.exe 32bits:
But executing this statement it does not even run. The errors are: 'C:Program' is not recognized as an internal or external command operable program or batch file
This was very wird to me, because this was very mentioned by the moderators.
So, I copy this same statement and created a job with a step type of "Operating System (CmdExec)" and it runs great...With no problem with the extraction from excel source.
Now my questions are: 1. Why the step job CmdExec recognizes the path of dtexec.exe 32bits ('C:Program Files (x86)Microsoft SQL Server90DTSBinnDTExec.exe ), but trying to run with xp_cmdshell it gives the error mencioned above. And if there is another way to set dtexec.exe 32bits besides this way?
2. If I cannot run it throught xp_cmdshell, how could I pass a parameter like convert(varchar,getdate(),112) in the format YYYYMMDD instead of the static parameter 20070101.
Hi, when I try to run my package with dtexec.exe, it starts fine but in the process it package calles another subpackage and at the time there is big delay before start processing the subpackage. the subpackage has been setup so executionoutofprocess pramater has been set to true. any idea what migth be the problem. I have to metion even when I run this with in the visual studio still I have a big delay.
I have created a SSIS package that reads 500 text files splits them into 4 raw files then reads them again and writes then to 4 database tables different Tables.
The reason form this is that my raw files have multiple types of records in them and it is only 1 Coolum. I split this out into the different types of records and load whole rows into the database.
End up begin rows in the T6 Table 1000178 18148821-00 40204043 1 EX201036259NZ 0000304862 1511158 18084863-00 40617044 1 EX201033969NZ 0000302981
T5 Table gets a new record 1511313 18126485-00 2006032510230300 EX201033399NZ
and T1 Table get a record 18148821-00
Anyway all this works find but I find that the DTExec process work fine until it has used up all the memory in the laptop in general it take 400megs to run this SSIS. I'm wondering am I missing something like don't run in a transaction. I know in the old DTS you could commit on each package and how do I turn all logging off eg what you see in the DOS box (can I do this?) would love some help on this and if anyone want a copy of this ssis package ie your trying to do the same then I'm more than happy to email it.
I HAVE an SSIS Pkg that gets data from lotusnotes into SQLS ERVER 2005. This SSIS Pkg works just fine, when I run it from manually from Visual studio environment. However, when I run this as a dtsexec from command line it fails with the foll error" The product level is insufficient for component "DataReader Source(1). The dtexec command I use is :
I have noticed a strange behaviour when running some of my packages with dtexec. The packages use EventHandlers to log information to a database using the Execute SQL Task with the query stored in a variable. This variable is further part of the package configuration, so that I can change the query without changing the package itself. Now, this all works fine, until I made a typo in the query causing the syntax to be invalid, ie changing SELECT to SELCET. Now, one would expect the package to fail, and it does, if I run it through the debugger in Visual Studio, but when I run it using dtexec it just hangs and I have to kill the process using the Task Manager.
Peculiarly, I tried doing the same thing with a task that was not contained in an EventHandler, and then the package fails as expected, both when running it in the debugger and using dtexec. This is not a major problem, but what I am afraid of is that one day the database server will be down and cause an error in the Execute SQL Task in the EventHandler, causing dtexec to hang indefinitely. Has anyone else had problems like these?
