I have deployed the RBS to one of my customer and everything is good. Now I am creating more forms and new Permissions and want to update customer with those new permissions and the DDT cannot find the correct permission records at the customer database to be updated.



The problem is that the pm_pk field value at the customer does not match with the pm_pk field value in my StrataFrame database. I believe what happened was that at some point during test, the customer database was TRUNCATEd and then new pm_pk values where auto-generated when security was deployed causing the customer and mine security databases to be out of synch.



So my question is: what is the DDT deployment is using to properly identify the record and do its merge?

In this particular case, for the SFPermissions table, the pm_Key should be the primary field or at least the key field used by the DDT to deploy the data and avoid the problem I am having now. If that is not the case, can you please explain the following:

1.- How is the DDT Data Deployment logic works?

2.- How can I fix my current problem without having to have to recreate all my customer's security configurations for each user?



Thanks!

Edhy Rijo

Also, just for clarification, I am looking for the correct Merge Type to use when deploying the RBS data to my customers. When using the DDT wizard, it will set all MergeType to "Overwrite" which may not be the desired case when taking into consideration that the only information the End User (the Customer) cannot change is the "Security Permissions" data, so "Overwrite" will simply wipe out all customization done by the End User.



I am testing with the following Merge Types (see attached image)

Security Roles - Ignore (So I can add some new Roles and be able to deploy those)

Security Permissions - Overwrite (This is a must to keep in sync with development)

Security Users - DeployIfTableEmpty (Should always be done by End User)

Security Users XPermissions - DeployIfTableEmpty (Should always be done by End User)

Security Preferences - DeployIfTableEmpty (Should always be done by End User)

Security Context Restrictions - DeployIfTableEmpty (Should always be done by End User)



I would appreciate if somebody with experience deploying RBS in production database can confirm/correct my assumtions.



Thanks!

Edhy Rijo