Viewing 15 posts - 58,156 through 58,170 (of 59,067 total)
| I like code to be self-documenting so I know wth I was doing when I have to maintain... |
--Jeff Moden
Change is inevitable... Change for the better is not.
June 9, 2006 at 8:22 pm
Not really... as previously pointed out, the execution plans are identical... and so are their execution times on a quiet non-networked server... here's my test results on a million row...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 9, 2006 at 8:11 pm
This will not find the tables affected by calls to other procs within the proc identified as @objname... but it may do what you ask... and, you get some column...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 9, 2006 at 7:41 pm
Every so often I have to remind myself that starting from scratch may actually be faster in the... |
--Jeff Moden
Change is inevitable... Change for the better is not.
June 9, 2006 at 5:45 pm
Does anyone have a Microsoft link or know the lookup in BOL that says that Temp Tables are logged (or not?). I know there is a log file associated with TempDB...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 9, 2006 at 7:37 am
A bit oversimplified on my part put if you have 4 working stored procedures, why not just use UNION ALL to convert it all to a single record set?
SELECT yada-yada
...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 9, 2006 at 7:34 am
My appologies, Lorna... I did think you were being sarcastic... glad you figured it out and thank you for the courtesy you intended. Ian is correct... we had no way...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 8, 2006 at 4:59 pm
It's a forum... not an instant help button. Your impatience may have cost you a great answer from one the good folks on this forum... we all work regular jobs...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2006 at 8:58 pm
Both Temp Tables and Table Variables start out in memory and both spill into TempDB when they get big enough... there are many other differences, as well...
http://support.microsoft.com/default.aspx?scid=kb;en-us;305977&Product=sql2k
...draw your own...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2006 at 8:46 pm
Sure... no problem...
OSQL -SwSRVR01 -E -Q"set nocount on select name from sysobjects" -n -h-1
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2006 at 5:23 pm
Doh! The simplest answer is usually the best and the most elusive... that'll sure do it, Tim! Good thinkin'
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2006 at 8:06 pm
Nice job Lowell,
Small correction, though... the switch to turn off the header and the dotted line is -h-1 and not just -h1.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2006 at 5:31 pm
Check the size of TempDB on both servers.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2006 at 5:19 pm
Checking with the DBA revealed that there had been instances where temp tables remained after the end of... |
--Jeff Moden
Change is inevitable... Change for the better is not.
June 5, 2006 at 8:14 pm
Thanks dee-oh-gee... little hint... document as you go and you'll never get behind.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 5, 2006 at 8:02 pm
Viewing 15 posts - 58,156 through 58,170 (of 59,067 total)