jeff.mason (9/24/2010)

---

Robert Frasca (9/24/2010)

---

jeff.mason (9/24/2010)

---

sjimmo (9/24/2010)

---

Quoting BOL (gasp) again (from the uniqueidentifier TSQL reference article):

I use replication heavily in our stores, to move high priority data back and forth with HQ. I personally have not had to use UNIQUEIDENTIFIER in any of the tables I have replicated, but do have to have a PK, which would be unique. If I use the GUI to create my publication, it will not allow me to select any table without a PK, and if I run a script without a PK, it gives me an error. Is this a new requirement of SS2008?

It happens under the hood, and always has AFAIK. If there isn't a uniqueidentifier replication will add one to every table on the system and if replication is deleted, the column will be dropped as part of removing replication.

Actually, that's a "uniqueifier" not a uniqueidentifier. A uniqueifier is a 4-byte column added to make a primary key unique.

That's not how BO seems to indicate it. From BO:

"A column named rowguid is added to each published table, unless the table already has a column of data type uniqueidentifier with the ROWGUIDCOL property set (in which case this column is used). The rowguid column is used to uniquely identify every row in every published table. If the table is dropped from the publication, the rowguid column is removed; if an existing column was used for tracking, the column is not removed."

Granted, it doesn't tell you the data type of rowguid but from that and the name I always assumed it was a uniqueidentifer as well.