August 12, 2005 at 10:09 am
I have a table with a nullable column, which must be unique for all of the non-null entries, but it is allowed to have many nulls.
Ideally I would like to enforce this using a unique constraint rather than a trigger. In BOL there are several contradictory entries about this - some say that a unique constraint will only enforce uniqueness for non-null values, whereas others say that only one null value will be allowed.
When I try it out, it seems that it will only allow one null, so it looks as if I will just have to go with the trigger.
Am I missing something?
August 12, 2005 at 11:30 am
Here's a solution that doesn't need a trigger... but I'd test it against the trigger to see which one is faster :
Create an indexed view on that table :
CREATE VIEW dbo.vwTableNameEnforceUniqueColNameHere
WITH SCHEMABINDING
AS
Select UniqueNullableColumn from dbo.YourTable where UniqueNullableColumn IS NOT NULL
GO
Then add the column as the clustered primary key of the view.
The problem with this solution is that you can't costumize the error message like you could in a trigger.
August 15, 2005 at 1:40 am
Unfortunately SQL Server does not implement unique constraints correctly as specified in the ANSI standard. Any entries in BOL that say "that a unique constraint will only enforce uniqueness for non-null values" is not correct and should be sent as feedback to MS to be corrected. That is the way it should work according to the ANSI standard, but as you noted clearly not how it does work in SQL Server.
This KB article discusses some possible solutions for this. I prefer the second solution (using a computed column) because it enables me to create a logical constraint that users can be aware of.
Also see these two old threads for more discussion regarding this:
August 15, 2005 at 2:55 am
Thank you. This has been very helpful.
September 6, 2005 at 2:06 pm
I am having the same problem in an Inventory DB. I use SQL 2000 as the backend with an MS Access frontend on the users desktops that access this data. Problem is: Workstations have an Unique name, but not all are out in the field, so those are NULL. With MS Access, it's cake to index (No Dupes) required = No and allow Zero length. Grrrrrrrrrr Now today with SQL 2000 I am hit with this problem and now have spent about 6 hours trying work arounds!
The Question was asked to me. Is this going to be a "new" enhancemnt in sql 2005? Maybe it will go back to allowing Nulls, but also checking the existing data for unique?
Thanks,
Chris
September 6, 2005 at 2:30 pm
The Question was asked to me. Is this going to be a "new" enhancemnt in sql 2005? Maybe it will go back to allowing Nulls, but also checking the existing data for unique?
No, SQL Server 2005 works like SQL Server 2000 in this aspect. For workarounds, see the solution posted by Remi above or the KB article I referenced.
September 6, 2005 at 2:32 pm
Remi = rgR'us .
September 6, 2005 at 2:41 pm
I'm just trying to force you into changing your nick back.
September 6, 2005 at 2:44 pm
Not gonna happen .
September 6, 2005 at 9:22 pm
i was wondering how this new guy was beeting Remi to the punch/post; must be that Remi-bot we heard so much about.
Seriosuly, thanks for all your contributions Remi/rqR'us
Lowell
September 6, 2005 at 9:25 pm
There's an actual meaning to that name... care to take a guess?
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply