Viewing 15 posts - 55,411 through 55,425 (of 59,072 total)
Just additional info... Foreign Keys must reference either a PK or a column with a UNIQUE index... that not-with-standing, you still can't reference a computed column as a Foreign Key...
--Jeff Moden Change is inevitable... Change for the better is not.
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
August 10, 2007 at 10:26 am
| 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
Viewing 15 posts - 55,411 through 55,425 (of 59,072 total)