exec stored procedure

Hi,

I'm new to SSIS and SQL Server 2005 and this is now driving me very mad!!

I have an OLE DB Command in my data flow task that I want to update a table with. I have looked round this forum and on Google and just can not find a solution or what I am doing wrong. So any help would be great!

The ole db command calls a stored procedure with two input variables:

exec stp_updedgrsholds status, temp_cr_num

from debugging the ssis it says it has updated 4 rows and also from doing a data view, the data it is updating seems all correct.

but nothing gets updated in the database.

If I call the stored procedure the following way

exec stp_updedgrsholds 'C', 87

It updates fine! I have tried a number of different way with @. symbols and assignment p_status = @.status

but nothing seems to work.

Any ideas are much appreciated.

Ninder Bassi

If you call the stored proedure and it succeeds, but then data is not updated, have you confused the target of your connections?

What is a data view?

How is the stored procedure being called, what task or component?

What are status and tep_cr_num, that syntax does not make sense. When passing in parameters with OLE-DB, it is usual to use ? as the placeholder, then in the task or component UI, use the "Parameters" screen to map a SSIS variable to the placeholder.

|||

told you i was new to it all!!

the stored procedure is being called from the ole-db command

i have tried the ?'s now and get the following error after mapping them in the "column mappings" tab.

[OLE DB Commmand [3310]]: Columns cannot convert between unicode and non-unicode string data types.

many thanks for the help.

|||

ot it. did a data conversion and the parameters mapped fine. and all worked fine.

many thanks DarrenSQLIS i just needed that nudge in the right direction.

Exec Stored Procedure

Hi,

Hope someone can help me out here - I'm trying to design a data flow in SSIS which relies in part on a stored procedure as a data source - I'm running it through OLE DB.

Sure Exec MystoredProc works fine on preview and on parsing, but it refuses to acknowledge any of the columns, when I go to Edit-->Columns everything is blank.

Just out of interest - the reason I am using a stored procedure is because I dump the data into a temp table and then amend a couple of the columns to make it the same as my other database (for example where len(field) = 6 then field = '0000' + field).

Possibly I'm better off taking the raw data through the OLE connection and then transforming it through SSIS, but my gut feeling is I should minimise what I'm dumping into SSIS and offload the processing onto the local DB. Any thoughts?

Thanks

Rich

To do exactly what you need - use OLE DB Command Transformation - part of the data flow. Use ? for column parameters.

IMHO: There are two schools that define how to do this: ETL and ELT. What you are trying to do is ETL - the disadvantage of this is if you have a lot of rows - this method will execute the SP as many times - this is performance impact.

In ELT approach you load the data with Bulk Insert and then apply a SQL statement or another set of trasnformations to load the target.

|||

This is helpful Dima, particularly your comments on ETL & ELT, but it doesn't quite hit the spot in terms of what I want to achieve.

Maybe because I'm being thick. My fundamental problem is that my OLE DB connector will not return any column names. When I add the OLE DB transform it just whinges that I don't have any column names.

As I see it your solution will allow me to connect two tables through OLE DB connectors, drag them into OLEDB transform, do my changes, and then output columns - are you saying that there is no way for SSIS to derive column names from a stored procedure without iterating through the recordset one record at a time? This sounds totally useless, but completely feasible.....

As I have already done the work I really just want to get the stored procedure results into SSIS via my OLE DB source, if you are saying I have to start again then I will, but in truth if using this technology means I have to rewrite all my existing SP code as data flows then it is about as much use to me as a chocolate teapot, I have years of work wrapped up in stored procedures and also I would prefer to distribute the load, I want as few transformations as possible in SSIS, the primary use for the server is reporting, not data transforms, we have plenty of spare DB capacity across the planet and bandwidth is at a premium so thinking about what you've said I think we are better off restricting the recordset at source.

|||

I feel your pain :)

What is your OLE DB source? a DB or file? If you have weird source - you may want to see if there is newer ODBC or OLE DB driver out there.

For the existing SP's:

If you already have SP's that accept fields and insert them into a table, row by row - you should be able to reuse them. You can map source fields to the OLE DB command parameters.

|||

Hi Dima,

Hmm... Just to let you know I worked round the problem after reading your answers - my stored procedures now delete and create tables, which I then query, not very efficient but hey, it works, and I can schedule them monthly just before my reports need doing. Anyway, it is only MS SQL I have a problem with, all my Oracle stuff is based on views anyway and it works fine (?)

I tried using the ADO.NET source instead but this is even more messed up.

Path of least resistance until Microsoft sort this mess out, I think.

Thanks for your help

Rich

