Viewing 15 posts - 41,266 through 41,280 (of 59,069 total)
It would be nice but, nope... you're pretty much stuck with a start and end record.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2009 at 8:37 pm
Chances are... it's not the SELECT that's causing the problem. It's some user or developer that began an explicit transaction, did a SELECT (which explains the read uncommited thing)...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2009 at 8:35 pm
Bridget Elise Nelson (11/5/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2009 at 8:29 pm
Dr.D (11/5/2009)
Please, It is urgent
That's quite possibly the worst thing you can say on these forums. Because of all the people that say that because the real urgency...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2009 at 8:14 pm
bwilliams-1049831 (11/5/2009)
a select statement into a table variable and passing the table variable back to the calling program
You can gain quite a bit of performance if you make sure they're...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2009 at 8:09 pm
You didn't LEFT JOIN properly. It should be...
SELECT t1.id as id1, t1.name1 as name1, t2.name2 as name2, t3.name3 as name3
FROM test1 t1
LEFT JOIN test2 t2 ON t1.id =...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2009 at 8:04 pm
Just keep in mind that no trick will keep the DBA from accidently TRUNCATEing the table. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2009 at 7:59 pm
SELECT *
FROM table1
WHERE StartDateTime >= @StartDate
AND StartDateTime < @StartDate + 1
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2009 at 7:50 pm
If you use James' good tried'n'true method, be sure to save a bit on performance and use UNION ALL instead of just UNION. UNION does a "Distinct" in the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2009 at 7:48 pm
In that case, I think a Cursor might be a wee bit tough on resources... doing 50,000 separate updates is going to require some CPU time and some IO time......
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2009 at 7:20 pm
I can't take anything away from the article... the author did a nice job on it. Well done.
I do, however, agree with some of the others... SELECT * is...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2009 at 6:32 am
sorte.orm (11/5/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2009 at 6:25 am
Heh... actually, that's a great addition, MBN. Lots of folks forget that knowledge is ability and without the knowledge, you may not have the ability... that's the whole purpose...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2009 at 6:15 am
Ah... now that's a horse of a different color. You'll still have many of the problems I and others have spoken of but I'm with you... take anything they're...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2009 at 5:59 am
Mazharuddin Ehsan (11/3/2009)
create procedure..
select
sysdate + cdays
....
from oracletable
Thank you
sysdate cannot be fetched from 'oracletable' :w00t:
Sure it can... SysDate can...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 4, 2009 at 10:56 pm
Viewing 15 posts - 41,266 through 41,280 (of 59,069 total)