SSIS Skip a container if table is empty - ssis

I have a package in SSIS with two sequence containers.
I want to create a logic that if one table on SQL is empty the SSIS should not run the first container and skip to second container._
How is the best approach to do that?
Thanks

You could begin with an execute SQL task to count the rows in the table. Then direct the flow based on the result.
Start by creating a variable to save the results to.
Use Execute SQL Task to get count of records in the table. Set ResultSet to Single Row and create your query to count rows in the table. Save the Result Set to the variable you created.
Select count (*) FROM [YourTable]
Use the Precedence Constraint to direct the flow to Task One or Task Two depending on the results of the TableCount.

Put B in it's own package.
In new package add Exec SQL Task like Don suggests and lead it to:
Container A connected to exec package (program to run B's package). And connect Exec SQL to Container A with precedence like Don did.
Also connect to exec package (that runs B) and connect like Don did with precedence constraint.
You package will flow down one side. A-B if empty. Or straight to B if not empty.
This is treating Container B as a method with this logic.
if(sqlCount==0)
{
RunA();
RunB();
}
else
{
RunB();
}

Related

SSIS: Order by Column Full Result Set for Execute SQL Task

I have an Execute SQL Task placed before a Foreach Loop Container so that for every row returned by the Full Result Set a Script Tasks Inserts this into an Excel row.
However, on one particular column I would like to sort the Full Result Set in ASC order before iterating though each row so that I can have the Full Result Set in a particular order.
I've tried using the Order By Clause in the SQL Script inside the Execute SQL Task but it doesn't sort as expected.
Is there a way I can sort the query results in the Result Set object in order by a single column before passing onto another process i.e. the Script Task?
As it seems you've learned, you cannot use ORDER BY in an Execute SQL task. Instead, use a Sort task to order the data after it's been loaded from the Execute SQL task.
Using the Sort Transformation Editor you can choose what columns are sorted and how you want to view them, in addition to determining "pass-through" columns or removing them from the Data Flow.
This image uses an OLE DB Source, but the actual effect of the Sort task is the same if you use an Execute SQL task
This does pose the question: Why are use using an execute SQL Task? An OLE DB source would be much easier and more flexible to use. Consider rewriting your SSIS package to use OLE DB data sources when possible.

Temp Table created in one Execute SQL Task is not available in another Execute SQL Task in SSIS

I created one Global Temp Table in one Execute SQL Task and the inserted some records into that table. While calling the result in another Execute SQL Task it is saying invalid object name.
Please suggest
Thanks
Sasi
If you put both Execute SQL Tasks in the same Sequence Container and set the TransactionOption to Required on the Sequence Container you can access the global temp table from the second Execute SQL Task. You can leave the TransactionOption at the default of Supported for both Execute SQL Tasks, as they will join the transaction of the parent Sequence Container.
The lifespan of a temp table is constricted to the Task it is associated with, so you wont be able to access it like this.
You'll have to create a more permanent solution, or handle it in a way like userfl89 above stated.
It can be done by using Retain same connection = true in Connection Manager
thanks
Sasi

State/Execution ID in SSIS

I have a problem with multiple executions of the same SSIS package.
I would like to allow parallel executions each of which handles a subset of data.
So far, I am thinking of using some state variable, but I don't know where to store it.
One option is to use keep the connection open and use temp tables to coordinate the task load. However, temptables cause lots of compilation issues, and they are not maintable.
Are there any other ways to identify the current execution id of the package or scope of execution? I have found no state (either in memory or stored elsewhere) in SSIS so far which I can use to partition/isolate each execution.
So based on my comments above you can try this. I dont know it is quite what your looking for, but maybe it can give you a hint to get further.
I am calling the example with workflowid 1. This is what i mean you can change in your SQL Job agent steps, and then change the parameter on each step, so fx you could add 2 steps executing workflowid 1 and workflowid 4. Then it will only run that sequence container where the constraint is success.
Create a package variable
Create your package flow
Edit your SQL Task Get WorkflowID
Add Parametermapping to your package variable
Get the resultset into local variable called WorkflowIDrun
Make your precedence constraints so it only allows one id to pass through
Notice: You could add parentworkflowid's so that you can diverse your flow inside the sequence container if you need some of the same logic
End result when package is run with workflowid 1
Create a new SQL Job in your agent. Add the needed steps Notice; I Created two steps for workflowid 1 and 2. Truncate and delete
I then edit my step and correct the variable with the right value. This will be workflowid 1 for truncate and workflowid 2 for delete
This could of cause also be in another job you do it, that depends on your needs.

Loading data from multiple db to another server using SSIS

I have used SSIS package to move table columns and data from one database to another database.
SERVER A, Database A, Table A
SERVER B, Database B, Table B (but only with selected columns from Table A)
I have used Data flow task with OLEDB source and OLEDB destinations. Derived columns as well to create new date columns in Table B in SERVER B. I need to do this automatically to load 50 databases Table A from SERVER A to Table B (with selected columns from Table A) into SERVER B using SQL Job.
Please can anyone suggest me how to nake database load as a loop.
Thanks.
I'm going to show you how to grab ALL the columns from the 50 tables of DatabaseA and load them into DatabaseB using SSIS. That package will look something like this.
I'll explain the logic flow.
The first Execute SQL task is going to get a list of tables from the Information Schema.
TABLE_SCHEMA|TABLE_NAME
MySchemaA |MyTableA1
MySchemaA |MyTableA2
We're going to take that list and save it as a ResultSet variable. Once saved, we can loop over the ResultSet using a Foreach Loop ADO Enumerator task. For each loop we're going to map values from one row into the TABLE_SCHEMA and TABLE_NAME SSIS variables. Then, we will use those values in dynamic SQL statement. The second Execute SQL task is getting it's command from the SQLStatement variable. We've set that variable by the following Expression ...
"SELECT * INTO DatabaseB." + #[User::TABLE_SCHEMA] + "." + #[User::TABLE_NAME] +" FROM DatabaseA."+ #[User::TABLE_SCHEMA] + "." + #[User::TABLE_NAME]
So for each loop, the schema and table name is injected into the SQL statement, and the table is SELECT * INTO a destination table of the same name.
Look here and here for more detailed examples about how to use the Foreach Loop ADO enumerator to map the variables.
Now...
I did read that you wanted
with selected columns from Table A
If you're lucky enough to need the exact same columnset from each of your 50 tables in DatabaseA then, just change the * in the query above to [ColumnA],[ColumnB],[ColumnC]. If you happen to need a different columnset for each table, well... that may be problematic. You'd need to create a list of TABLE_NAME | ColumnSet and integrate that into your looping... and well.. thats starting to sound like a lot of work! You could probably do the 50 by hand before you could code it. Hope this helps!
This means that the query is predictable as well as the destination table names.
You can make a loop through the tables you need either by putting their names in a table or getting them from INFORMATION_SCHEMA.
Inside this loop container, you can construct the source queries from the INFORMATION_SCHEMA then make the source component in the Data Flow use expression to use your query.

How to create a new column with an SQL function in Pentaho PDI work-flow?

I have one sql function, let's say theFunction(item_id). It takes an item id and computes one value as its return. I read one table from the DB and I suppose to compute a new value to append for each row by this function given the item_id particular to taht row. Which desing block would do this form me with the following SQL (if not wrong).
select thsFunction(item_id);
I assume that the block gives me item_id of each row as a variable.
You can use another table input step, and have it accept fields from previous steps and execute for every row (both config options are at the bottom of the step's window).
Beware that this is a rather slow implementation. Each query is executed separately and as such each row requires a round trip to the database.
Alternatively, you can use the Row SQL Script. I believe it allows you to pass all SQL statements in a single trip to the database.
An SQL function is probably much more efficient to run in the database, for all rows at once, in stead of making a separate call into the database from PDI for each row to execute the function. So if performance is at all a relevant concern, I'd suggest a whole different strategy:
Write your rows to a table in the database. End your transformation here.
On the job level, first execute your transformation from above, then execute the function in an "Execute SQL script..." component, giving it an SQL command somewhat like "UPDATE my_temp_table set target_col = theFunction(item_id)".
Continue your job with the remaining steps in a new transformation, starting from that table as input.
This of course presupposes that you don't have too many other threads going on, but if your transofrmation is simple and linear -- or at least if it can be made single-linear at this particular step -- it may be possible to split it up into two parts before and after this SQL call.