I made the following changes to make this work can you please add to your code so I dont break at next update? or let me know how and what you want to change so I dont get a suprise next update

Thanks

Paul

To Business layer I added this Property. (with a private as well)

''' <summary>

''' Gets or sets a value that determines whether the primary key for this business object is

''' a RowGuid

''' </summary>

''' <value></value>

''' <returns></returns>

''' <remarks></remarks>

DefaultValue(True), _

Description("Determines whether the primary key for this business object is a RowGuid.")> _

Public Property PrimaryKeyIsRowGuid() As Boolean

Get

Return Me._PrimaryKeyIsRowGuid

End Get

Set(ByVal value As Boolean)

Me._PrimaryKeyIsRowGuid = value

End Set

End Property

And in Data Layer

In method BuildUpdateInfo aroung line 573

'----------------------> Paul made a change the code here from

'--this

'-- Add the pk field to the fields to update if the primary key if not

' auto incremented

' If Not Me._BusinessObject.PrimaryKeyIsAutoIncremented Then

' loInfo.Fields.Add(lcFieldName)

' End If

'---> to

'-- Add the pk field to the fields to update if the primary key if not

' auto incremented or Row-Guid

If Not Me._BusinessObject.PrimaryKeyIsAutoIncremented AndAlso Not Me._BusinessObject.PrimaryKeyIsRowGuid Then

End If

Thats what I thought as well but excluding the PK from the fields to update causes another exception to be thrown as then the business object thinks there is no primary key

I for one think it may be a good idea for the SF team to have an empty extension layer for all SF objects and the New Items Wizard  use those objects and we could code against that layer if necessary and a migration tool later could verify that the New SF works with the current SF Extensions.   Just a thought and probbaly not thought all the way through.

There are cases in the User Control extensions that Strataframe had to be changed to accomodate an extension layer due to scope ( it's been awhile since I have been in that area so specifics escape me right now ).

Richard

Yeah I tried that first but it complains that there is no Primary Key Field. It makes sense once you step through that method why it doesn't work. PrimaryKeyNotUpdatable work's just let me know what ya end up doing.

Thanks

Paul

 loInfo.FieldDbTypes(loInfo.PrimaryKeyFields(0)) check to work with GUID's.  

Then maybe the PrimaryKey GUID of NewID() from the Database might work?

Richard

I'm not using the newid() function to populate the Primary Key. I am handling the population of the Pk in my base business object by creating a sequential guid. 

The problem I am having here is that I am using replication and it requires one column to be a rowguid, because my primekeys are guids I also use them as rowguids, Rowguids cannot be updated and must be excluded from the update query.

Rich

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

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

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

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

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.

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

Richard

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