SELECT CASE WHEN SIV > ActualSellingPrice THEN 0 ELSE CASE WHEN NEW < 0 THEN ActualSellingPrice * 7 / 47 ELSE (ActualSellingPrice - SIV) * 7 / 47 END END...

What business problem is this causing you?

What happens if some rows have more than 4000 characters in that column?

Check updatetext in bols.

Why are you using an ntext datatype??

I've learned to stay away from those sp_oa, seen too many problems caused by this.

Well I'm here now but I'm too tired to find and obvious fix (assuming there's one). I'll scratch my head on this one tomorrow.

While I'm gone, could you post...

Well that's another story, why can't this data be kept in the same table??

Or are you querying different data in different tables?

I'm sorry but I still don't get it... can you show some sample data/results?

Nice point... but I still like to see it written as a join, makes the query read better.

I'd give my name but other than perf tuning I can't offer much... but I'd be fun to move to australia... I'd have a 9 months summer this year

Don't you have a DocumentId somewhere in the db?? that would be much simpler to implement, not to mention much more safe.

The cursor exists only for the @varStr execution lifetime. Can you post the whole code so we can figure out the best solution?

You want all the users to be presented vertically?

No, if you need the select to have parameters, then transform the proc into a table function, otherwhise just make it a view.

It is to have a calculated column.

Exemple from an inventory table

Columns

Qty decimal (18,4)

Price decimal(18,4)

Value as Qty * Price