December 2, 2010 at 1:52 pm
:cool:I am giong to get my point I lost back!;-)
December 2, 2010 at 1:57 pm
BowieRules! (12/2/2010)
I am sorry for confusing you with insert option, I only included it here because I found it on another blog as a solution to the problem, which I agree is not really a solution, but still a valid workaround, especially if it is put in a good InsertUpdate stored procedure.
This is not an administrative workaround and will not enforce the contraint from a DBA perspective.
It would not pass an Audit either. The other solutions listed would.
:cool:I am giong to get my point I lost back!;-)
December 2, 2010 at 1:59 pm
:cool:I am giong to get my point I lost back!;-)
Am I being greedy?
December 2, 2010 at 2:27 pm
SanDroid, I was wondering when you were going to show up;-)
(I need to get mine back as well:hehe:)
Steve Jimmo
Sr DBA
“If we ever forget that we are One Nation Under God, then we will be a Nation gone under." - Ronald Reagan
December 2, 2010 at 2:54 pm
Got it right by fluke, but still trying to figure out how this one would resolve the issue:
Create a calculated column that is based on the column that allows nulls, and then define a UNIQUE constraint on the calculated column.
SQL DBA.
December 2, 2010 at 3:00 pm
SanjayAttray (12/2/2010)
Create a calculated column that is based on the column that allows nulls, and then define a UNIQUE constraint on the calculated column.
Sanjay, Some of the more creative minds at M$ actualy list this and how to do it as a solution to this "documented limitation" of TSQL RDBMS servers in a Q article.
http://support.microsoft.com/kb/322002
The solutions provided in this article are the only ones supported by M$.
ummm... Or at least that is the word on the street.... 😎
:w00t:Still getting my POINT back:w00t:
December 2, 2010 at 4:31 pm
The statement "I found it on another blog as a solution to the problem" worries we. Just because someone says something, especially on the internet, doesn't mean it's correct. As many have pointed out previously, enforcing something in the app isn't really enforcing anything at all, because as soon as someone uses a different app there's no enforcement at all.
(I'd also be very amused to watch how that "solution" scaled as the number of rows increased, unless I had to support it that is).
December 2, 2010 at 5:34 pm
Well, as has been pointed out already the 5th "correct" option doesn't handle update statements at all and even for inserts it handles only single row inserts.
Nevertheless, it's a good question (despite that flaw in the answer) because it's thought-provoking. And I don't imagine I'm the only one who wasn't previously aware of Hugo's connect item and added a vote as a result of this, so with some luck the question has added a few votes that may help MS realise that this is a serious issue.
It raises an interesting side-issue: how bizarre does a "work-around" have to be before it ceases to count as a real work-around. I guess any answer to that is going to be subjective. For myself, I reckon a filtered index is a good work-around, and a trigger is a passable work-around. But I'll go along with an earlier comment about the computed column solution - why do I want to invent some weird imaginary column to do something that the SQL standard says I can do without it? It works, of course, but I don't like it one bit. Neither do I like the indexed view work-around, although of course that too works; but confusing an index (an access mechanism) with a view (a derived relation) seems to me to be a step too far from the relational model.
Tom
December 2, 2010 at 10:51 pm
This question seems dubious. 5 required correct answers and only worth 1 point?
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
December 3, 2010 at 1:40 am
Hi,
It is always hard to get the right answer for this kind of question. There is more probability that you will miss at least one point.
So I think rather then giving 8 options together in 1 question, it should be distributed to 2 to 3 questions and then it would be better justice.
Regards,
--------------------------------------------------------------------------------
Mayank Parmar
Software Engineer
Clarion Technologies
SEI CMMI Level 3 Company
8th Floor, 803, GNFC info Tower,
SG Highway, Ahmedabad - 380 054,
Gujarat, India.
www.clariontechnologies.co.in
Email: mayank.parmar@clariontechnologies.co.in
MSN : mayank.parmar@clariontechnologies.co.in
Mobile: +91 9727748789
--------------------------------------------------------------------------------
December 3, 2010 at 1:56 pm
Thanks to everyone for the discussion, I knew the WHERE clause wasn't a real work-around...
December 6, 2010 at 9:29 am
UMG Developer (12/3/2010)
Thanks to everyone for the discussion, I knew the WHERE clause wasn't a real work-around...
I'm with UMG on this one. Besides the quibble that the WHERE clause option didn't include UPDATEs, it is still a possible "workaround", even if impractical.
The question was simply "what is a workaround for this?", not "what is a workaround which won't get you fired or laughed at?"
December 15, 2010 at 5:02 am
Its depends on requirement,any one will not always correct...
January 5, 2011 at 5:16 am
If we want to talk about workarounds: how about threaten the halfwit who designed/built such a piece of cack and put you in a position where you had to deal with this?
Carlton..
Viewing 14 posts - 31 through 43 (of 43 total)
You must be logged in to reply to this topic. Login to reply