|
| | | StrataFrame User
 
Group: StrataFrame Users
Last Login: Today @ 6:19:25 AM
Posts: 225, Visits: 1,112 |
| Hi,
I'm recreating test set of tables from an existing database into DDT. We use GUIDs throughout as the PK for each table and I notice the tables created by the DDT all have their RowGuid property set to No whereas the current tables are all set to Yes. The defualt value for the PKs are are to (newid()).In all original tables we set RowGuid to Yes because that, is indeed, what the column is however I not sure what would have happened had we said No. My question is: should I change all the settings in DDT so that all out GUID PK's have a RowGuid value of Yes? TIA - Peter |
| |
| | | 
StrataFrame Developer
Group: StrataFrame Developers
Last Login: Today @ 4:52:53 AM
Posts: 4,586, Visits: 4,571 |
| | Peter, I am sorry but I am confused by your post. The DDT has full support to allow you to create GUID PKs. I do not understand what you are trying to do here. What do you mean by the following statement? We use GUIDs throughout as the PK for each table and I notice the tables created by the DDT all have their RowGuid property set to No whereas the current tables are all set to Yes. |
| |
| | | StrataFrame User
Group: StrataFrame Users
Last Login: Today @ 6:19:25 AM
Posts: 225, Visits: 1,112 |
| | Hi, I probably made my question sound more complex than it should. Let me rephrase it: When I set the primary key for a table definition in DDT to GUID when the table is created in SQL Server 2005 the value for the RowGUID property is set to No. I don't really understand what this property actually does and I would like confirmation that a RowGUID of No is correct. Cheers, Peter |
| |
| | | 
StrataFrame Developer
Group: StrataFrame Developers
Last Login: 09/26/2008 8:30:36 AM
Posts: 2,685, Visits: 1,886 |
| Yes, the setting of RowGuid=No is correct for a GUID pk. The RowGuid is used by SQL Server replication to uniquely identify rows across replicated databases (i.e. you have have two records with the same PK on different servers and when you replicate one database into the other, SQL Server will handle it). So, the RowGuid property of a column is independent from the primary key. Generally, when you use replication and a GUID pk, you can make them the same column.
www.bungie.net |
| |
| | | StrataFrame User
Group: StrataFrame Users
Last Login: Today @ 6:19:25 AM
Posts: 225, Visits: 1,112 |
| | Hi Ben, Thanks for that. Actually this is interesting because the reason we use GUIDs is that the app does support replication. So, in this case, should we be changing the RowGUID value to Yes? Cheers, Peter |
| |
| | |
StrataFrame Developer
Group: StrataFrame Developers
Last Login: 09/26/2008 8:30:36 AM
Posts: 2,685, Visits: 1,886 |
| Replication requires that all tables being replicated have a RowGuid somewhere on the table, so yeah, I would go ahead and turn it on on your PK columns... there's no reason to have another 16 bytes per record taken up by another GUID when you already have one 
www.bungie.net |
| |
|
|