Did you look closely?

Run it again:

select * from tempdb..sysobjects

create table @temp ( a int)

select * from tempdb..sysobjects

and tell me how many rows come from 1st select and how many from 2nd...

Did you hear such name as "Jean-Claude Van Damme"?

Try to work it out.

After you finish with it start with his original name: "Jean-Claude Camille François Van Varenberg"

Did you actually run it?

Did you notice any difference between @temp and #temp?

Run this:

select * from tempdb..sysobjects

declare @Temp TABLE (ID int)

select * from tempdb..sysobjects

What do you see?

Do you think requirements grow on trees?

Who, on you opinion, made this requirement?

1. Generally speaking yes. But actually UPDATE will be equal to DELETE + INSERT in the worst possible case.

Don't forget about single record to LOG file instead of 2.

Also,...

1. No need fr transaction.

Imagine scenario when 2 processes try to do the same save interrupting each other:

1st runs UPDATE, 2nd runs UPDATE,

1st runs INSERT WHERE NOT EXIST, 2nd...

Jeff, would such solution be acceptable if it would be FOR YOU?

I don't see any other use of this function but for cursoring.

If you mean to get rid of cursors, you don't need this function at all.

Just a note:

1 "write" equals about 8 "read"s  in terms of consumed resourses.

So, your approach ir really wrong for such a busy system like yours.

You must choose UPDATE...

Try this.

UPDATE FSA1

SET Counter = 'Terr, Prov and FSA match',

GroupLabel = Substring(FSA1.FSA,1, 1) + Substring(FSA2.FSA,1, 1)

FROM dbo.FSAGroupingCursor FSA1

INNER JOIN dbo.FSAGroupingCursor FSA2 ON FSA1.RowID <> FSA2.RowID

AND FSA1.Territory =...

So, what are you after?

What gave you idea to spoil the thing with "GO"?

What do you mean by "insert into #command... stuff"?

create table #Command (

 EventType nvarchar(100),

 parmeters int,

 EventInfo nvarchar(255)

&nbsp

INSERT INTO #Command

EXEC sp_executesql N'dbcc inputbuffer(@SPID)', N'@SPID int', @SPID = @@SPID

Don't see anything opposite.

Keep in mind that "OR" means "rescan" (or "re-seek", if you are that lucky to have proper indexes set up ...

Yes, the permanent table is the best way to do it. Especially when you deal with big sets.

But I know how it's difficult for developers to think in "table" way....