Hey Rich. Thanks for sharing those thoughts. I would agree that there is no intrinsic reason for lack of adoption. I think the slow adoption rate is related to a combination of the following:

• Lack of understanding of: its strengths and weaknesses, when to use it and when not to use it, limitations and pitfalls, etc.
• Steep learning curve: just like Analysis Services, one cannot just install / enable it and use it in a meaningful way. Without having a background in C# or VB.NET, it is more likely that one will create CLR code of a similar quality to the DB code we so often complain about being produced by developers who know only the most basic SQL.
• The human factor: as much as we like to pretend that science (this is computer "science", right?) is based on evidence / fact / logic, all of that is subject to silly, often irrational, personalities and politics, etc. As you mentioned, the mantra of "business logic doesn't belong in the database" gets repeated and rarely does anyone explain what they mean by that (i.e. what really qualifies as "business logic"?). And what if we are talking about actual business logic? So what? Does it make sense for the context at hand? Does that way of structuring an application take into account advances in hardware and software efficiency? Does it take into account the fact that most, if not all, of the major RDBMSs have been becoming more of data platforms rather than dumb data stores, and for quite some time now.

  Along these same lines, as I have mentioned before, a lot of people have claimed that SQLCLR presents problems for security and performance. But when pressed to give specific examples, I have only ever been given one: that a runaway Regular Expression can chew up CPU and/or memory. Ok. But that is hardly a reason to not use the entire feature simply due to a rather infrequent problem. However, the mere fact that some people wrote it in blogs meant that quite a few DBAs still won't enable a feature that could greatly help them, all because they read somewhere, years ago, that "CLR is bad" and that was somehow convincing, and there's certainly no time to waste re-evaluating that statement. It is far easier to just remember simple rules such as "no CLR" and "no Cursors" than to learn the nuances of when those things are entirely appropriate.

Take care,

Solomon..