Triggers e Views DB2

[watanabe]

Boa tarde galera tudo bem ?
Criei alguns campos via database builder em 3 tabelas.
Essas tabelas possuíam algumas views e Triggers ..... elas pararam de funcionar ....fui orientado a copiar os scripts, dropar e recria-las....


Pergunta sempre que for criar campo...depois tenho que analisar se tem alguma view ou trigger dessa tabelas e fazer esse processo que citei acima? ou tem outra forma no db2?

[Samuel Pizarro]

Nao use o DbBruilder e nem o DF Studio pra realizar alteracoes em suas tabelas.. se vc usa recursos nao suportados pelo DF.

o DF tem um suporte limitado para criar, e ou alterar tabelas. Eles nao tem como implementar tudo o que cada banco oferece.

Esse eh um caso tipico. o DF por detras dos panos ai inves de realizar simples ALTER TABLEs pra adicionar as colunas, tem horas que ele recria a tabela toda.. (cria uma nova, copia os dados da atual pra nova, e depois renomeia a nova com o nome antigo). So que nem tudo vem, como vc pode observar...
Tem alteracoes que ele nao precisa fazer isso, e eh mais inteligente.. MAs nao existe documentacao. Eu nunca sei quais tipos de alteracoes vao trigar esse comportamento "destrutivo". Entao, eu simplesmente desisti.
Eu nao uso o builder e o dfStudio pra NADA, NADA, a nao ser só olhar a definicao.

todas alteracoes eu faco com comandos nativos do db2 , via linha de comando, ou pelo IBM Data Studio, que eh uma ferramenta antiga da ibm desenvolvida pra isso..
Ela tem uma opcao interessante de criar um script das alteracoes que vc esta fazendo.. e vc pode apllicar as alteracoes no seu banco de desenvolvimento, e depois usar o mesmo script pra reproduzir em seus bancos de teste e de producao.

Apos realziar a alteracao da tabela no DB2 diraetamente, a unica coisa que preciso fazer no DF eh fazer um "Refresh" da definicao dessa tabela no DF Studio, e ele apenas vai reconhecer a nova definicao, trazendo os campos novos pra vc.

[watanabe]

Vou fazer os testes aqui mais uma vez obrigado pelo retorno.

[watanabe]

Samuel estou a testar essa ide para montar as queries no DB3 é Free

https://dbeaver.io/

[Samuel Pizarro]

cuidaod com essa ferremantas... faça bastante testes de cenarios diferentes. pois algumas fazem boas cacas. por ai..

[uandzleonel]

Nao use o DbBruilder e nem o DF Studio pra realizar alteracoes em suas tabelas.. se vc usa recursos nao suportados pelo DF.

o DF tem um suporte limitado para criar, e ou alterar tabelas. Eles nao tem como implementar tudo o que cada banco oferece.

Esse eh um caso tipico. o DF por detras dos panos ai inves de realizar simples ALTER TABLEs pra adicionar as colunas, tem horas que ele recria a tabela toda.. (cria uma nova, copia os dados da atual pra nova, e depois renomeia a nova com o nome antigo). So que nem tudo vem, como vc pode observar...
Tem alteracoes que ele nao precisa fazer isso, e eh mais inteligente.. MAs nao existe documentacao. Eu nunca sei quais tipos de alteracoes vao trigar esse comportamento "destrutivo". Entao, eu simplesmente desisti.
Eu nao uso o builder e o dfStudio pra NADA, NADA, a nao ser só olhar a definicao.

todas alteracoes eu faco com comandos nativos do db2 , via linha de comando, ou pelo IBM Data Studio, que eh uma ferramenta antiga da ibm desenvolvida pra isso..
Ela tem uma opcao interessante de criar um script das alteracoes que vc esta fazendo.. e vc pode apllicar as alteracoes no seu banco de desenvolvimento, e depois usar o mesmo script pra reproduzir em seus bancos de teste e de producao.

Apos realziar a alteracao da tabela no DB2 diraetamente, a unica coisa que preciso fazer no DF eh fazer um "Refresh" da definicao dessa tabela no DF Studio, e ele apenas vai reconhecer a nova definicao, trazendo os campos novos pra vc.


Rapaz, agora você colocou uma pulga atrás da minha orelha. Vou ter que testar isso hahaha
Quando você cria uma tabela você adiciona no DF pelo "Database > Add Existing Table"?
Existe algo que é feito por comandos que ao dar "Refresh table's definition" no DF que ele não entenda?
Vlw ai pela dica. God!

