October 24, 2013 at 2:39 pm
I want to see the results of my execute SQL query. Is there any simple way to do that ? I am looking for some kind of viewer or even file where the results can be written to.
October 24, 2013 at 3:24 pm
You cannot see this in SSIS itself.
You'll need to go to the database and check if the query was executed.
You could also use SQL Server Profiler to verify if the query has been sent to the database correctly.
Or you could implement some auditing in the query itself.
The Execute SQL Task will only tell you if the query has been successfully executed or not and how long it took.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
October 28, 2013 at 4:34 am
Write the results of your SQL query out to a variable, try single row first, if you have a full result set then it gets a little more tricky.
1 . Create a string variable eg: @resultsfromquery.
2. In you SQL Task container, choose ResultSet Single row
3. Choose Result Set from the menu on the side GENERAL, ParameterMapping, Result Set, Expressions.
4. Set the Result Name to 0 and the VariableName to your variable eg: User::resultsfromquery
5. Add a breakpoint to your SQLTask, you can use Break when the container receives the OnPostExecute
6. Start Debug (F5)
7. When debug starts you will have the extra option of adding a WATCH window.
8. When the watch window appears drag your variable onto the watch window.
When your package hits the breakpoint, you will then see your results appear in your variable.
If you are doing a full result set you will need to set up a for each loop container 🙂
Hope this helps
Paul
October 28, 2013 at 7:00 am
pnr8uk (10/28/2013)
Write the results of your SQL query out to a variable, try single row first, if you have a full result set then it gets a little more tricky.1 . Create a string variable eg: @resultsfromquery.
2. In you SQL Task container, choose ResultSet Single row
3. Choose Result Set from the menu on the side GENERAL, ParameterMapping, Result Set, Expressions.
4. Set the Result Name to 0 and the VariableName to your variable eg: User::resultsfromquery
5. Add a breakpoint to your SQLTask, you can use Break when the container receives the OnPostExecute
6. Start Debug (F5)
7. When debug starts you will have the extra option of adding a WATCH window.
8. When the watch window appears drag your variable onto the watch window.
When your package hits the breakpoint, you will then see your results appear in your variable.
If you are doing a full result set you will need to set up a for each loop container 🙂
Hope this helps
Paul
That only works with SELECT statements of course, which are kind of pointless in an Execute SQL Task unless you assign the results to a variable 🙂
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
October 28, 2013 at 8:31 am
Well yes 🙂 but the poster seemed to want that? :-S
October 28, 2013 at 2:07 pm
pnr8uk (10/28/2013)
Well yes 🙂 but the poster seemed to want that? :-S
Not sure, he doesn't mention the type of query 🙂
If it's an update statement, you see nothing in SSIS.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
October 28, 2013 at 2:34 pm
Dude... what are you trying to do here? I'm just trying to help the guy out, there's no mention of an update in his post or I wouldn't have put down my solution. I'm not trying to say you were wrong or anything. Aren't these forums about trying to provide a solution, not undermine any poster or helper?
I want to see the results of my execute SQL query. Is there any simple way to do that ? I am looking for some kind of viewer or even file where the results can be written to.
October 29, 2013 at 1:47 am
Dude, relax. I was just pointing out that there's not enough information in the original post to know what kind of query it is.
If it is an update/delete, the variable is useless, if it's a select, it's not.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
October 30, 2013 at 8:55 am
This is one of two reasons I don't use the execute SQL task. If I get called at 1 AM because the SQL failed I want to know where it failed and what error I got. I don't want to have to rerun the SQL in SSMS to find the error. And I may have to determine if I can rerun the earlier steps in the SQL, may need to restore or recreate certain files. Not things you want to have to think about at 1 AM.
The second reason is I have to update the SSIS package anytime I make a SQL change. I know this can be a good thing if you keep versions of each update. But luckily we haven't ran into any issues, yet.
We use an 'Execute process task' to call a 'bat' file that executes the SQL. I can set this to put the log from the SQL out to a file that I can then review.
So until someone can tell me how I can see this same type of 'log' information for an execution of a SQL job, I will not be using the execute SQL task.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
October 30, 2013 at 9:30 am
below86 (10/30/2013)
So until someone can tell me how I can see this same type of 'log' information for an execution of a SQL job, I will not be using the execute SQL task.
If you just want to know where and why the task failed, you could use SQL Server error handling to get an even better error log. To avoid changes on the SSIS package, you could simply use Stored Procedures instead of the full query.
I'm not sure that your way is the way to go, but if it works for you, then I can't suggest you to stop using it, just wanted to give some ideas.;-)
October 30, 2013 at 9:47 am
Luis Cazares (10/30/2013)
below86 (10/30/2013)
So until someone can tell me how I can see this same type of 'log' information for an execution of a SQL job, I will not be using the execute SQL task.If you just want to know where and why the task failed, you could use SQL Server error handling to get an even better error log. To avoid changes on the SSIS package, you could simply use Stored Procedures instead of the full query.
I'm not sure that your way is the way to go, but if it works for you, then I can't suggest you to stop using it, just wanted to give some ideas.;-)
I know how to tell where my SSIS package failed it's just finding out where in the SQL it failed and what error it gave. And from what I've done, granted not a lot, I don't see that I can get that detail from the execute SQL task. If you have a 1,000 line SQL file you are executing with say 20 individual SQL 'steps' within it. I need to know that SQL 'step' 10 failed for 'duplicate key' or whatever the error is. My log file will give me that and I can also see how many rows were processed by each step. I haven't done much with stored procedure so I am not aware of any 'log' that is created when it is executed. Where/and how would I find that information? Does the stored procedure need to be set up in any special way for this to happen? Or is is a setting on the database or server?
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
October 30, 2013 at 9:57 am
I wasn't saying that stored procedures save a log automatically, but are a simple way to manage your T-SQL code without touching the SSIS packages.
For the error logging, take a look at TRY...CATCH documentation. It might seem to be more work to do, but it's more flexible than normal logging.
October 30, 2013 at 10:18 am
Luis Cazares (10/30/2013)
I wasn't saying that stored procedures save a log automatically, but are a simple way to manage your T-SQL code without touching the SSIS packages.For the error logging, take a look at TRY...CATCH documentation. It might seem to be more work to do, but it's more flexible than normal logging.
Sorry I miss understood your prior post. I'll keep the TRY..Catch in mind, but with thousands of individual SQL jobs out there it would be a long time to migrate to that. I was just hoping there was something out there that I wasn't aware of. Thanks.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
October 30, 2013 at 10:42 am
I am doing only select statements.
Response "to below86" - regarding execute SQL indirectly by executing a bat file which executes SQL - I am trying something similar now. Need your help to figure it out.
I made posts on it here and haven't got much help so far -
http://stackoverflow.com/questions/19674377/need-to-understand-output-of-sqlcmd-exe
October 30, 2013 at 10:51 am
Hi mate, if you are only doing select statments then my solution would work...
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply