>>Bummer, we do a lot of pre and post-processing of data sets and views and were looking to an alternative to having to perform a lot of "data over the wire" transfers while performing these. we also have lots of embedded function in our queries and are always needing one value from a data set to use in processing in some cases. We also are very dynamic in what columns are in our views and the user has total control over which ones he gets back. T-SQL is just painful when we are striving to remain abstract and data-driven.
>>
>>We are excited about possibly using this functionality to keeping code down over writing many static sprocs.
>
>Viv's post just shows M@'s position on the use of the clr functionality. I read should or should not, not don't. If you need the functionality and it saves you processing time on the client, I would go for it.

Hi,

There's the usual Catch22 - if it saves processing time on the client then it costs processing time on the server. And the CLR processing will require the same number of CPU cycles whether on the client or server so any time saved will be based on the size of the result set sent to the client. And this calculation only holds true if there's only one client. If the server is handling multiple requests there could be a large strain on its resources whilst clients are spinning their wheels waiting for their results.

Like Michael I was initially enthused by the CLR capability but the paper writer doesn't appear to have any particular axe to grind and gives examples where CLR is a better choice but the general conclusion is that you need *very* good reasons to use it.

Regards,
Viv