Viewing 15 posts - 57,151 through 57,165 (of 59,098 total)
Ok, thanks... isn't that the way? Company buys something and that won't let you use it which forces you to revert to undocumented features in SQL Server...
This will work in...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 21, 2006 at 6:59 am
Thanks John... appreciate the feedback!
--Jeff Moden
Change is inevitable... Change for the better is not.
December 21, 2006 at 6:33 am
This is pretty cool... we have several complex, multi-step store procedures and some folks have put some pretty complex logging procedures in them just so they can query a...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 20, 2006 at 10:43 pm
How simple... how elegant... I never knew you could do this... nicely done.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 20, 2006 at 10:22 pm
We sure don't need a cursor for this and I'm not sure you could do it any faster or easier in the client
...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 20, 2006 at 9:40 pm
What... replace one form of RBAR (pronounced "ree-bar" and is a "Modenism" for "Row By Agonizing Row") in the form of a correlated sub-query for another form? I don't know...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 20, 2006 at 7:22 pm
Sure... right after you tell us why you can't use xp_filesize so we don't recommend something similar...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 20, 2006 at 6:57 pm
Nice article, David, as usual...
As you are aware, I suspect that any performance differences will only occur where joins of different data types occur due to implicit conversions... but...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2006 at 5:46 am
Yep... you're supposed to know what the bad rows are BEFORE you begin the transfer. ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2006 at 5:25 am
Heh... my turn Remi... how come no Tally table here? "I'm surprised you didn't think of it" ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2006 at 8:45 am
Here... shoe-horn a call to this function into my previous code to get rid of all but the required "pattern" of characters...
CREATE FUNCTION dbo.CleanData(@sText AS VARCHAR(8000),@pattern varchar(8000))
RETURNS VARCHAR(8000)
...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2006 at 5:40 pm
Thanks for the feedback Jules... I always wonder if anyone actually runs these things ![]()
Like I said, how long does it take on...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2006 at 5:31 pm
David...
What do you call "huge?" How many denormalized rows are we talking about? I work with a denormalized input from a million customer IVR and there are currently almost...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2006 at 5:01 pm
I appreciate the compliment but I didn't do anything... my comment was actually directed to Mohammed's fine and easy solution.
John is correct... using the system tables would certainly work,...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2006 at 4:49 pm
So... how many rows must you examine (do this for)?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 15, 2006 at 4:45 pm
Viewing 15 posts - 57,151 through 57,165 (of 59,098 total)