Apos os testes no momento da criacao e todos eles executados com sucesso, prosseguimos com alteracoes no formulario de inclusao e comecamos a testar as novas alteracoes, percebemos que triplicava o solicitante e solicitado, mas a solicitacao estava apenas com um regsitro.revimo todas as alteracoes e concluimos que o problema estava no BD, assim ao analisar mais atentamente a trigger vimos que:Ela disparava a cada insert e update na tabela solicitacao.A trigger SOLICITACAO_AI1, tinha duas linhas com update.Assim o insert mais os dois updates na mesma tabela SOLICITACAO, tratando do mesmo registro geravam os registros triplicados na tabela SOLICITANTE e SOLICITADO.Pensei em:Desmembro o SOLICITACAO_AU2 em:SOLICITACAO_AI2 para o solicitante.SOLICITACAO_AI3 para o solicitadoSOLICITACAO_AU4 para a atualizacao do solicitado, reparem que AI2 e AI3 e apenas um Insert Into Select e o AU4 e um UPDATE.O unico tipo de solicitacao que pede isso e a substituicao, assim se pensarmos em cobertura da substituicao resolveriamos esse impasse e nao teriamos que ter um UPDATE pois, o solicitante nao tera o seus dados alterados na solicitacao em hipotese alguma, o solicitado apenas quando encontrar o respectivo que e necessarioa a alteracao da solicitacao.Assim sendo nao preciso nem desmembrar, basta eu mudar a trigger para nao disparar a cada insert e update, disparando apenas no insert, e show, mas preciso saber com o cliente se criar mais uma figura de solicitacao nao teriamos problemas.Afastamento temporario, Licenca Gestacao, Licenca Maternidade, Acidente de Trabalho, Acidente Trajeto, Descanso Anual, tem seus solicitantes nos tipos CoberturaAusencia comunicada pelos setor, Incidente na Afericao de Producao, Revisao de Pro-labore, e demais solicitacoes nao tem solicitado.A troca tem o solicitado no momento da inclusao logo nao cabe alteracao.Todo esse problema apenas pela solicitacao,Mas se o solicitado vier numa segunda etapa, ou seja, sempre com um tipo distindo de solicitacao eu acabo gerando um retrabalho desnecessario para o usuario, pois ele tera um tipo distinto de solicitacao sempre. Pode nao ser uma ma ideia, vamos amadurece-la, assim esconderemos os campos solicitante e treinamento dos tipos que nao interessa e habilitaremos nos tipos pertinentes.Pensei ate em tirar SOLICITANTE e SOLICITADO da tabela SOLICITACAO, mantendo o protocolo como vinculo entre as tres tabelas, mas vou insistir na primeira ideia ainda e depois analiso se terei vantagens nessa mudanca. Estou pensando em fazer um esquema mestre / detalhe para que em apenas uma solicitacao seja possivel a inclusao de mais de um pedido. Ex: nota / itens da nota.Preciso uma nova abordagem para Grupo de Empresas e Grupo de Folhas, que vai fazer com que tanto o CONSOLI quanto o FOLHA precisem de varios ajustes.Preciso criar um controle com historico para funcao, producao, previsao Pensei em alterar a forma com que a aplicacao lida com as solicitacoes, dando a possibilidade de exclusoes http://www.comunidade-firebird.org/cflp/downloads/CFLP_T004.PDFhttp://ich.pro.br/downloads.php replicacaohttp://www.cria-arquivos-exportacao.intesoft.com.br/ exportacaohttp://www.software-replicacao-dados.intesoft.com.br/ replicacaoPreciso criar uma tabela acao com um tabela de busca tipo de acao para saber quais sao as acoes que estao sendo tomadas a partir do comunicado do cooperado. ex. encaminhado ao DRH, em analise, pagamento autorizado, pensar em varias acoes referentes aos tipos de solicitacoes.ainda preciso elaborar uma tabela retorno ou feedback para