That will work fine on small chunks of data, but recursion is inherently RBAR and therefor slow.

The...

I agree... clustered index with an index hint on it or and order by is required and you've been lucky with the order so far.

What are you doing that requires...

It's not done by Excel... it's done by the query. Add this to it...

WHERE ESASKSIZE > ' '

AND ESBIDSIZE > ' '

You would get 100 if you weren't also grouping by customer name and date as in your original code.

If you substitute the word "table" for "database", I'd agree with that.

All 3 work just fine if all you want to do is to detect that there is one or more. #3 is the fastest for this purpose. #1...

No... redundant data is not necessary. Like I said, you could use a trigger to pull this off.

Just curious... why do you want to do this? What is...

I believe you can limit that a bit by using the WITH (ROWLOCK) hint on the update.

Yes... your code for the trigger... let's see it...

Yes, that works... but no chance of an Index SEEK. The code should be written similar to the following to allow...

Actually, we still need a Create Table statement, and some data. Otherwise, we're just guessing as to what your data actually looks like.

Like Matt suggested, it's not possible...

I've found XML splits to be just a tad on the slow side. Take a look at the following URL.

http://www.sqlservercentral.com/articles/TSQL/62867/

Also, fairly big article on splits coming out on Wednesday.

Can't be done... computed columns cannot refer to other tables.

You might be able to use a trigger to accomplish this. Why do you need to do this?

David Lester (5/19/2008)

---

This one has me baffled. I have a table with five columns. As follows

RowID Char(16) {Primary Key, Unique}

Code1 Char(6)

Code2 Char(6)

Code3 Char(6)

Code4 Char(6)

What I need to do...