Viewing 15 posts - 52,051 through 52,065 (of 59,067 total)
GilaMonster (3/6/2008)
The index with ProductID first produces an index scan because ProductID is not in the where clause.
Ummmm..... heh... What's that highlighted in red????
SELECT
ph.ProductId
,ph.CLientID
, ph.PolicyType
FROM
PolicyHeaders ph
INNER JOIN Products pr
ON...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 7:40 am
Ken... the OP actually wants to know what the algorithym is for the CheckSum function.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 7:35 am
Jacob Luebbers (3/6/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 7:34 am
Nisha, 2000 rows is nothing. Use Select/Into. Look at my previous post with the test code. Select/Into will load 2000 rows in less than 15 milliseconds. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 7:26 am
Why would you want to create, compile, register, and attach a CLR to do the same thing that was just done in T-SQL?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 7:18 am
I agree.... the Dynamic SQL will frequently perform better because it snuffs any chance of parameter sniffing and forces a recompile so you're always using a good execution plan... For...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 7:09 am
Yes, but it will take longer... you can do it with a Tally table and a join on the backslashes using SUBSTRING. I've already tried it (damn... should have...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:54 am
Heh... I can tell you which one is the only one that works 100% of the time...
http://blog.pengoworks.com/index.cfm/2008/2/15/The-only-valid-measurement-of-code-quality-WTFsminute
:hehe::P:D:);)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:49 am
Heh... Hour or so? Like I said previously, I've used this method to do 5.1 million rows in about 3 minutes. I'm sure there's a faster method, but...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:48 am
Heh... Daniel, unless you're wearing a porkchop around your neck, everyone is welcome in the "lions pit". Nice code...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:42 am
Sharon Matyk (1/3/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:40 am
CRUD... for some reason, this thread will no longer allow me to add a reply... in fact, it keeps overwritting THIS message when I try and the previous message has...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:36 am
Nisha, it depends... is the code for high hit ratio GUI code or is it for batch code that runs every once in a while?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:29 am
SELECT/INTO hauls butt in any DB but it runs like an ape that sat on a hot coal if you use it on a database that is setup for anything...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:24 am
Heh... WELLLLLLLLLLL!!!!!!
I'm pretty sure all you need is one select per column per table. It there where some rhyme or reason to the table names you
wanted to attack, we...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:03 am
Viewing 15 posts - 52,051 through 52,065 (of 59,067 total)