Entendi, faz sentido desde o início. Eles provavelmente anotaram sua observação logo no primeiro post, e provavelmente vai ser revisto para o futuro...

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.

Ivan... Boa Noite...

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.

Rogério Mauri

---

Olá Rogério.

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.

This problem continues in version 1.6.6.

Rogério Mauri

---

Ok... I suggest then only the correction in the DDT to prevent the duplicity in the assistant of update of security tables.

Rogério Mauri

---

We have started implementing the auditing (which will be fully released before long).  So even though these tables are being imported, they aren't necessarily being used yet (through the 1.6.5 release).  But having them there will not hurt anything.  That is why you see the SFSAuditEvents table in the imported package file, but we have not yet released the framework side that allows you to interact with that table.  Hope that makes sense.

Olá...

Rogério Mauri

---

Hmmm...I am not sure out you ended up with two tables of the same name...I will see if I can reproduce.  The easiest thing would be the following though:

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.

Image...

Rogério Mauri

---

Olá...

Rogério Mauri

---