Ajuda com bloco VII

[Ramon Lopes]

Olá. Preciso de uma idéia.

Estou Me debatendo com o arquivo de movimentos por ECF. Ocorre que nos testes precisamos manipular os campos que servem de chaves PK/FK. Exemplo: se eu mudar o CRZ perco a ligação com os cupons dessa ReducaoZ. Como vcs tem contornado isso?

[Régys Silveira]

Eu tenho visto o pessoal fazer de duas formas:

- Não utilizar os campos que são modificados como chaves.

- Ter tabelas para cada um dos registros R com os campos necessários e chaves próprias.

[Ramon Lopes]

Vou fazer o seguinte: vou duplicar os campos chave ex: CRZ: vai ter uma coluna chamada CRZ e outra chamada REDZ_KEY. Na query p homologar, usarei CRZ, e nas ligações uso REDZ_KEY. Só vou tomar o cuidado de gerar o arquivo com a coluna alterada, p poder passar no teste.

[Ramon Lopes]

Me ocorreu outra solucao: Colocar as chaves FK com a regra de "ON UPDATE CASCADE", isso resolveria tudo... so que alteraria em cascata em todos os "R"s nao sei se isso seria permitido, se for esta resolvido... Acabei de mandar um email ao homologador e vou ligar cedinho p ele, depois posto aqui.

[Juliomar Marchetti]

Segundo o homologador, desde que faça o que está solicitando não tem problema se for chave pois vai mostrar o registro errado.

[Ramon Lopes]

Ola Juliomar... Acontece que ao alterar o R01 por exemplo, automaticamente se alterariam as chaves de R02,R03,R04.... pois seria em cascata.... a principio essa seria a duvida. Assim que tiver uma resposta da polimig eu posto aqui.

[Régys Silveira]

Quando homologuei na Polimig/BH eu fiz cascata com as chaves, e na época o homologador não criticou isso, ele disse que não tinha problema desde que ficasse evidenciada a mudança.

[Ramon Lopes]

Acabei de conversar com o Deynison, da Polimig/MG - realmente pode ser em cascata, desde que seja evidenciado o item que foi alterado, e que nao "sumam" registros qdo alterado o serial, coo, crz, etc.... tranquilo.

[ornei]

Boa tarde, colegas.

 

Gostaria de reviver este fórum, validação dos registros EAD.

 

No caso de chaves estrangeiras (FK) como os colegas estão tratando as alterações?

 

Exemplo:

 

No teste que devemos altear a unidade de um item do DAV (registro D3). Na minha tabela de itens do DAV eu não tenho este campo explicitamente, mas sim uma chave estrangeira que faz referencia com a tabela de unidade de medida, onde fica armazenado a sigla da unidade.

 

A princípio pensei em controlar as alterações na tabela de unidade também, sendo assim alterando a "unidade" da tabela de unidade, apareceria a "?" no registro D3.

 

Mas aí vem o problema. Existem outras tabelas que fazem referência com a tabela de unidade (como a de produto), com isso,

a alteração acima, feita para atender aos testes do registro D3, iria afetar outros registros como é o caso do P2 , E2.

 

Isso é aceito na homologação?

 

Ou a melhor maneira de controlar isso é quebrar a normalização do Banco de Dados, e replicar estes campos nas tabelas necessárias (no caso do exemplo acima, criar o campo unidade na tabela de itens do DAV)? 

 

Desde já agradeço.

 

 

 

 

[Juliomar Marchetti]

Cada PDV não tem sua base de dados? seu cadastro de produtos é independente em cada PDV certo?

[ornei]

Cada PDV não tem sua base de dados? seu cadastro de produtos é independente em cada PDV certo?

Cada PDV não tem sua base de dados?

SIM.

 

seu cadastro de produtos é independente em cada PDV certo?

SIM.

 

Independente de ser local ou não, analisemos o seguinte DER:

 

TB_PRODUTO

-------------------    

ID (PK)

DESCRICAO

ID_UNIDADE (FK)

...

 

TB_UNIDADE

-----------------

ID

DESCRICAO

SIGLA

...

 

TB_DAV_ITEM (REGISTRO D3)

ID (PK)

ID_DAV (FK)

ID_PRODUTO (FK)

...

 

Observe que na "TB_DAV_ITEM", para montar o registro D3, tenho que buscar as informações do produto (Descrição, Unidade), através de um JOIN com a "TB_PRODUTO" e com a tabela "TB_UNIDADE" TIPO:

 

SELECT

  P.DESCRICAO, U.SIGLA ...

FROM TB_DAV_ITEM D

LEFT OUTER JOIN TB_PRODUTO ON (D.ID_PRODUTO=P.ID)

LEFT OUTER JOIN TB_UNIDADE ON (D.ID_UNIDADE=P.ID_UNIDADE)

  

Como tratar as alterações no caso de chaves estrangeiras (FK) ?

[Juliomar Marchetti]

Terá que tratar local na tabela quando for gravar mas usando join ! 

simples solução e rápida!

 

No caso seu dav itens vai ter um campo para o md5 certo? pra gerar ele será com o join na tabela!

[ornei]

Terá que tratar local na tabela quando for gravar mas usando join ! 

simples solução e rápida!

 

No caso seu dav itens vai ter um campo para o md5 certo? pra gerar ele será com o join na tabela!

 

Sim tenho um campo para o MD5 na "TB_DAV_ITEM".

 

Se entendi, no momento de gerar o hash eu iria considerar o campo "unidade" para formar o MD5 do registro?

[Juliomar Marchetti]

É ! 

outra forma não vejo, só se mudar a lógica e colocar sua UND junto ao DAV Itens!

[ornei]

Ok, Juliomar

 

Digamos que implemente desta maneira. Para atender ao teste de alterar a "unidade" no registro D3  (item do DAV), terei que ir na tabela "TB_UNIDADE" e alterar o campo "SIGLA" certo?

 

Mas e as outras tabelas que fazem referência com a "TB_UNIDADE" (como "TB_PRODUTO" registro P2), a alteração acima, feita para atender aos testes do registro D3, iria afetar outros registros como é o caso do P2, ou seja iria aparecer um tanto de "?" em vários outros registros.

 

Será que passa na homologação assim?

[Juliomar Marchetti]

Com certeza irá passar ele está atendendo ao que foi solicitado no teste!

que se alguém resolver de alterar manualmente deve evidenciar os arquivos!