Viewing 15 posts - 57,016 through 57,030 (of 59,101 total)
Oh noo, no, no.... go look at Master.dbo.sp_SpaceUsed and "steal" code from that... do it in a set based manner so that you can create a view like an Information_Schema...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2007 at 8:22 am
Hey Micheal! Welcome aboard! Have seen lot's of your posts on the "other" forum... glad to see another intelligent person come on (well, except for the cursor ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2007 at 6:27 am
And, do a ...
SELECT COUNT(*)
FROM yourtablename
... to find out how many rows it's really looking at...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2007 at 6:21 am
p.s. Lookup QUOTENAME in Books OnLine if you need to do lot's of stuff like this...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2007 at 6:06 am
Alot... the very first '+ is followed on the next line by a single ' which ends the string literal which is followed by CASE so SQL Server see's it...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2007 at 6:04 am
If you have a number of these kinds of calculations to make, you may want to make a calendar table. Many different examples on SQLServerCentral... do a search. Well worth...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2007 at 9:57 pm
You'll need one CASE per column returned... sounds long but runs very fast.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2007 at 9:53 pm
Heh... Even in the "higher priced spread" of Oracle, you have to TRUNC(somedate) to get the date with no time (midnight, really).
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2007 at 9:50 pm
Both methods are identical in execution plan, performance, and resource usage.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2007 at 9:38 pm
Then you have to use Rob's method... triggers are absolutely oblivious as to what the source of information is so far as table name goes.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2007 at 9:33 pm
The "t" prefixed "indexes" are not "real" indexes... they are merely notations to the server that the table contains image or text datatypes...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2007 at 9:22 pm
Actually... there is a way... if you look in Books OnLine, the syntax for creating a stored procedure is....
CREATE PROC [ EDURE ] procedure_name [ ; number ]
[...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2007 at 9:17 pm
--===== Create a test table to demo the problem with...
SELECT '11AA' AS AccountID, CAST('01/01/2007' AS DATETIME) AS MyDateTime
INTO #MyHead UNION ALL
SELECT '11AA','01/02/2007' UNION ALL
SELECT '11AA','01/03/2007' UNION ALL
SELECT...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2007 at 9:10 pm
Not after a couple of days... unless you have a really good audit log.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2007 at 8:57 pm
's'ok... great minds think alike... I went a little nuts with the derived table thingy, though ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2007 at 8:52 pm
Viewing 15 posts - 57,016 through 57,030 (of 59,101 total)