You probably don't need to loop through the records. With any luck (and good db design) you can rewrite your code to use the whole of the inserted and/or deleted...

In case you wander back onto this path, this might be what you were after:

create

function dbo.getFY(@date datetime, @FYstartmonth

You might want to have a look at this, too. It's about the same issue, rather than a crosstab (aggregate) query like the previous link.

http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=8&messageid=291923

I've had a go at this, trying to keep the dynamic SQL to a minimum. The processing could possbly be made more efficient, but the task itself limits the options...

Effectively the same as

(2) Have the front end do the processing of the result sets for you.

Except you are using a middle tier (the CLR code) rather than a...

You can record them if they don't abort a transaction or terminate the connection, by changing the sp to capture the value of @@error immediately after each statement in the...

You need to use the table which contains all the ProsAtty entities as the basis of your query, using a left join (LEFT JOIN) to return...

Here's an indexed view version.

Performance stats are shown at the bottom for three tests, comparing use of base table indexes v use of view indexes.

[edit: revised and expanded,...

>What do you mean by 'could'? Is what your suggesting that

>where null is null

>could/should (?) return as unknown?

Yes, I am imagining that, say, a...

From BOL v9:

RAISERROR ( { msg_id | { msg_str | @local_variable} }{ ,severity ,state }    [ ,argument [ ,...n ] ] )    [ WITH option [ ,...n ] ]

msg_id

Is a user-defined...

>I need change behaviour of the "SomeProc".

>The result should be UNION of result tables from two execution of the "SomeProc".

>Once with original parameters and once...

Yes I believe fervently in teaching propositional logic via the means of SQL.

quiz:

In the context of te above batch, are these two logically equivalent? Could they give different results? Discuss.

Just in case it could be a problem: the constraint as defined will also disallow nulls in ClaimStatusID.

declare

@t table(ClaimStatusID int, DateClosed

Agree with the indexing idea - but remember all other indexes use the clustering key for row access, so don't make it too wide. All the usual caveats about storing...