Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««34567

Design Expand / Collapse
Author
Message
Posted Monday, September 27, 2010 9:00 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Monday, August 18, 2014 7:25 AM
Points: 989, Visits: 1,823
Agreed Robert, but I have seen cases where people assumed that the IDENTITY was guarding the data for uniqueness and so inserted dupes by mistake, assuming that it would be prevented by the IDENTITY. You have to have the unique constraint to protect against clueless data loaders. Not saying it's smart but it IS real life unfortunately.
Post #993728
Posted Monday, September 27, 2010 10:56 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, June 16, 2014 9:38 AM
Points: 2,163, Visits: 2,189
Robert Frasca (9/27/2010)
Well, I suppose you could do that but that defeats the purpose of using the identity attribute.


No, not if your purpose is just to get a sequential set of numbers in a column by default. I don't think they should have named it identity, I think they should have done something more like they did in Access and call it an AutoNumber field, since that is what it really is. It becomes an identity once you set the primary key or unique index on it. Of course that wouldn't follow the SQL "standard" but neither does Microsoft's implementation of IDENTITY. (However it appears that this is one SQL feature that is commonly implemented differently, if at all.)
Post #993809
Posted Monday, September 27, 2010 11:58 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 4:28 PM
Points: 5,984, Visits: 8,242
UMG Developer (9/27/2010)
(However it appears that this is one SQL feature that is commonly implemented differently, if at all.)

That's probably because all products had already implemented their own syntax for this when the standardisation committee finally decided to forget relational purity and add this commonly needed feature to the standard.



Hugo Kornelis, SQL Server MVP
Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
Post #993879
Posted Monday, September 27, 2010 7:37 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Today @ 5:59 PM
Points: 8,748, Visits: 9,296
The question resulted in an interesting discussion, so I guess it must be a good question. But I like neither the question nor the answer (despite having got it right by assuming that the answer would not only be be as stupid as the rules suggested in BoL but would also so interpret the rules as to maximise the stupidness)
And transactional replication certainly doesn't create any extra columns by magic (at least in didn't in SQLS 2000), and neither does snapshot replication; merge replication may do it (I've never used it, so never read up on it).


Tom
Post #994148
Posted Tuesday, September 28, 2010 4:18 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Monday, August 18, 2014 7:25 AM
Points: 989, Visits: 1,823
Tom.Thomson (9/27/2010)
And transactional replication certainly doesn't create any extra columns by magic (at least in didn't in SQLS 2000), and neither does snapshot replication; merge replication may do it (I've never used it, so never read up on it).


It specifically happens on transactional replication with updateable subscriptions and on merge replication. It is how the system deals with conflicts when two separate sources could in theory get updated at nearly the same time in the same location in the data.
Post #994299
« Prev Topic | Next Topic »

Add to briefcase «««34567

Permissions Expand / Collapse