Yep I know how it is Thanks for getting this in the next build for me.

We'll make sure it is in the build   We did have a good break but we are running as quick as we can trying to catch up...I am sure that you understand how it goes

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

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.

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

Richard

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

Thanks Ben that should work!

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.

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

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