Deprecated: Since GeneXus 16 upgrade 5.
You can get the error "Repository, Application, Name already exists (BC: 1)(42)" if you try to update permissions that have the same name and different GUID.
Another possible error is No matching 'Application Permission Parent'.(42). 'No matching 'Application Permission Child'
Permissions and roles are identified by a GUID, not by their name; that is, the GUID is the Primary Key of those entities, and the name is a Candidate Key.
If you import roles or permissions which already exist in the repository with the same name, but with a different GUID, they will be considered as different entities. When trying to update them, an error will be thrown because the permission (or role) name conflicts with another one.
Note: If you always perform the export from the same database, this will not happen; this is the practice that should be followed.
1. A scenario where this error can happen is when you create a role or permission manually in the production database, and then create it in the development database. When exporting from development, the role or permission will have a different GUID than the GUID it has in the production database, so they are considered different even if they have the same name.
2. Another scenario is if you lose the development database, and create the permissions there from scratch. When you generate permissions in the KB, all the permissions are populated in the database using an entirely new GUID.
You shouldn't export the permissions from that environment to import them into Production, because of what was already explained.
1. If you manually create roles or permissions in production, export them using the GAM deploy tool, and import them into development, so that they will be defined using the same GUID identifier. On the other hand, if you create them manually in the development environment, they will get another GUID identifier, and there will be conflicts when importing these permissions into production.
2. If you lose the development database, restore the production database into the development database. That's the way to be sure that the permissions and roles keep the same GUID. An alternative is to use the GAM deploy tool to do a full export from production and a full import into development.
The Permissions and roles of the GAM database have a unique name but are identified by a GUID.
The recommendation is to always perform the export from the same database (e.g., development database) to import into the production database.
