February 22, 2014 at 2:50 am
Yes, we do it for the SQL Mail
February 22, 2014 at 3:52 pm
My 2 cents: SQLCLR is like any other hammer, when you hold it, every thing looks like a nail! I think it is a valuable addition to the SQL Server and like any technology, when used properly it rocks. But having outperformed CLR with set based code in certain cases and also my best efforts in other being up to 3 or 4 times slower, one realizes that there are specific nails for specific hammers. The down side in my opinion is not the technology itself but the application of it. Far to often we use what we are most comfortable with, not necessarily what is the most applicable.
February 24, 2014 at 7:30 am
Jeff Moden (2/21/2014)
eric.notheisen (2/21/2014)
I worked on a project for Wells Fargo a few years ago. We had a database developer who used CLR procedures for 60 percent of his stored procs. We found the performance hit to be minimal and [font="Arial Black"]the flexibility to be superior.[/font] In my current work I have used CLR procedures several times when I needed to recursively look at or process .dataFlexible how and superior to what?
When it comes to databases, scalability, extensibility, and maintainability are good, but flexibility can have some negative connotations.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 24, 2014 at 10:00 am
SQL# contains just about everything I'd want to do that isn't already in T-SQL.
It think SQLCLR has yet to have its day. I firmly believe that it has potential for developing a statistics toolkit and that requirement has yet to come to the fore.
We did some work with SQLCLR and service broker some time ago but it didn't catch on.
Personally I think that where there is separation between the various roles of a DBA and the roles of developers you won't get SQLCLR adoption. If you had developers with a strong database skillset then blending the two worlds together would be much more likely.
February 25, 2014 at 1:47 am
David.Poole (2/24/2014)
...If you had developers with a strong database skillset then blending the two worlds together would be much more likely.
I could take exception to that!!! :rolleyes:
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 28, 2014 at 8:33 am
Like most people on all the developments I have been involved in we have stuck to using code within the API or T-SQL with standard SQL functions. I am afraid the SQLCLR has remained almost untouched.
March 6, 2014 at 3:38 am
Hmm, perhaps mentally inspired by this thread I tried a CLR function to export a PDF, replacing an SSRS export that had become troublesome. Sadly it did not work due to the limitations on the libraries you can reference from the SQLCLR. I ended up just cmd shelling out to a console app, which works fine, so I guess I'll continue to overlook the CLR.
Viewing 7 posts - 46 through 51 (of 51 total)
You must be logged in to reply to this topic. Login to reply