Viewing 15 posts - 57,016 through 57,030 (of 59,098 total)
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
Of course, if you used any one of a thousand or so set based solutions for this problem, you wouldn't have to worry about what a cursor does or doesn't...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2007 at 8:41 pm
01/01/1900 was also a Monday... kind of convenient, too, because the decimal equivelent for that date is "0".
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2007 at 8:24 pm
Be a bit leary of queries that have an inequality in the WHERE clause especially when a self-join is also present as it may form a "triangular join" which is a...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2007 at 8:12 pm
Viewing 15 posts - 57,016 through 57,030 (of 59,098 total)