Viewing 15 posts - 52,996 through 53,010 (of 59,091 total)
First, it's not likely that we'll actually be able to see the document on your "C:" drive.
Second, you haven't explained what you want the proc to do.
Third, if you want...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 7:41 pm
Even in SQL Server 2000, there is no need to engage any systems tables to figure out if an object exists...
IF OBJECT_ID('someobjectname','xtype') IS NOT NULL
... object exists ...
ELSE
... object does...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 7:36 pm
Careful... that's only guaranteed to work correctly if one of two things happen...
1. You have a rock solid clustered index on the correct columns and you have an "anchor"...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 10:24 am
Including name in the sub-query will not guarantee unique SSN's. 😉
Still, I'd like to know... not that I'd do it with a Temp Table, but what's so important about avoiding...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 7:31 am
By the way... there shouldn't be a header on fixed width output...
... and, contrary to what's been said, BCP makes a nice fixed width output if you use a format...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 7:16 am
Michael is correct, as well... if you create a temp table in a nested proc, the outer proc will not be able to see it. If you create a...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2008 at 4:46 pm
Ramesh (1/9/2008)
Thank you very much for ur response...Without temp Table is it possible?..
can u plz explain me
Why do people always ask that? What's so poison about temp...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2008 at 7:39 am
Just in case you want to know why Matt says the performance will suck...
http://www.sqlservercentral.com/articles/T-SQL/61539/
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2008 at 7:36 am
Andrew Terwiel (1/9/2008)
Also, derived tables have lower overheads in comparison to temporary tables.
Not really... both are formed in memory if there's room and in TempDB if not...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2008 at 7:23 am
Better than that, correctly designing a normalized table would go a long way 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2008 at 7:21 am
Thanks for the tip, Jan...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2008 at 7:14 am
Which DBCC command did you execute?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2008 at 7:12 am
Each new query window creates it's own connection or "session" to the database.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2008 at 7:08 am
True enough... but for planning purposes, it does count towards the max of 8060...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2008 at 1:56 am
Heh... you didn't read the OP's request... he wants the total disk size as well. xp_FixedDrives does not provide that information. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2008 at 12:45 am
Viewing 15 posts - 52,996 through 53,010 (of 59,091 total)