|||I guess you are doing something wrong... You can call a SP in an OLEDB datasource (described here: http://msdn2.microsoft.com/en-us/library/ms141696.aspx). I tried that with Adventureworks using the SP they suggested for testing with parameters (just entered a one as value for each ?). It returned the metadata correctly...|||I've had similar problems where SSIS doesn't correctly identify columns if you have anything more than a vanilla SELECT statement in the s/p. The solution is to do a SET NOCOUNT ON at the start of the s/p. In addition, there seems to be a problem if the s/p uses temporary tables (i.e. #TableName). It works fine if using table variables though.

Greg.

Exec Stored Procedure

Hi,

Hope someone can help me out here - I'm trying to design a data flow in SSIS which relies in part on a stored procedure as a data source - I'm running it through OLE DB.

Sure Exec MystoredProc works fine on preview and on parsing, but it refuses to acknowledge any of the columns, when I go to Edit-->Columns everything is blank.

Just out of interest - the reason I am using a stored procedure is because I dump the data into a temp table and then amend a couple of the columns to make it the same as my other database (for example where len(field) = 6 then field = '0000' + field).

Possibly I'm better off taking the raw data through the OLE connection and then transforming it through SSIS, but my gut feeling is I should minimise what I'm dumping into SSIS and offload the processing onto the local DB. Any thoughts?

Thanks

Rich

To do exactly what you need - use OLE DB Command Transformation - part of the data flow. Use ? for column parameters.

IMHO: There are two schools that define how to do this: ETL and ELT. What you are trying to do is ETL - the disadvantage of this is if you have a lot of rows - this method will execute the SP as many times - this is performance impact.

In ELT approach you load the data with Bulk Insert and then apply a SQL statement or another set of trasnformations to load the target.

|||

This is helpful Dima, particularly your comments on ETL & ELT, but it doesn't quite hit the spot in terms of what I want to achieve.

Maybe because I'm being thick. My fundamental problem is that my OLE DB connector will not return any column names. When I add the OLE DB transform it just whinges that I don't have any column names.

As I see it your solution will allow me to connect two tables through OLE DB connectors, drag them into OLEDB transform, do my changes, and then output columns - are you saying that there is no way for SSIS to derive column names from a stored procedure without iterating through the recordset one record at a time? This sounds totally useless, but completely feasible.....

As I have already done the work I really just want to get the stored procedure results into SSIS via my OLE DB source, if you are saying I have to start again then I will, but in truth if using this technology means I have to rewrite all my existing SP code as data flows then it is about as much use to me as a chocolate teapot, I have years of work wrapped up in stored procedures and also I would prefer to distribute the load, I want as few transformations as possible in SSIS, the primary use for the server is reporting, not data transforms, we have plenty of spare DB capacity across the planet and bandwidth is at a premium so thinking about what you've said I think we are better off restricting the recordset at source.

|||

I feel your pain :)

What is your OLE DB source? a DB or file? If you have weird source - you may want to see if there is newer ODBC or OLE DB driver out there.

For the existing SP's:

If you already have SP's that accept fields and insert them into a table, row by row - you should be able to reuse them. You can map source fields to the OLE DB command parameters.

|||

Hi Dima,

Hmm... Just to let you know I worked round the problem after reading your answers - my stored procedures now delete and create tables, which I then query, not very efficient but hey, it works, and I can schedule them monthly just before my reports need doing. Anyway, it is only MS SQL I have a problem with, all my Oracle stuff is based on views anyway and it works fine (?)

I tried using the ADO.NET source instead but this is even more messed up.

Path of least resistance until Microsoft sort this mess out, I think.

Thanks for your help

Rich

|||I guess you are doing something wrong... You can call a SP in an OLEDB datasource (described here: http://msdn2.microsoft.com/en-us/library/ms141696.aspx). I tried that with Adventureworks using the SP they suggested for testing with parameters (just entered a one as value for each ?). It returned the metadata correctly...|||I've had similar problems where SSIS doesn't correctly identify columns if you have anything more than a vanilla SELECT statement in the s/p. The solution is to do a SET NOCOUNT ON at the start of the s/p. In addition, there seems to be a problem if the s/p uses temporary tables (i.e. #TableName). It works fine if using table variables though.

Greg.

Exceptions in Data Flow Scripts

What is the "correct" way of dealing with exceptions in a data flow script component. i.e. am I supposed to catch all exceptions and then set some failure flag? The reason I ask is I've got a script in a dataflow which is occasionally throwing exceptions when trying to convert an empty string to a decimal. Problem was the package locked up and had to be terminated when the exception was thrown (and not caught in the script)?

The only thing which differentiates this package from others I've created is the data flow has a conditional split which creates 2 seperate paths loading 2 seperate SQL tables - the exception is being thrown in a script on one branch which seems to hand the entire flow

PS I have fixed the script so this doesn't happen, i.e. test if the input string is String.Empty and if so set the _IsNull property.

If you are going to go down the road of custom building functions inside a script versus using the derived column or conditional split transformations to look at your data (test your data for correctness), then you'll also have to build in your own error handling as the script component does not support error outputs as part of the data flow.

Phil|||

Hi Phil,

Thanks for the reply, I'm not sure you're answering my question though The problem is that if an exception is thrown in a script and not caught, the package simply locks up - the unhandled exception seems to be blocking - no event handler is called etc. So what I'm asking is how do you flag a failure in a data flow script (if it were a control flow script I would propably create a global catch handler with Dts.TaskResult = Dts.Results.Failure

Dave

|||I think the package should lock up though, as the script component doesn't support the error output stream. So if an error is encountered in a script task, how should the package continue? That is, the error is fatal to the script component.

Some of the other guys will undoubtedly have some more advice when they get in tomorrow morning, especially those that are well versed in script programming.

Sorry, but I won't be of no more help tonight, especially when I'm not sitting in front of SSIS.

Phil|||Does it really lock up, or does the package simply fail?|||

It locks up, i.e. if run from BIDS the scipt component goes yellow when it starts executing, and nothing more occurs.

In other data flows, exceptions do cause the script component (and ultimatly the package) to fail. The different seemingly being that the package has a conditional split and each path of the split appears to be running concurrently when the exception is thrown in the script.

It's interesting that there's no error output from a script - not sure what to make of that - of all my dataflow components, the ones which fail the most are my scripts , esp since I cannot single step through them. Maybe I need to add and error number colume, handle the exception and set the error number in the script and then pass the subsequent flow through a conditional split?

|||

Dave Waterworth wrote:

Maybe I need to add and error number colume, handle the exception and set the error number in the script and then pass the subsequent flow through a conditional split?

Yep, a very valid solution.