I am trying to find a way to be able to pass a couple variables into a Windows Task Scheduler task and I can't find the answer anywhere. I'm not even sure it is possible.
The purpose of this task will be to run a batch file, which will call dtexec to run a SSIS package against my SQL server. I need to remote execute the SSIS package and found that this could be done via PsExec on the remote server, calling a scheduled task on the SQL box. I have gotten this method to work well on other packages.
However, I have a task which requires a StartDate and an EndDate for the package. I can explicitly put the dates into the Add Arguments portion of the scheduled task and it runs fine. I need this argument to be dynamic so when some one requests this data, they enter the dates, and it runs using those dates.
I'm expecting I need to put something in the Add arguments field which will allow this to happen, but I can't find the syntax anywhere. As well, how can I set these variables via command line to set them.
I expect the command to look like
C:\PsTools\psexec \SQLBOX schtasks /run /tn SCHEDTASKNAME /tr input variable syntax
Any help or a push in the right direction would be greatly appreciated.
If you want to schedule the SSIS package execution you should create A SQL Server Agent JOB.
YOu will be able to pass variables values to the package using
SET "\Package.Variables[YOUR_VARIABLE_NAME].Value";"\"VARIABLE_VALUE\""
hope this help
Related
I have a simple package to produce a csv file from a query and update a 'lastrun' time on a table. This was written in 2014, running on a test server with 2014. The agent job that runs it simply executes it via an SSIS Package step. No other steps are involved.
However, I get the above error message in the agent log file. The job will successfully execute and produce a file, but ONLY after either restarting the agent service or changing the properties on the job (after refreshing the job list in SSMS). And because it seemingly deletes itself during execution, there is no job history to view, and then the schedule will stop repeating.
I can't find anything like this on here, and wondered if anyone has ever seen this, or has any ideas?
Thanks.
Note (update) : All other agent jobs run ok on the same server. The only difference with this one is that it's the only one that is calling an SSIS package.
It could be when you try to restore the same database (subscriber/distribution) as another database name, it will clear the job automatically.
I have created an SSIS solution (using SQL SERVER 2012) to extract data from ServiceNow. All the tasks are wrapped in a Sequence Container. When I right click on the Sequence Container and click Execute Task the package behaves as expected. It extracts the data from ServiceNow and performs the rest of the etl. However when I click Execute Package from the Solution Explorer the package successfully completes but it does not extract any data from Service Now.
I have played around with settings and different package designs but with no change in behavior. I can execute with true success at the task level but not the package level. This behavior is even apparent after deployment. I can execute with success from the SSISDB but with no data extraction. When I hook the deployed package to a job I still get no data extraction.
My thinking it has to be some kind of bug or hidden proxy setting because I only get true success (with data extraction) when I manually execute at the task level - i.e. the Sequence Container.
I have been using SSIS for a couple years now and have not come across this issue. Hopefully someone can help or have some ideas.
Got it. I needed a break and to think about this clearly. I needed to update the Package Property Delay Validation from False to True. That solved the issue. I guess the SSIS engine needed the extra time to validate the variable and expressions set up within the package.
The starting item in my Control Flow needs to be something that will check what time it is and set a variable. Is there an item in the Control flow items that can do this?
Access your system variables. System::StartTime will be when the package started execution. If there is a significant amount of time between start of execution and the element that needs to evaluate the current time, you can look at the ContainerStartTime. If that isn't precise enough for you, look at using a script task.
SQL Server 2005 Run a stored procedure via SSIS using GETDATE() as a Parameter
Morning
I've been reading "SQL Server 2008 Integration Services Problem - Design - Solution". It outlines a way of logging variable changes which I'm trying to replicate in SQL 2005.
Create variables e.g. PackageId, RecordsAffected. - Set Raise ChangeEvent to true.
Create a string variable g.g. strVariableValue. - Set Raise ChangeEvent to false.
On the package event handler: OnVariableValueChanged add a script task "SCR Convert value to string".
Add ReadOnlyVariables: System::VariableValue
Add ReadWriteVariables: User::strVariableValue
In the script, set a local variable to System::VariableValue.value.tostring
Set the variable User::strVariableValue to the local variable
Add an "Execute SQL Task" component "SQL Log Variable Value Changed" calling a SP with no resultsets.
Set parameter mapping to User::PackageId, System::VariableName, User::strVariableValue
When this is run, I get a deadlock on User::PackageID
Error: 0xC001405B at SQL Log Variable Value Changed: A deadlock was detected while trying to lock variable "User::_PackageID" for read access. A lock could not be acquired after 16 attempts and timed out.
The script step succeeds but the Execute SQL task fails. I'm using Visual Studio 2005 Version 8.0.50727.42, Microsoft SQL Server Integration Services Designer Version 9.00.4035.00 and BIDSHelper Version 1.4.3.0.
Any ideas?
Eureka!
I had the same problem and led to a few deadend posts, then I discovered the root.
I had the framework working just fine and wanted to force some info to be logged.
So I changed the value of the framework variable "strVariableValue" and this caused the deadlock with the change event task.
I fixed by creating my own variable "strLogMe" and putting whatever I wanted to log.
Moral: don't touch the framework variables
Did you use the code sample from the book? All the files are available on the Wiley website for free. The code sample includes a SSIS package, sql scripts, and VB code for the script. If this doesn't work for you, then let me know since one of my team members found a way to log variable changes that was different from this methodology.
I was getting this error ("a deadlock was detected" etc), suddenly, which seemed to coincide with I.T. having done a Microsoft Windows patch on the server. There were packages which were using script tasks, with read-only and/or read-write variables in the SSIS UI. Even though it seemed to have been an environmental issue (because the packages had worked for months, then suddenly stopped working, even though I hadn't changed any code), I thought, well (as I had seen from various blog posts from years gone by), there were instances of companies doing server patches, then having their SSIS packages break; and the blogs seemed to say, change the way you're locking the variables, don't reference them in the UI; instead, lock them explicitly in code. So I tried the same thing. It didn't fix it.
It turns out some individual had removed the permissions of the user under whose identity the packages run, from the AD group; those permissions were required because it was trying to copy a file from a directory which required read permissions on the directory. These packages are typically called by a SQL agent job using a proxy identity. When the package was executed manually from SSMS, it worked. But when it was run by calling the SQL agent job, it failed.
The bottom line is, it was just coincidence that the packages started failing around the time of the Windows update. But the other (main) point is, if your package is trying to access a file on the network, and the identity (or proxy identity) under which that package runs does not have permissions to the source or target directory, then your package could fail and the problem could manifest itself in this cryptic way, where it looks like a variable deadlock issue, but it's actually a file share permissions issue. I only wasted a day on this, but... maybe this will be useful to somebody in the future.
I'm trying to programmatically add an Execute SQL task from within a script task of my SSIS package. I know that the Microsoft.SqlServer.Dts.Runtime.Package class has an Executables collection which I can add my new task to but how to I get a reference to the package Im inside of?
It is not possible, SSIS does not support self-modifying packages.
To prevent any attempts of doing what you are trying to do, the task code does not have access to the package API, so you can't obtain reference to Package object from a task. But even if you find a way to curcumvent this - the results are not predictable, as package is not allowed to modify itself at runtime.
If you could describe what you really want to achieve (rather than asking for particular way to do it) - someone might find a way to do it. Maybe you can use child package - it is OK to modify child package before its execution, or maybe it is enough to just change some variables that are used by Execute SQL task later in this package?
As Michael says above, it's not possible to do what you are asking. However, you may be able to find a solution by setting variables at runtime, or by enabling or disabling certain packages at runtime using dtexec. For example:
dtexec /f e:\ssis\master.dtsx /set \Package\YourPackageName.Disable;True