I have a simple task that I would like to manage through a SSIS package but do not know how to accomplish it. I need to perform the following tasks:
1. update a sql server table (ecwcust) and set the ftpstatus column to 'P' when the column's value is 'E'.
update ecwcust set ftpstatus = 'P' where ftpstatus = 'E'
2. declare a variable and set the variable to the number of rows that have a ftpstatus equal to 'P'
declare @newcustomercount int
select @newcustomercount = count(*) from ecwcust where ftpstatus = 'P'
3. if @newcustomercount > 0, copy all of the rows from ecwcust where ftpstatus = 'P' to an excel spreadsheet.
4. send an email to an email recipient with the excel spreadsheet as an attachment.
5. delete the excel spreadsheet.
I do not know how to create the variable @newcustomercount so that I can determine whether or not to create the excel spreadsheet and copy the records to it.
I have read all the online help and stuff that MS has but I can't understand the instructions. Please point me to some instructions that are understandable.
We're just in the middle of performing our first release of SSIS packages through various environments.
The way we are set up currently is the developer will check the package(s) and related config files out of source control, develop on their own machine and check everything in again. Then we deploy the packages consecutively to the Dev, Tst and Prd servers.
We are going down the path of using one environment variable for every config file. some packages share config files (e.g. we've only one config file for each database or ftp connection etc.) and some config files are package specific (error log file connections and success/failure e-mail sources etc.).
What we want ideally is a script that we can check into source control that will create the environment variables on a server at deployment. The "set" command at the command line can be used to change the value of an environment variable, or to create a session-specific variable, but not to create environment variables.
So far the only method that we're using is manually typing in the environment variable names via control panel and copying and pasting the paths into the value fields. Given that we're deploying potentially hundreds of config files, it's obvious that this new-fangled GUI point-and-click and copy-and-paste method of deployment is absolutely foolproof and totaly not prone to any error whatsoever.
Please tell me there's a way to create and set environment variables without going through control panel. running a script or something to do it automatically will: Ensure that each environment is set up accurately and identically, eliminating human error. Ensure that when a developer checks out a package to their local drive, although they may have to change the variable values, he can at least create the relevant variables without having to type them in. Enable efficient migration to another new server (for example during Disaster Recovery).
Can anyone point me to some example scripts at all?
I've run into a problem with SSIS packages wherein tasks that write or copy files, or create or delete directories, quit execution without any hint of an error nor a failure message, when called from an ASP.NET 2.0 application running on any other machine than the one where the package was created from. By all indications it appeared to be an identity/permissions problem.
Our application involves a separate web server and database server. Both have SQL Server 2005 installed, but the application server originally only had Integration services. The packages are file system-deployed on the application server, and are called using Microsoft.SqlServer.Dts.Runtime methods. For all packages that involve file system tasks, the above problem occurs.
When the above packages are run using the command prompt (either DTEXEC or DTEXECUI) the packages execute just fine. This is expected since we are using an administrative account. However when a ShellExecute of the same command is called from ASP.NET, the same problem occurs.
I've tried giving administrative permissions to the ASPNET worker process user to no avail.
I have likewise attempted to use the SQL Server Agent job approach but that approach might not be acceptable for our clients since it means installing SQL Server 2005 Database services on the application server.
I have read the relevant threads in this forum, namely http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1044739&SiteID=1 and http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=927084&SiteID=1 but failed to find any solution appropriate for our set up.
We manage some SSIS servers, which has only SSIS and SSIS tools installed on them and not the sql server DB.
SSIS packages and configuration files are deployed on a NAS. We run the SSIS packages through DTEXEC by logging in to the server.
We want to allow developers to run their packages on their own on the server, but at the same time we dont want to give them physical access on the server i.e we do not want to add them into RDP users list on server properties. We want them to allow running their packages remotely on the server.
One way We could think of is by using powershell remoting and we are working on that. But is there any other way or any tool already present for the same.
I'm working on a solution in Visual Studio that has 3 SSIS packages, and now I want to add a 4th that needs access to variables defined in one of the other packages. How can I do that?
hi, Is there any way to export a set of variables from each other package?? Issues comes when you have to built five packages which share the same variables. It's very tedious and hard to re-write them every time... Thanks for your time,
When executing a package from Business Intelligence Studio variables are well passed between packages but when same is done using dtexec utility variables don't get passed between packages. Does anyone have any idea why this could be happening and what would be possible solutions? Thanks in advance!
It is pretty easy to create the package configuration to the shared, never-changing path to XML file. But to get this to work, I have to add a bunch of package variables which are driven from the configuration. I then use expressions to compute actual paths to source files and packages.
This business of copying a block of variables from one package to another is extremely tedious, and at least to me, something of a maintenance issue. I have found if I get ahead of myself and forget to create the variables first, then Visual Studio is NOT very forgiving, and will complain repeatedly just prior to crashing without the offer to save anything. If I add a new variable, it is like an easter egg hunt. This does NOT feel very single point of maintenance when variables must be used in this way to really effectively apply configuration, and it is so tedious and error prone, and unforgiving. I seem to spend a great percentage of time copying the names and datatypes and values of variables ONE AT A TIME. What is that all about?
I hear people telling the praises of configurations, but I must be missing something.
With DTS I used a system where global scope settings were "injected" into packages as they ran, and I never had to worry about anything, and it was damn hard to goof it.
Please someone, evangelize me!! Are people bypassing VS and using NOTEPAD on the packages or something like that to save time?
1) Create a global variable. 2) assign a value to the variable using an SQL Task. (For this all I want to do is assign a maximum value from a column in my table)
3) use the variable in a Data flow task (using SQL to get my source data)
I know this must be very simple but I am new to SSIS and I am struggling to achieve this task.
I'm trying to use a variable in a OLEDB Command, but i can't do it. What i want to do is: Step 1: Count the number of rows of a table (using count rows transofrmation) and save it to a variable 'var1'. Step2: Insert some rows on this table. Step 3: Count again the number of rows and save it on another variable 'var2'. Step 4: Ina OLEDB Command , get the inserted records in step 2 to manipulate them on other tables...
Something like that: select top (@var2 - @var1) * from table order by desc
¿Can i use local or global variables from an OLEDB Command transformation object?
I have created SSIS (.dtsx) files and have stored in different servers. Now my query is I want to move all dtsx files from filesystem to Sqlserver2005 database how should i do it.
I need to create the ssis package in business intelligence developement studio i am need to sqlserver 2005.When i opened the BID studio i am not able to see the integration services packages type.. Please help the steps to design the package.
I have experience of using the 2000 in dts designer mode.
I upgraded to Microsoft SQL Server 2005 Service Pack 2 and now when I run the master SSIS package( that has several packages in it), all the packages run twice.
After removing SP2, they work fine. Any ideas how to make this work with SP2?
I am writing a vb application that is supposed to let the users set the connection string for the datasources in the package. After new connection strings are entered the application is supposed to run 8 packages in a certain order, but I haven't been able to set a new connection string successfully. Is there a way to programmatically modify the connection string of a package's datasource? (the packages are moving data from a D3 database to sql server 2005)
Here is what I have tried so far:
A. Dim pkgLocation As String Dim app As Application = New Application() pkgLocation = "c:Package1.dtsx" Dim pkg As Package = app.LoadPackage(pkgLocation, Nothing) Dim myConns As Connections = pkg.Connections
MessageBox.Show(myConns(0).ID.ToString) Dim myConnMgr As ConnectionManager = myConns(0) Dim connProperties As DtsProperties = myConnMgr.Properties
I am connecting to a DB2 mainframe to pull data into SQL 2005. Very simple import. SSIS package works fine on 32 bit. However, once deployed to the 64 bit machine, I get "invalid product license" on the Acquire Connection method.
I've worked with IBM support. I have the correct version of the DB2 Connect client installed. The license is there and in the right place. I can connect to the mainframe from the 64 bit server using the DB2 client tools. I just can't seem to execute the package from Integration Services or run a job in SQL Server that executes the package.
According to BOL, the package should automatically detect the 64 client I installed. It and the 32 bit client I developed with share the same name/id.
I read in Kirk Haselden's book "Microsoft SQL Server 2005 Integration Services" that if SQL Serfver 2005 and 2000 are installed on the same machine as seperate instances then you can view the SQL Server 2000 DTS packages in 2005 Management Studio under the Management tree, Legacy, Data Transformation Services node.
But in my case, I am not able to see DTS packages in Management Studio. Is there a property or a setting that we need to configure for that?
I have a process which connects to a SQL server remotely, runs some code, creates a temporary table with an output. I want to be able to select the results of this table into XML (not a problem), put the results into a variable in SSIS, and put the variable results into a SQL table a different SQL Instance. Doing it this way removes the footprint of needing a normal table on the source SQL Server.
Before in DTS, I used to using ActiveX scripts to setup simple Global Variables that would later be used by the package, let's say a give state or a date. I'm completely lost how to do the same in SSIS, can someone give me a hand? I'm not sure what component to use and how to read this variable.
Hello, I am wondering what is the difference between assigning variables in the following two ways.1. Dim myVar11 As Variables Dts.VariableDispenser.LockOneForWrite("LoopCount", myVar11) myVar11("LoopCount").Value = 32. Dts.Variables("LoopCount").Value = 3I received this error when processing SSIS Package.
Error: A deadlock was detected while trying to lock variables "User::LoopCount" for read/write access. A lock cannot be acquired after 16 attempts. The locks timed out.
I have a SSIS package that was migrated from DTS 2000. It had a variable that I passed to the DTS package when executing. Now when I try executing the SSIS package with the variable, I get the following error: The package path referenced an object that cannot be found: "package.variables[user::SnapShotDate].value". This occurs when an attempt is made to resolve a package path to an object that cannot be found.
From everything that I can find, I am passing the variable correctly. If I look at the package within BIDS, my variable is listed under the variable window & it is scoped for the package. Any ideas on what I might be missing here? This is my first SSIS package that contains a variable.
I have a script which grabs data from a source server. The problem is I have over 50 source servers, so I have to make a script for each one.. EXACTLY the same code but different linked server address.
So I was wondering if i can put the server name into a variable so I only need to make one script. Is that possible?
I have a very simple package which consists of a SQL Task component and a Script Task.
The SQL Task retrieves a single value from 1 row table in one of my database and assigns that value to a variable. The Script task simply outputs the value of the variable in to a message box. I know, it's all simple stuff (I am trying to master SSIS )
The problem I have is that when I change the value of the column in my table, the value of the variable is not changing when I re-run my package. It seems to be the same value every time.
in my package, I have serveral data flow sources using a same date value. the date value is different everytime the package is executed. (e.g. the date is two weeks before the execution date) I want to create something in my package which can dynamically calculate the datetime and pass it to all the data flow sources.
I thought variable is a good choice. but i don't know how to make the value dynamic.
I need to pass a value to a package level variable in an SSIS package from a SQL Agent job. If I use dtexecui the syntax for passing the variable in the Property Path is
Package.Variables[User::MyVar].Properties[Value]
and the package runs fine.
When I use this syntax, or any similar format I can think of, in SQL Agent, my job fails. In SQL Agent you put this in the Property Path on the Set Values tab of the Step that runs the package. If I remove passing in the variable my package runs fine.
BOL says use the format Package<container name>.<property name> but I can find no examples. Can anyone provide a working sample to make this work?
I'm still new to SSIS packages and I'm NOT a developer. I am in the process of doing preliminary/prepatory work for migrating our SQL 2000 platforms to SQL 2005.
I am having a REAL headache with migrating/moving DTS packages from SQL 2000 to SQL 2005. Here are things that I know :
1. I know that some packages cannot be migrated due to ActiveX issues and other issues. Fine.
2. I know that I can install DTS backwards compatibility components on the server in order to be able to edit the DTS packages using a SQL 2000 DTS GUI. Fine.
3. I know that I can use the Migration wizard to migrate packages (and that some of them can't be migrated this way). Fine.
Here's what I don't know/or am conjecturing:
1. In a clustered environment, I have to edit the <%Install Path%>/90/DTS/Bin/MsDtsSrvr.ini.xml file to set the <ServerName> property to the Virtual Server name. Correct? Why can't M$ do this for me?
2. Do I HAVE to export the SSIS package to a .DTSX file in order to be able to edit it with Visual Studio? Is there ANY way around this?
3. If I am running in a clustered environment and I use the File System for storing packages, then the pacakges must be stored on a shared volume, right?
4. I did not find SQL Server Integration services on the B- (Passive) node. Do I have to install it separately onto the B server (much like having to install the Client Tools)?
If anyone has some guidance or tips on running SSIS in this brave, new, wonderful world, I would sure appreciate it.
And yes, I am going to go out right now and order a new book on SSIS.
