Viewing 15 posts - 43,966 through 43,980 (of 59,101 total)
Doc (4/30/2009)
A funny side of Outsourcing from Onion news network 😀http://www.theonion.com/content/video/more_american_workers_outsourcing
THAT's freakin' funny, Doc! Heh... I'll bet there are folks out there that have actually managed to pull...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2009 at 9:05 pm
Actually, it's a "white space" problem.
[font="Courier New"]DECLARE @CrLf NVARCHAR(MAX)
SET @CrLf = 'X '+CHAR(13)+CHAR(10)
SELECT LEN(@CrLf),
LEN(REPLACE(@CrLf,CHAR(13)+CHAR(10),''))[/font]
Any sproc that has spaces just before the last CrLf will have the problem because when the trailing CrLf goes away, those spaces become...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2009 at 8:43 pm
See what I mean? This works...
[font="Courier New"] SELECT [Name],LenCount,LenTally,REPLACE(definition,CHAR(13)+CHAR(10),CHAR(1))
FROM (
SELECT TOP(200) o.name, m.definition,
(DATALENGTH(m.Definition)-DATALENGTH(REPLACE(m.Definition,(CHAR(13)+CHAR(10)),'')))/4 AS LenCount,
(
SELECT COUNT(*) AS DoDah
FROM Tally
WHERE N <= LEN(definition)
AND SUBSTRING(definition,N,2) = CHAR(13)+CHAR(10)
)AS LenTally
FROM MASTER.sys.all_objects o
JOIN MASTER.sys.all_sql_modules m ON o.OBJECT_ID = m.OBJECT_ID
WHERE TYPE = 'P'
)d
WHERE LenCount LenTally[/font]
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2009 at 8:04 pm
Phil Factor (5/1/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2009 at 7:58 pm
Paul White (5/1/2009)
I have *just* realized the point of Lynn's solution!
It avoids the I/O on the custom tally table completely.
Not my finest moment.
Luckily it won't be available on...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2009 at 7:02 pm
I still want to know what the CLR procedure is going to do. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2009 at 6:52 pm
Phil Factor (5/1/2009)
...but their developers seem unable to fix things so they work like they used to.
Ouch.
They're doing all they can to put in a better solution ASAP. The problem...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2009 at 12:03 pm
Florian Reischl (5/1/2009)
TheSQLGuru (5/1/2009)
Flo, are you getting your reads from SET STATISTICS IO ON? IIRC UDFs don't report IO correctly in this manner. Try getting them with Profiler.
Good...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2009 at 11:14 am
I'll take a look, Paul. Thanks.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2009 at 11:07 am
JohnG (5/1/2009)
1. Create it as an Indexed Organized Table (IOT) using the ORGANIZATION INDEX clause. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2009 at 10:53 am
Almost forgot... the reason why I don't use the code windows anymore is because, although they may work fine with FireFox, they suck when using IE7. The remove blank...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2009 at 6:31 am
Florian Reischl (4/30/2009)
We had a performance issue in conjunction with STUFF? Maybe, I'm just gone blank... :doze:
Maybe it's just me and I'm thinking of the wrong person. It was...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2009 at 6:27 am
JohnG (4/30/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 30, 2009 at 5:05 pm
That would be the ANSI standard for UPDATE... subqueries for each field(s) being updated. If you do such a thing in SQL Server, the duration of the update increases...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 30, 2009 at 2:59 pm
Heh... I wonder if the ANSI committee like pork chops. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
April 30, 2009 at 1:20 pm
Viewing 15 posts - 43,966 through 43,980 (of 59,101 total)