1. Manually remove the SFS tables and views
2. Manually remove the Security related Deployment Data items in the Deployment Data section
3. Now...and this is an important step...select the Object Name History and delete the SFS table name deletions from the Object Name History so once we import them back in they will not be deleted
4. Now, Select the Profile -> Add Security Tables menu
5. Once this is done, click on the Deployment Data node and then click the Deployment Data Package Wizard button
   
   
   
6. Then go through the standard motion of bringing in the Security data for the desired project.

When you rebuild your package, you should be good to go.  Since we now have the Data Verification process, any tables accidentally left in the Object Name History that could cause problems will be brought to your attention.  If you get a clean bill of health once built, you are good to go.

Just out of curiosity... why are you running the wizard and adding the security tables into your DDT project over and over again? Once the structures are added, you don't need to it again. If you want to do it though, delete them first, and go to the History and delete them from there too. Then you can add again. But I don't know why you need to do that every time.

If you add Permissions, Users, Roles, etc into your Security project and want to deploy them, you don't need to add the structures again. This is done through the Deployment Data node on the DDT.

Abraços.

No lançamento da versão 1.6.5 houve uma alteração na tabela 'Users' com a inclusão do campo 'us_DisplayName'. Daí, a necessidade de reimportação das tabelas do módulo de segurança.

Existe, de fato, a possibilidade de exclusão, limpeza do histórico e nova importação das tabelas, no entanto, em algumas situações, criamos relacionamentos entre a tabela "users" e outras tabelas de cadastro para vincular o código do usuário autenticado ao registro adicionado. Então, se excluo as tabelas, depois preciso recriar todos os relacionamentos.

Considerando que o DDT permite nova importação das tabelas de segurança, mesmo estando elas já importadas, seria conveniente então criticar esse processo não permitindo essa situação, pois do jeito que está (faça você mesmo o teste) a rotina indicada pelo DDT como 'update' na verdade duplica as tabelas de segurança e ainda gera outros erros. Não sendo possível o 'update' de fato, sugiro criticar o processo de importação, quando este já ocorreu, com uma mensagem de erro tipo 'Se deseja fazer nova importação das tabelas de segurança, exclua manualmente as existentes no projeto e limpe o histórico de atualização'. Nesse caso, um alerta também poderia anunciar que eventuais relacionamentos criados com essas tabelas seriam perdidos.

Abraços.

Eu só queria me certificar de que você não estava adicionando as estruturas várias vezes em função de alguma alteração no seu projeto de segurança. Mas ficou claro, você está certo.

Valeu.