Viewing 15 posts - 38,986 through 39,000 (of 59,098 total)
As a bit of a side bar, if you key off the ROW_NUMBER for the DELETE, you can eliminate one full execution of the CTE. Like this...
...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2010 at 7:52 pm
COldCoffee (4/8/2010)
Jeff Moden (4/8/2010)
Sorry... I didn't scroll down to see COldCoffee's solution which is a coded example of what Lutz was talking about.
No issues Jeff... i am infact feeling great...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2010 at 3:44 pm
CirquedeSQLeil (4/8/2010)
Gianluca Sartori (4/8/2010)
WayneS (4/7/2010)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2010 at 2:41 pm
SQLJeff (4/8/2010)
And what about the old CONVERT(VARCHAR(12),GETDATE(),101), will this work in some cases?
Most likely... but the problem with that is as I previously stated... it uses twice as much CPU...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2010 at 7:11 am
Gianluca Sartori (4/8/2010)
Looking at the execution plans, it should not be faster.
Heh... I've run into that many, many times. Perhaps an article titled "The execution plan lies". 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2010 at 7:07 am
Sorry... I didn't scroll down to see COldCoffee's solution which is a coded example of what Lutz was talking about.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2010 at 6:51 am
Kajal123 (4/7/2010)
I am having hard time forming this query to dedulicate - duplicate rows in a table:
select 1_KEY,2_KEY
from MY_TABLE
group by 1_KEY,2_KEY
having count(*) >1
now this query gives...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2010 at 6:48 am
Just to summarize and answer the question being asked right up front...
If you have people that can write good code in either, both Oracle and SQL Server are very, very...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2010 at 6:29 am
And, no... table variables are not logged. That's part of the reason why they aren't/can't be rolled back.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2010 at 5:44 am
Your code points to drive "D". That drive must be on the server and it must not be a "mapped drive". If you want the server to read...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2010 at 5:42 am
miss.delinda (4/8/2010)
tq to all. i'll learn to using Books Online
KO 10Q. Thanks for the feedback. Yeah... these questions are easily answered by looking up key words like "Temp...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2010 at 5:33 am
The "users" own the data but you must assume ownership enough to protect the data even from them. Heh... Perhaps a small poem I heard a long time ago...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2010 at 8:09 pm
lmu92 (4/7/2010)
GregoryF (4/7/2010)
I think you have gone way beyond the scope of someone who asked what the difference between delete and truncate is 🙂 Don't confuse them while they...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2010 at 7:49 pm
miss.delinda (4/7/2010)
1. How many types of temporary tables exist in SQL Server and how is each type symbolized?
2. What is the lifetime and visibility of each type?
3....
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2010 at 7:43 pm
Jason Selburg (4/7/2010)
test for numeric:ISNUMERIC(LEFT(yourFieldName,1)) = 1
Heh... you sure about that ol' friend?
SELECT ISNUMERIC(LEFT('$Howdy',1)),
ISNUMERIC(LEFT(',Howdy',1)),
...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2010 at 7:25 pm
Viewing 15 posts - 38,986 through 39,000 (of 59,098 total)