Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>SQL 2005 CLR only supports .Net 2.0 framwork by default. I have imported the .Net 3.5 framework into SQL server before, but it is somewhat messy and opens up some security holes (don't recall the all the details), but the quick and dirty is <a href="https://stackoverflow.com/questions/335524/using-net-framework-3-5-in-a-sql-server-2005-stored-procedure">in this question</a> -- in particular</p> <pre><code>CREATE ASSEMBLY [System.Core] AUTHORIZATION [dbo] FROM 'C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll' WITH PERMISSION_SET = UNSAFE </code></pre> <p>The other roadblock that you typically encounter in CLR procs is the security context from the user running the stored proc is not inherited by the CLR proc, so trying to accomplish some things can be harder than you would expect.</p> <p>Debugging a CLR proc is not as easy. You can do it, and I was never able to get a full stack backtrace (with line number, etc.). So, debug before you move it to CLR as much as possible.</p> <p>Other than that, I have not had much trouble with CLR procs -- they work pretty well as long as you have a handle on possible performance issues by running complex code inside SQL, don't allocate lots of memory inside your CLR proc -- you will regret it.</p> <p>ADDED</p> <p>One other issue I thought of. CLR proc code writing needs a higher level of proficiency than typical client side code or stored procs. This is a maintenance consideration.</p> <p>Updates to the CLR proc are also more complicated the client side code or sql procs, so this can also be a problem. This also complicates maintenance.</p> <p>I'm not trying to discourage CLR procs, the upsides are also good -- performance, flexibility, security (have to have DB permissions to update). But, I was trying to documents the issues that they don't tell you about when you read about "how great and simple CLR procs are".</p> <p>ADDED</p> <p>You don't give detail, but if you are data bound (lots of rows) and you can write the logic as set-based TSQL performance is almost certain to be much better as set-based. TSQL is slow if you try to do lots of computation via TSQL -- scripting runs slow, database I/O runs fast. TSQL is not very flexible as a programming language, so CLR adds flexibility and faster code execution.</p> <p>If you are not familiar with using APPLY in a select statement (Sql 2005+), you should take the time to understand as it can be very useful in keeping complex query "set based" -- you don't ever want to use a cursor if you can avoid it -- slow and chews up database resources.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload