Diferenças entre NUMERIC, DECIMAL, FLOAT E DOUBLE PRECISION

[@jameswhatson6397]

Ótima explicação. Bem detalhada! Uma dúvida: no banco tenho um campo numérico, mas lá no Delphi eu envio a informação da string pelo o comando StrToFloat. Como fica isso? Certa vez eu estava tendo problema de precisão com o StrToFloat, e consegui resolver usando StrToCurr.

[@moisesabel741]

Sensacional mestre, só uma pergunta, eu tenho uma procedure que lê um JSON, e devolve o campo, nível e o valor, com esse retorno do valor, eu consigo identificar dessa forma aí, pois não são campos, são retornos de procedure.

[@jameswhatson6397]

Interessante. Então é por isso que eu tinha um numérico 10,2 e não conseguia de jeito nenhum mudar pra 10,3... tive q mudar pra 11,3 e daí eu certo.

[@tonatocatonatoca]

Muito bom! Show!

[@mqfs]

Valeeeeu!! 💪🏻💪🏻💪🏻

[@SilvestreFilmes]

VALEU AMIGO, VC É UM AMIGÃO

[@mqfs]

Valeeeeu!!!

[@joelcosta1631]

Bom dia, meu caro professor. Tudo bem? Amigo, eu teria algum problema em migrar meu banco de firebird 2.0 para 3.0. Tipo: houve alteração de Campos? Data, entre outros? É complicado fazer essa mudança? Agradeço a atenção. A propósito. Este vídeo está Top. Parabéns. Obrigado.

[@mqfs]

Opa, e aí Joel, blz?? A princípio, uma coisa q vc precisa tomar cuidado é se as suas UDFs (caso use) são compatíveis com a nova versão. Fora isso, já vi pessoas dizendo que fizeram essa migração do 2.0 pro 3.0 direto sem problema nenhum. Uma coisa que é importante na hora de migrar, é registrar todo o processo em logs, pra que fique fácil identificar qualquer erro. Enfim, a princípio não é pra ter problema não, vamos ter certeza mesmo quando vc fizer o teste... Fiz um vídeo sobre migração do 2.5 para o 3.0 usando uma técnica mais rápida, mas não tenho certeza se já estava disponível no 2.0. Veja: kzbin.info/www/bejne/inW7q3aZgdh5o6c

[@joelcosta1631]

@@mqfs certo. Vou ver o seu vídeo. Preciso me atualizar. Veja que até o comando que eu fui usar não existe no 2.0. Fiz uma rotina no Delphi, aproveitei sua deixa e usei o stringreplace. Deu certinho. Agradeço por isso. Mas usar o ibexpert direto é mais produtivo. Obrigado.

[@jacksonlima4772]

Então brother, meu campos eram todos floats, tinhamos muitos problemas e mudamos para numeric(15,6), porém agora é preciso ficar dando cast em tudo quanto é lugar no sistema, cara é chato pq só estoura nos clientes os overflows. Hoje encontrei a seguinte situação: Sum((VALOR * QUANT) * (1 - (DESCO / 100) )) VALOR O campo valor tem: 5.000,000000 (cinco mil) O campo quant tem:1,400000 (um virgula 4 (peso)) Ambos da tabela de itens O campo desco tem 0.000000 (tabela pedido) e recebo um overflow simplesmente pq no DESCO tem 0.00000, quando eu coloco 0 passa de boa pq isso acontece? O que eu posso fazer para resolver sem ter que ficar dando casts? Abraços.

[@mqfs]

E aí Jackson!! Sempre que é feita multiplicação ou divisão, as casas decimais dos campos envolvidos são somadas, ou seja, 2.00 / 1.000 resulta em 5 casas decimais... Mas o certo é isso mesmo, precisa colocar cast em contas que possam estourar as casas decimais, a desvantagem é que fica mais trabalhoso, a vantagem é que vc tem precisão alta de forma proposital, não ao acaso. Se vc tiver consultas que se repetem em vários pontos do sistema, veja se é viável criar view ou procedure selecionável pra centralizar seu código, sem necessidade de fazer cast em todo lugar.

[@jacksonlima4772]

@@mqfs Triste viu. Mas eu via algumas tarefas abertas lá no firebird core que parece que foi aumentado a precisao para 34 digitos. Será se não vai resolver isso ai? tracker.firebirdsql.org/browse/JDBC-516