Viewing 15 posts - 55,441 through 55,455 (of 59,101 total)
| I have a table which contains a date field which is a string with format 'yyyymmdd' ... |
It's almost...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 10, 2007 at 8:23 am
I don't think so... foreign keys don't automatically make indexes like Primary Keys do. They make excellent candidates for indexes, though.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 10, 2007 at 7:59 am
Pretty sure "OR" can't be used here....
SELECT CASE RowNum
WHEN 1 OR 10 THEN '1 or 10'
ELSE 'Not 1 or 10'
END
FROM jbmTest
WHERE RowNum <=10
Server: Msg...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 10, 2007 at 7:50 am
The only thing you can pass to a function are scalar values... can't pass a query.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 10, 2007 at 7:45 am
I agree... as everyone knows, temp tables live in TempDB. TempDB's recovery mode is set to SIMPLE which uses minimal logging. No performance advantage to shifting temp tables to permanent...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 10, 2007 at 7:42 am
I agree...BOL is incorrect or, at the very least, misleading here... if you use any decimal math against the time portion, you will many times come up with the wrong...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 10, 2007 at 7:31 am
Just a list or to generate the actual code to create the constraints?
Also, why do you want to do this? Might be important...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 10, 2007 at 7:14 am
I could be wrong, but I don't think that anything you do to the hardware or the server settings or indexes is going to fix this one...
As you said, it works...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 10, 2007 at 7:11 am
Nope... glad to see someone else thinks the same thing, Jacob. ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
August 10, 2007 at 6:41 am
You don't like the idea of SELECT 1 instead?
--Jeff Moden
Change is inevitable... Change for the better is not.
August 10, 2007 at 12:11 am
Heh... nothing breaking is good ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
August 9, 2007 at 11:00 pm
Good catch, Lowell...
I've seen it where the view totally recalculates for each individual update... kinda drags performance down a bit ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
August 9, 2007 at 2:30 pm
And, Peter's fine method works not only for single variables, but for a whole table, as well.
SELECT (ABS(CHECKSUM(NEWID())) % 10000) AS RandomNumber
FROM Master.dbo.Syscolumns
--Jeff Moden
Change is inevitable... Change for the better is not.
August 9, 2007 at 2:20 pm
Nicely done... but, what if it takes 6 numbers to make the desired total?
--Jeff Moden
Change is inevitable... Change for the better is not.
August 9, 2007 at 2:14 pm
Yes... don't allow developers to have access to write to production machines. Works for us. Create a new server with snapshots of the production box and use that as the...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 9, 2007 at 2:09 pm
Viewing 15 posts - 55,441 through 55,455 (of 59,101 total)