Viewing 15 posts - 51,391 through 51,405 (of 59,102 total)
Shaun McGuile (4/1/2008)
Jeff are those the 'Three Rules'? 😀akin to Asimov and Clarke
Heh... no... these are... 😉
[font="Tahoma"]Jeff Moden's Three Rules of DBA's.
1. A DBA may not injure data or performance...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 6:15 am
ashoknegi84 (4/1/2008)
i have a table like
empname empid empsal
---------------------------
abc 1 ...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 5:42 am
rbarryyoung (4/1/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 5:41 am
SQLZ (4/1/2008)
command on all tables that are more than 10% fragmented.
I know I can use sys.dm_db_index_physical_stats to get this...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 5:40 am
rbarryyoung (4/1/2008)
And as far as I'm concerned, IN and EXISTS OK to use. They are just as fast as Joins when used correctly and greatly aid code clarity.
WHERE IN...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 5:35 am
Heh... I'm thinking that's more than two options right there 😉 Lets see... DTS, OSQL query, SP_OA* sprocs... there's a couple more, but I forget.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 11:58 pm
Yes... don't use either... use an INNER JOIN instead.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 11:47 pm
Extract into what? Are the files all in the same format? We need just a little more info.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 11:45 pm
p.s. A join to a Calendar table would be even more effective...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 10:58 pm
tickler_foryou (3/31/2008)
I have a Order_date column where order dates are captured in SQL server 2005 DB, I need to find the order dates that falls on Week Days only...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 10:56 pm
You'd be amazed what it can do... as you've seen, it'll do splits. It'll also fill in missing dates, generate multiple rows for each row according to a "QTY",...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 10:33 pm
SQL ORACLE (3/31/2008)
We can use BIT MASK concept to implement this task.
Sure could... now, pretend it's 5PM on a Friday and you have a really hot gig at 5:30PM (what...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 10:21 pm
The only thing that can be faster than the Tally Table is Dynamic SQL... but that's not a split and it does have some security issues if it's public facing.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 10:09 pm
escaleraroyal (3/31/2008)
They just asked me to performance tune it.
But it appears the SP insert data if (party_data) > 36. Then it adds up a sort_order, and for new instrument_id the...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 10:06 pm
GSquared (3/3/2008)
Just did some tests.The XML version is faster, significantly so, than the Numbers table version, for parsing out a string.
Any bets? 😉 Post your test data please, the...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 9:39 pm
Viewing 15 posts - 51,391 through 51,405 (of 59,102 total)