[Samuel Pizarro]

Existe algo que é feito por comandos que ao dar "Refresh table's definition" no DF que ele não entenda?

Puts se tem! Uma cacetada deles..

Tudo depende de qtos recursos seu banco tem. Nenhuma ferramenta suporta tudo o que um DBMS oferece.

Até tempos atras por exemplo, o DF perdia a referencia da Tablespaces da tabela. (Tablespace no Db2 eh o arquivo fisico onde os dados sao gravados no disco).
A tabela foi criada numa tabelspace diferente da padrao. ai vc alterava a tabela pelo Builder ou DF Studio, ele recriava ela sem definicao da tablespace, e a "nova" que ele criava como parte do processo da alteracao, era criada na "padrao" .

Nas ultimas versoes, 19.x acredito , isso foi corrigido. mas era um problema ate a 18.x acredito eu.

E varios outros recursos que vc liga pelo banco, se a ferramenta nao suporta, aquele recurso "some" , pois a ferramenta que recriou a tabela, nao esta ciente que ele estava la.

Exemplos:
1. Check Constraints (no Db2) : sao equivalentes a regras de validacao do DD do DF. mas no banco, regras que o banco valida o conteudo de uma coluna. Exemplo so aceitar valores intenrios entre 5 e 9. (qq que seja o motivo)..
se vc tem checks constraints , definido no banco, bye bye, se o DF recriar sua tabela.

2. Colunas GENERATED by DEFAULT as IDENTITY.
Antes da versao 19, as colunas IDENTIRY nem eram suportadas pelo DF, entao a definicao de auto-incremento delas dentro do banco, tb sumiam.
A versao 19.0 passou a suportar colunas GENERATED ALWAYS as IDENTIY, mas ainda nao suporta as GENERATED BY DEFAULT.

e a lista segue..

tudo depende se vc esta usando tais recursos ou nao.

Se vc sempre criou a alterou suas tabelas pelo DF, isso significa que vc NUNCA ligou os recursos que ele nao suporta.. pois como ele nao suporta, ele nunca vai conseguir liga-los concorda. ? Entao, o risco eh menor.. pois vc nao pode perder algo que vc nunca teve.
Mas mesmo assim eu nao uso o DF pra alterar a estrutura das tabelas, pois tem casos que ele recria a tabela toda. e recarrega os dados..
Faz isso numa tabela gitante me producao, com milhoes de registros.. vc vai ter que deixar sua app fora do ar por horas ate ele conseguir recria uma tabela desse tamanho.

Isso eh verdade pra qq ferramenta por ai, que se dizem suportar o DBMS x e y.. Aquelas que dizem que suportam varios tipos de bancos entao... eu sempre tenho pe atras.. pq eh praticamente impossivel eles suportarem todos os diferentes recursos que cada DBMS pode oferecer..

Nem mesmo a propria ferramenta Nativa do Db2, o Data Studio, suporta todos os recuros que ele tem.. Tem horas que nao tem como fazer algo pela GUI (ferramenta) e vc tem que apelar pra linha de comando... Se a propria ferramenta do fabricante, nao suporta tudo, imagina as outras...

Ou seja, Nao eh culda do DF. A proposta do DF eh suportar o minimo possivel pra vc usar o Banco SQL, como se vc estivesse usando ainda o DAT .
Pra que vc consiga trabalhar com o banco , sem necessariamente precisar de um DBA que saiba como aquele banco funciona.
Se vc se limitar a esse tipo de uso.. entao, o risco e menor..

[]'s

[uandzleonel]

Entendi. Deu uma visão muito boa.
Até hoje a única coisa que vi que ele se perde são nas colunas do tipo uniqueidentifier (MSSQL), ai acabei fazendo por comando mesmo.
Só que agora eu fiquei meio com medo de fazer algo e o DF não entender pelos arquivos .int, .def ou qualquer outro.
De qualquer maneira, muito obrigado por explicar. Ajudou demais!

[Samuel Pizarro]

Os arquivos .int nao sao o problema.
Neles vao ter apenas coisas q o driver suporta.

A principio você pode usar algum recurso q o driver nao suporte. A maioria das coisas podem ser “ligadas” diretamente no banco sem problemas. Vai ficar transparente pro DF. Ele nem vai saber q tal recurso esta sendo usado. Esse nao eh o problema na maiora das vezes.

O problema eh quando voce usa algum desses recursos, e depois faz alguma alteração na definição da tabela pelo DF.
A chance de “perder” o recurso q estava ligado configurado eh praticamente de 100%.