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...

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...

Just a list or to generate the actual code to create the constraints?

Also, why do you want to do this?  Might be important...

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...

Nope... glad to see someone else thinks the same thing, Jacob.

You don't like the idea of SELECT 1 instead? 

Heh... nothing breaking is good

Good catch, Lowell...

I've seen it where the view totally recalculates for each individual update... kinda drags performance down a bit

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

Nicely done... but, what if it takes 6 numbers to make the desired total?

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...

Heh... forget PayPal... UPS will ship a keg

I don't have access to 2k5, yet, Michael... did they keep the information schema views named the same way?

Heh... yeah... Just look for anything that uses MAX(somecolumnname)+1 or @@IDENTITY in the code.  If the aren't "in sync", it'll cause Primary Key violations which is the error you're getting.

Also,...

I'd also like to throw my hat in the ring with the others that expressed some disappointment in certs... or rather I should say in some of the people that...