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

Hi Richard,

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

Hi,

Any other comments?

Understood,  I thought that by using replication that you wouldn't be using a Sequential GUID as different replication sources wouldn't be sequential.   Makes sense then.

Rich

Hi 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.

Wouldn't setting Me._BusinessObject.PrimaryKeyIsAutoIncremented = TRUE work? I think you'd have to change the 

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

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

Richard

Ben,

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

Paul, did you try adding the PK field name to the FieldsToExcludeFromUpdate?  That should do the same thing... if it doesn't then yeah we'll probably add a field called PrimaryKeyIsUpdatable (so it handles more than just RowGuids).

Instead of putting in Strataframe code we built an extension layer for the BusinessLayer and Data Layer and simply use those objects when creating Business Objects so there is no compatability issues.   You could try that...

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

Chan,

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