I have an execute sql task , that only runs 1 sql statement, something
along the lines of :
Select * into dbo.tablename_old from dbo.tablename

Is there a way for me to promote the rowcount info up to the package so
it gets logged?
I always get "Progress count in Step: 0" for this (since sql tasks
don't seem to return rowcount),
I would love to be able to log this info properly.

@@rowcount will contain the number of rows effected by the sql operation.

If you want to write to some custom log table, then just add code to your
Execute SQL task. Like this:

Select * into dbo.tablename_old from dbo.tablename

insert into myLogTable
(rows, other columns...)
values
(@@rowcount, otherdata)


<jlcaesar (AT) gmail (DOT) com> wrote

This is what I am doing right now actually, sorry I should have been
clearer. Rather than have the DTS log and an additonal custom log
table, my goal is to store this within the DTS log , so that the dts
text log file is all that is needed to be consulted. I was wondering if
there was something similar to what you can do with RaiseError().

If you RaiseError() with a severity below 11, the task is still
completed successfully. If you RaiseError() in your TSQL code with a
severity of 11 or higher, DTS will recognize the task as having failed,
and it has the error message from your raiseerror call. The error has
basically been promoted from the scope internal to the task, up to the
scope of the task within the package.

I would like to do the same thing. I want to take the @@ROWCOUNT that I
have, and somehow move it out from the task's internal scope, to a
level where the DTS package will recognize it , and report it as the
progress count for that step/task . Any ideas if this is possible ?

VC wrote:

Hello jlcaesar (AT) gmail (DOT) com,


The only way i can think that this may be achievable is to use a proc to
capture the rowcount. Now you pass the value out using an output parameter
to a Global Variable. From a Script task you can write to the log using
WriteStringToLog(). It isn't very pretty but it should work.



Allan Mitchell
www.SQLDTS.com
www.SQLIS.com
www.Konesans.com