June 5, 2008 at 2:29 pm
I have been trying to debug a simple CLR function in VS2008 without any luck. I have searched Google and gone through several walk throughs without any luck. The function builds, deploys, and works from SQL fine but I cannot debug in VS. I created a new SQL login for a new user with SysAdmin privileges, and even set the permission level to "unsafe". Still, no debugging. The results in the output window of VS is "Canceled by user". I feel like this may be a permissions issue but I'm not sure. Can someone point me in the right direction to correct this? I use to debug CLR stored procs at another place of employment using VS all the time. Unfortunately, I wasn't involved with configuring it.
June 18, 2008 at 9:05 am
June 18, 2008 at 9:25 am
Professional...
After doing some additional research I did a re-install of the remote debugging service on the sql machine and that fixed the problem.
July 6, 2008 at 11:08 pm
MichaelC (6/5/2008)
I have been trying to debug a simple CLR function
Just curious... what does you "simple CLR function" do?
--Jeff Moden
Change is inevitable... Change for the better is not.
July 7, 2008 at 6:38 am
Nothing would debug because there was an issue with the remote debugging service on the server. After I re-installed that everything was fine. But, the simple function that I was working on would simply parse a comma delimited string and return the requested section. For instance, I would pass a string, the delimiter, and what section of that string that I wanted back, the function would parse it and return what I was looking for.
July 7, 2008 at 7:37 am
MichaelC (7/7/2008)
the simple function that I was working on would simply parse a comma delimited string and return the requested section. For instance, I would pass a string, the delimiter, and what section of that string that I wanted back, the function would parse it and return what I was looking for.
There are several methods for doing this in SQL and the good ones will beat the CLR for performance. They're also easier to modify if need be. Here's one of them... can be very easily converted into a function (which is a form of RBAR, just like your CLR function), but it doesn't need to be if you're only passing 1 parameter... take a look at the following article...
http://www.sqlservercentral.com/articles/T-SQL/63003/
... slight bit of modification on your part will blow the CLR performance pretty much away.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 7, 2008 at 7:49 am
... and, here's a bit of simple code to play with...
If you cannot create a Tally table, please post back... we have other ways to skin the same cat. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
July 7, 2008 at 7:52 am
Thanks for the info!
At the time we were using that function the string that we were pulling sections from may or may not have multiple parts. And we had different actions to handle depending on the number of sections there were. I don't think we are using that particular function any longer. It was something we were doing for a client that has since changed their minds and wanted to do something else.
July 7, 2008 at 8:05 am
Ok, thanks for the feedback...
By the way... sorry I forgot to post the simple code example... just in case anyone else is interested...
DECLARE @SomeString VARCHAR(1000)
SET @SomeString = 'Jeff,Bob,Ken,Samual,,Mary,Sue,Debbie,Carlene'
DECLARE @DesiredElement INT
SET @DesiredElement = 4
;WITH
cteSplitOne AS
(
SELECT ROW_NUMBER() OVER (ORDER BY N) AS ElementNumber,
SUBSTRING(','+@SomeString+',',N+1,CHARINDEX(',',','+@SomeString+',',N+1)-N-1) AS ElementValue
FROM dbo.Tally
WHERE N < LEN(','+@SomeString+',')
AND SUBSTRING(','+@SomeString+',',N,1) = ','
)
SELECT *
FROM cteSplitOne
WHERE ElementNumber = @DesiredElement
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply