Viewing 15 posts - 51,766 through 51,780 (of 59,098 total)
Thanks Adam, but he said
"The source table will have approx 10,000 records."
I want to know how many rows are in the destination table. That will answer...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 15, 2008 at 3:31 pm
Hi, everyone. I'm working on my senior project.
Cool! Which school?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 15, 2008 at 3:25 pm
How many rows in the desitination table?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 15, 2008 at 3:11 pm
Dang, Barry... good stuff but awfully long for saying that folks preach the standards right up to the point where the standards don't work for them and then they violate...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 15, 2008 at 2:42 pm
Barry, you're correct... the single column update example yields nearly identical results for both query types in 2k5.
[font="Courier New"]Correlated Subquery...
Table 'TargetTable'. Scan count 1, logical reads 54, physical reads 0,...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 15, 2008 at 1:42 pm
All I can say is “Not in My Experience.” Although Sql2000 did have some problems in this area (performance “bugs”, IMHO) these were mostly addressed in Sql2005.
Thanks for that...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 15, 2008 at 1:18 pm
Oh... ok. Thanks Jack.
Hey, do you have a dates table? I've got a neat trick to show you if you do...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 15, 2008 at 12:56 pm
Like this...
--===== Solve the problem is 2k5
SELECT Category,[Desc],ID,
DENSE_RANK() OVER (ORDER BY Category,[Desc]) AS Seq
FROM #yourtable
ORDER BY...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 15, 2008 at 11:55 am
But for some application elements it would be very handy to copy a complete row of data
and then alter some values of the new record via the userapplication,
You really...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 15, 2008 at 11:45 am
Sure... use DENSE_RANK instead of ROW_NUMBER... look it up in Books Online... except for the partition, the rest of the query will be pretty much the same...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 15, 2008 at 11:06 am
Ummm... just in case you don't have a "Dates" table like what Jack used, please consider the information at the following URL...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 15, 2008 at 10:47 am
Heh... I think the OP "left the building".
The other thing is, ( I don't think anyone mentioned this above) you will never get the same speed using SELECT * no...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 15, 2008 at 10:43 am
Jack Corbett (3/15/2008)
Steve Jones - Editor (3/15/2008)
I've added this to the list. turns out to be a switch 🙂Sounds like good data-driven design to me:P
I gotta agree there...
... but...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 15, 2008 at 10:38 am
Oh yeah... almost forgot... I recommend that you don't actually use keywords for column names...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 15, 2008 at 10:34 am
Jack beat me to it but I'll post my solution anyway... the reason is that I want you to see an example of how to post information about a table...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 15, 2008 at 10:32 am
Viewing 15 posts - 51,766 through 51,780 (of 59,098 total)