November 15, 2011 at 7:47 am
brazumich (11/15/2011)
Good question, thank you.I will "third" liking your question format. It forces us to actually type the code if we want to cheat that way before answering the question.
Or conversely, if lazy and not feeling like typing, doing research.
Sorry folks, I'm sure all of us have done that at least once - I freely admit that myself.
My point is that you can't answer without reading everything. It seems to twart lots of the usual complaints :-).
November 15, 2011 at 9:01 am
Great question - cheers
November 15, 2011 at 10:14 am
Nice question.
It made me think, briefly, because I was startled by the unnamed single column constraint. I'm so used to writing unnamed single column primary key, unique, reference, and check constraints (and of course default constraints, but they are inherently single column anyway) as part of the column definition that seeing one written elsewhere was a surprise; but after a very rapid reflection realised that as the syntax is available for (unnamed) multicolumn constraints there's no reaon it can't be used for (unnamed) single column constraints as an alternative to including the constraint in the column definition.
From the discussion I learnt that named constraints are allowed on temp tables; that is really awful - table variables have this one right.
Tom
November 15, 2011 at 10:24 am
Very neat -- thank you!
November 15, 2011 at 11:34 am
L' Eomot Inversé (11/15/2011)
From the discussion I learnt that named constraints are allowed on temp tables; that is really awful - table variables have this one right.
Yes, that is awful indeed. I found that out the hard way, when I decided to add "always name constraints" to my list of best practices to follow. I changed some code, tested, then quickly removed the constraint names for the temp tables. For those who never tried - it'll give you errors. If you create a table named #temp, SQL Server will apply some magic to give it a real name that's unique and that maps to the #temp pseudo-name. If you add a constraint named pk_#temp to that table, SQL Server will do no magic at all; it will simply use that constraint name - and give you an error message ("there is already an object named pk_#temp in the database") as soon as a second connection runs the same code before the temporary table from the first connection has been removed.
November 15, 2011 at 5:04 pm
Nice question. Thanks
November 15, 2011 at 5:06 pm
brazumich (11/15/2011)
Good question, thank you.I will "third" liking your question format. It forces us to actually type the code if we want to cheat that way before answering the question.
Or conversely, if lazy and not feeling like typing, doing research.
Sorry folks, I'm sure all of us have done that at least once - I freely admit that myself.
I've no problem admitting that I tried the Declares before answering. If I actually cared about the points, I'd like to think that I would depend on research or prior knowledge and never "cheat" by running the code. A true points-hawk would just answer each QOD a day later, if you know what I mean.
At least I explored my results by trying the variations on a #temp table before submitting my answer, thus burning the distinction into my brain. As with others, I was surprised to see the named constraint accepted in that case.
Anyway, great question and discussion. I really learned a lot more than just which check boxes were "correct".
November 16, 2011 at 2:21 am
Nice question, thanks!
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
November 16, 2011 at 3:23 am
good question!!!
thanks Ron!!!
Viewing 9 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply