Jonathan Kehayias (2/6/2009)

---

I didn't use his CLR method directly because it has an inherent flaw in its usage of Regex in it
that I wouldn't make in my own code. Instead I used a functionally identical function:

Jonathan Kehayias (2/6/2009)

---

Not true. I've seen this happen in consulting twice for OLE automation and a few times for XML documents that get created but not removed. Its not that difficult of a mistake to make. Leaking in CLR is only possible with UNSAFE assemblies, as a part of the design of the hosting environment. The ability to leak memory requires Host Protection Attributes that are prevented from loading in anything but UNSAFE.



You could do everyone a favor and just reference them to the text file rather than posting the varbinary output string of a compiled assembly in here and making this page of the forums unusable because it doesn't know how to handle a string that long. You aren't comparing similar code, by looking at the binary compiled assembly object. The code is the C# and should the following connect item get added to SQL Server:

http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=265266

the ability to write code similar to the following will exist in SQL:

CREATE PROCEDURE my_proc @par1 int,
                         @par2 int WITH
EXTERNAL LANGUAGE C#, PERMISSION_SET = EXTERNAL_ACCESS AS
using System;
using System.Data;
using System.Data.SqlClient;
...

Jeff Moden (2/6/2009)

---

Ya beat me to it on the other thing... I didn't realize the binary was quite so wide in your code and started fixing it as you were typing. It's fixed now. Thanks for the heads up, though.

Jonathan Kehayias (2/6/2009)

---

so I did it the right way, rather than the easy way

Jeff Moden (2/6/2009)

---

BWAA-HAA!!! Man, I'm right there with you on that one! Now, all we have to do is convince the rest of the world, especially the managers that want it real bad, to give people just a little more time so they don't get it that way... real bad.

Good talking with you again, Jonathan. Kudos on the article.

This solution is based on the premise that security is important enough to take the time to implement. If time is more important than preventing unrestricted access to the OS as the SQL Service account with xp_cmdshell, then this solution probably isn't for you.

That was it and I agree... someone like you wouldn't pass a bad path.

Jeff Moden (2/6/2009)
.... One of my major points was that someone posted some a link to some pretty bad T-SQL and the race between that
and a CLR and a test that probably wasn't even done correctly.....