Hi Richard,

That is why I am creating the Guid from within the application so i can keep them sequential

Hi Guys,

I just don't really get the problem. All our PK's are GUID's and defined as RowGUID = True in the table's properties. We set the default for the PK column as (NewID()). In the BO we set PrimaryKeyIsAutoInceremented = False and the replication column (msrepl_tran_version) is included in FieldsToExcludeFromInsert/Update.

And that's it - I've never seen a problem with the CRUD and we do a lot of parent/child/grandchild stuff.

We use DevExpress for our UI.

Cheers, Peter

Peter,

Our scenarios are different ,

I am using the existing Primary Key Column as the (msrepl_tran_version) column I do not have 2 seperate guid columns in my tabe, in this scenario the primary key field cannot be included in the update as replication will complain and if exclude it via the include exclude collection SF complains that there is not a PK.  To be honest it did not make much sense to create another guid column for soley for replication when I have a perfectly good one already.

So yes I could make it work by adding another column soley for replication however I don't think that is an answer to the problem as using the existing PK as the replication column is valid way to configure replication.

Paul

Hi Paul,

The documentation on msrepl_tran_version is a bit light on but, in our Push/Transactional replication environment, I've always understood it to be what it says, i.e. "a version number". So, when a row on the Publisher changes it is given a new msrepl_tran_version GUID and the update, along with the new msrepl_tran_version, is eventually propergated to all the subscribers.

I've just checked this and sure enough, in our environment anyway, that is what happens which means, of course, having a seperate msrepl_tran_version column is pretty well mandatory unlesss we cascade updates to the PK every time a change is made to a row in a table.

As far as I'm aware Merge replication works in a similiar fashion but I guess there are other flavours of replication that could well behave differently.

Cheers, Peter

Well, looks like I'll need to include the PrimaryKeyIsUpdatable property.  I'll get started on it and let you know when it's done. 

Incidentally, this probably would have fixed Rob Toyias's issue the other day, too; it had to do with the Oracle PK being passed twice for non updatable PKs.

Thanks Ben that should work!

Peter,

I think what you describe is how transactional replication works, I am using merge replication and it seems to work just fine except for the problem I described. I'm not expert on replication so I could be wrong but from what I've read about merge replication it should work ok.

Paul

I was looking for a way around Stored Procedures for Simply GUID PK based tables.  

Richard

The way around sprocs is by supplying the primary key values for the GUIDs from within the business object (so the primary key is not auto-incremented).  Otherwise, you'll have to use sprocs since there is no way for the non-sproc business object to retrieve the value of the last created GUID.  i.e. if you set newsequencialid() or newid() as the default value of the record.

Ben,

I have a slow day today and before I get back into the swing of things I figured it would be a good time to get 2008 up and running, I was hoping that maybe you had added the PrimaryKeyIsUpdatable property to the release that Trent posted but I don't see it unless you named it something else?

Anyways just wanted to make sure you don't forget to add it to the release that is coming or see if you named it something else.

Hope yall had a good holiday break!

Thanks

Paul