Viewing 15 posts - 34,876 through 34,890 (of 59,102 total)
AndrewJacksonZA (2/28/2011)
HiPlease include a link to where Jeff Moden posted his function.
This search turned up this result.
Is that where you got the function from?
Thanks
Andrew
That's likely it. I've only posted...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 28, 2011 at 6:19 am
Jeff Moden (2/28/2011)
SQLkiwi (2/28/2011)
A couple of tweaks to Jeff's code, mostly for correctnessI was in a bit of a hurry... what tweaks did you make?
Never mind. I see. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 28, 2011 at 5:54 am
SQLkiwi (2/28/2011)
A couple of tweaks to Jeff's code, mostly for correctness
I was in a bit of a hurry... what tweaks did you make?
--Jeff Moden
Change is inevitable... Change for the better is not.
February 28, 2011 at 5:51 am
Ok... I've not tested every eventuality, but this works with the test data provided by other posters.
First, here's that test data.
CREATE TABLE dbo.CLOB
(
Row_ID INT IDENTITY(1,1),
Parse_Clob NVARCHAR(4000)
)
INSERT INTO dbo.CLOB
SELECT ',2...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2011 at 11:12 pm
{edit} I found a bug in my code after I posted it, so I took it down. I'm trying to fix the bug right now.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2011 at 10:32 pm
JJH82 (2/27/2011)
nvarchar(4000) is set to the column, so I assume that no string is longer than 4000.:-)
Very cool. I'm sure that Paul will come up with something great on...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2011 at 9:04 pm
JJH82 (2/27/2011)
I created a loop to process 1000 Records at a time.
any comments or suggestions...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2011 at 8:58 pm
SQLkiwi (2/27/2011)
Jeff Moden (2/27/2011)
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2011 at 8:56 pm
SQLkiwi (2/27/2011)
Jeff Moden (2/27/2011)
Heh... you should practice what you preach in this case. 😉
Heh. No. My comments were as much for daveriya's benefit as anyone else's - so...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2011 at 8:54 pm
SQLkiwi (2/27/2011)
Jeff Moden (2/27/2011)
I found it under "partitioning schemes" in BOL... not under "partitioned views".
The is a good deal of coverage of this topic in BOL, in separate entries. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2011 at 8:32 pm
SQLkiwi (2/27/2011)
pietlinden (2/27/2011)
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2011 at 8:30 pm
Actually, after all these years, I finally found the correct rules for the partitioning column including the fact that the partitioning column must be a part of the PK. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2011 at 7:56 pm
So, instead of having the procedure add union alls for only the tables that would be required on a per call basis, you standardized certain views for certain distances against...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2011 at 7:42 pm
But there IS a hit on performance... try adding an index to NVARCHAR(MAX) or anything that involves over 900 bytes.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2011 at 5:57 pm
Brandie Tarvin (1/31/2011)They work wonderfully well for recursive querying...
You forgot to mention that recursion is usually hidden RBAR that should usually be avoided. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2011 at 5:23 pm
Viewing 15 posts - 34,876 through 34,890 (of 59,102 total)