Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Simple SQL CLR Integration Expand / Collapse
Author
Message
Posted Thursday, September 1, 2005 9:53 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, September 25, 2014 9:01 PM
Points: 1,113, Visits: 705
Not a whole lot. I think 5% is a very accurate figure for the current implementation. However, if MS changes a few things about the way UDTs and UDAs work in the next version, I think that number could jump quite a bit.

I also predict that in a future version MS will implement a fully object-based data access library that can compete with TSQL from a performance point of view. Note, I have no inside information to back that up, it's just what I think I see based on some of the direction I see all of this going in. If that does turn out to be true, I think we'll see the landscape drastically change as developers really will no longer have a huge incentive to learn T-SQL. But that's at least a few years off.



--
Adam Machanic
SQL Server MVP
SQLblog.com: THE SQL Server Blog Spot on the Web
Post #216184
Posted Thursday, September 1, 2005 9:56 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, September 25, 2014 9:01 PM
Points: 1,113, Visits: 705
The assembly is loaded into the database. The DLL is no longer used -- and can even be deleted.

You are correct, there can be many issues, and it is not an easy task. Not so bad for functions and stored procedures most of the time, but quite interesting for user-defined types...


--
Adam Machanic
SQL Server MVP
SQLblog.com: THE SQL Server Blog Spot on the Web
Post #216190
Posted Wednesday, September 7, 2005 2:37 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, January 20, 2009 3:33 PM
Points: 124, Visits: 13
This is the first I've been able to stop and look at this. Is it me, or is this CLR integration a lot like our current extended stored procedure capability?




Steve Miller
Post #217521
Posted Wednesday, September 7, 2005 2:42 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Thursday, November 20, 2014 10:16 PM
Points: 480, Visits: 472

Yep that sounds about right to me, except it seems a bit simpler to use. Anyway I'm convinced of its benefits, not something I'd use that often but when it's used it seems like it would be of great use.




Post #217523
Posted Wednesday, September 7, 2005 8:05 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, September 25, 2014 9:01 PM
Points: 1,113, Visits: 705
Similar, perhaps, with several key differences:

1) Managed code vs. unmanaged code -- means that CLR routines are safer than XPs.
2) XPs are created per server. CLR routines are created per database.
3) XPs are only "procedures". CLR routines can take the form of procedures, functions, types, aggregates, or triggers.
4) In-process ADO.NET context connection for CLR routines vs. "bound" connections for XPs -- means less overhead for CLR routines (no need to create a new connection).



--
Adam Machanic
SQL Server MVP
SQLblog.com: THE SQL Server Blog Spot on the Web
Post #217619
Posted Tuesday, September 13, 2005 8:20 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, January 20, 2009 3:33 PM
Points: 124, Visits: 13
Adam, thanks for the succinct summary.



Steve Miller
Post #219448
Posted Tuesday, January 24, 2006 3:00 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, August 10, 2010 3:50 PM
Points: 1, Visits: 8

I think the article is fine, but it seems to ignore the Visual Studio 2005 tools that can make the process of creating and debugging SQL CLR exectuables far easier.

 




HTH,

William (Bill) Vaughn
Author, Mentor, Consultant, Microsoft MVP
betav.com
Post #253229
Posted Friday, September 1, 2006 12:10 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, February 15, 2011 10:26 AM
Points: 1, Visits: 8

Excellent article!!! I am new to SQL Server and am charged with moving a MS Access application to SQL. I have managed to get all our business rules translated to the point all MS Access is used for is a "front end" consisting only of a database full of forms. Part of our application requires the output of reports in an Excel format. A resonably easy task in VBA. I have been struggling on how to accomplish this in SQL Server 2005. Since I am able to create the customm reports using VB.NET or C# .Net, this article gave me the link I desparately was searching for!

My Kudos to the author!

Post #305751
Posted Thursday, January 27, 2011 7:52 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Wednesday, November 5, 2014 11:16 AM
Points: 75, Visits: 622
Best example I have seen on the web. It actually works if you follow the steps.
Post #1054589
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse