Post the code, Will...

Hey, Phil...

I just went back and read my reply about testing it... it sounds a lot sarcastic and I didn't mean to make it sound that way.  Hope you took...

Ya beat me to it, John.

Now, there's some common sense thinking outside the box... thanks, Lowell.

No, no... he's not miffed... it's a bit of a language barrier thing and, because of that, he comes off as being short...  He's really trying to help you think...

Thanks, Lynn...

Heh... I don't have 2k5, either... was going on someone else's word... thanks.

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

I have a table which contains a date field which is a string with format 'yyyymmdd' ...

It's almost...

I don't think so... foreign keys don't automatically make indexes like Primary Keys do.  They make excellent candidates for indexes, though.

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

The only thing you can pass to a function are scalar values... can't pass a query.

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