Viewing 15 posts - 38,956 through 38,970 (of 59,072 total)
Build "intermediate" tables to hold the PK's of all rows affected for each table. That will allow you to work unimpeded and without crushing production until you're ready to...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2010 at 8:47 pm
Nuts (4/8/2010)
I have calculated top 20 tests from my table and here is the result
Test_name year
test1 ...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2010 at 8:38 pm
TRACEY-320982 (4/8/2010)
Worked a treat and replaced it anywhere it found it in the string.Thank you so much got a hugh update to do.
What does the 1 mean ?
(CHARINDEX('00001', column, 1)
My...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2010 at 8:36 pm
JDixon-385826 (4/8/2010)
fill factor 80 seems a little low - I would review the fill factor you are most likely cauing more page splits than needed
A low fill factor will prevent...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2010 at 8:15 pm
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
Viewing 15 posts - 38,956 through 38,970 (of 59,072 total)