Viewing 15 posts - 22,471 through 22,485 (of 59,072 total)
Heh... every time that I've deleted legacy data, even stuff over 5 years, someone finds a reason to "need it back NOW!". I don't delete. I "archive" on...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 14, 2014 at 10:00 am
dan-572483 (7/14/2014)
I seem to recall in previous exams having at least 100 minutes to answer 45 questions - well over two minutes per question.
]]
2 minutes and 13 seconds doesn't seem...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 14, 2014 at 9:57 am
I believe that there's an SQL Task, isn't there? Why not just skip the proverbial tower of Babel and call a stored procedure?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 14, 2014 at 9:55 am
GilaMonster (11/14/2014)
sql_er (11/14/2014)
The main goal at the moment is to ensure that when a monthly report goes out we can get the data out fast.
Then stop wasting your time looking...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 14, 2014 at 9:00 am
PearlJammer1 (11/14/2014)
We cannot use temp tables either because the 3rd party vendor doesn't allow it for some reason.
Heh... I'm always amazed but such things. What they don't realize is...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 14, 2014 at 8:53 am
For starters, both queries miss nearly a full second of the day identified in the WHERE clause. Use the following, instead.
(TBL_1.DateTime >= '11-01-2014 09:00:00' AND TBL_1.DateTime < '12-01-2014...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 13, 2014 at 11:14 pm
aarionsql (11/13/2014)
DECLARE @t table...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 13, 2014 at 11:04 pm
Perhaps it's not even an LDAP limit. Perhaps it's as simple as a DOS buffer limit, which can be easily overcome though the use of the ancient, largely unknown,...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 13, 2014 at 8:56 pm
I'm not sure what you're talking about. I use OPENQUERY for sometimes millions of rows all in one shot. There's something else going on for your problem. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 13, 2014 at 4:40 am
Steve Jones - SSC Editor (11/12/2014)
Eric M Russell (11/12/2014)
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2014 at 5:54 pm
TheSQLGuru (11/12/2014)
Be careful. Recursive CTEs can be DREADFULLY poor performers!!
Absolutely agreed!
How many rows are we talking about here?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2014 at 4:12 pm
Grant Fritchey (11/11/2014)
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2014 at 4:08 pm
dndaughtery (11/11/2014)
Turns out I was able to speed it up by looking at the query plan and adding some indexes.
How fast is it now?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2014 at 4:05 pm
I have no idea but sounds very interesting. If nothing else, this reply will serve to "bump" this interesting question.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2014 at 3:57 pm
SQLJocky (11/12/2014)
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2014 at 3:16 pm
Viewing 15 posts - 22,471 through 22,485 (of 59,072 total)