[Resolvido]Postgresql Campo INET ou CIDR com problema no scriptcase.

Pessoal, estou desenvolvendo algumas aplicações onde tenho no banco de dados PostgreSQL campos tipo INET ou CIDR.
O scriptcase trata os campos como texto, mas os campos são especiais. Quando crio o formulário e quero inserir com algum campo vazio, o Scriptcase manda uma " ‘’ "(aspas aspas) e isso é inválido para o Banco de Dados. O correto seria ele enviar " NULL " (Sem aspas). Alguem passou pelo mesmo problema?
Acredito que isso seja um BUG do scriptcase e seria ótimo se alguem conseguisse resolver. Tenho muitas aplicações usando esse tipo de campo no banco de dados e está complicado contornar essa situação.
Atualmente estou usando Scriptcase 8.1.017

Opa, blz? Já tentou colocar o campo como default NULL no banco de dados e lá no Editar Campos colocar como Campo calculado pelo Banco de dados se vazio?

Estou com esse mesmo problema … Espero que nos ofereçam alguma solução.

Thyago, no insert funciona essa sugestão perfeitamente, já até havia implementado assim, mas o grande problema é na atualização.
Na atualização nao existe um “Calculado pelo banco de dados se Vazio”, somente “Calculado pelo banco de dados”.
Se colocar como Calculado pelo banco de dados ele não envia a alteração, se colocar normal ele envia ‘’ (aspas aspas) e dá erro.

Outra solução é verificar se o campo estiver vazio, informar para o mesmo null. Ex:

Faça isso no onBeforeUpdate

if (empty({campo})){
    {campo} = NULL;
}

Acabei de testar aqui Thyago e aconteceu o mesmo problema, o Scriptcase converteu meu NULL para aspas aspas na hora de dar o UPDATE.

if (empty({rnggw})){ {rnggw} = '0.0.0.0'; }

Desta forma até funciona, mas nao queria o valor ‘0.0.0.0’ no campo, queria NULL.

Existem formas de corrigir via Trigger no Banco de dados, estou partindo pra isso agora. Mas gostaria muito que o pessoal da NETMAKE olhasse isso, pois realmente é um BUG.

Tente isso:

if (empty({campo})){
    {campo} = NULL;
    // OU 
   {campo} = 'NULL';
}

Também não funcionou.

Mesmo erro.

Sabe se ele chega a entrar no if?

Entra sim.

Veja no Print que ele tentou gravar ‘NULL’ quando coloquei {campo} = ‘NULL’; (com aspas)
Quando coloca {campo} = NULL sem aspas ele troca o NULL por ‘’ e ferra do mesmo jeito.

Tente enviar o problema para este email então:

bugs@netmake.com.br

Eu consegui resolver adicionando uma trigger no banco de dados com o seguinte trecho de codigo

IF (TG_OP = 'INSERT' OR TG_OP = 'UPDATE') THEN IF (NEW.rnggw << NEW.range OR NEW.rnggw = '0.0.0.0') THEN NEW.rnggw = NULL; END IF;

No scriptcase coloquei pra setar como ‘0.0.0.0’ quando for vazio.

if (empty({rnggw})){ {rnggw} = '0.0.0.0'; }

É uma gambiarra, pois pelo que ví o Scriptcase não consegue trabalhar corretamente com campos INET ou CIDR do PostgreSQL

Thyago, muito obrigado pela atenção. Email enviado a NETMAKE. Espero que possam corrigir esse campo em breve. Ele já melhorou, visto que no SC7 ele travava a aplicação, no SC8 pelo menos ele insere, porém nao trabalha com campos nulos ou vazios.
Valeu. Grande Abraço.

Blz André. Te mandei uma mensagem em privado. Dá uma olhada lá.

Prezados,

O problema reportado foi corrigido e será liberado na próxima release.

A correção estará disponivel na release 8.1.018

Agradecemos a colaboração de todos.

Valeu Yuri

Resolvido na release 8.1.018

Versão liberada e disponivel para download ou atualização.

Pessoal, o problema ainda continua. Dessa vez fui usar os campos INET e MACADDR no filtro de uma consulta. Ele tenta mandar as aspas simples. Esses campos não suportam aspas simples. No formulário fiz alguns testes e passou a mandar NULL.
Os campos que devem atenção especial são INET, MACADDR e CIDR. São campos especiais no postgresql para armazenamento de IPs, mac address e redes.

Segue imagem com os erros.

Na época que constatei pela primeira vez o erro contornei usando TRIGGER no banco de dados, e mandava ‘0.0.0.0’ e a TRIGGER convertia pra NULL. Agora que voltei a usar os campos para outra aplicação e constatei o erro. Foi anunciado correção desse erro na versão 8.1.018.

Pessoal, bom dia!! Confirmo o problema citado pelo alubale!!!