[firebase-br] CONSTRAINT - UNIQUE

Carlos H. Cantu listas em warmboot.com.br
Seg Ago 12 10:44:46 -03 2019


GS> Embora o uso do   TYPE OF COLUMN seja uma vantagem obivia a tipagem, ele
GS> compromete expressões que usam ele durante a codigo PSQL porque ele não se
GS> limita apenas ao tipo, mas tambem a constraint.

TYPE OF COLUMN não "carrega" as constraints:

TYPE OF COLUMN in variable declaration
Added in: 2.5

Description: Analogous to the “TYPE OF domain” syntax supported since
version 2.1, it is now also possible to declare variables and
parameters as having the type of an existing table or view column.
ONLY THE TYPE ITSELF IS USED; in the case of string types, this
includes the character set and the collation. CONSTRAINTS AND DEFAULT
VALUES ARE NEVER COPIED FROM THE SOURCE COLUMN.

[]s
Carlos H. Cantu
eBook Guia de Migração para o FB 3 - www.firebase.com.br/guiafb3.php
www.FireBase.com.br - www.firebirdnews.org - blog.firebase.com.br

GS> Embora o uso do   TYPE OF COLUMN seja uma vantagem obivia a tipagem, ele
GS> compromete expressões que usam ele durante a codigo PSQL porque ele não se
GS> limita apenas ao tipo, mas tambem a constraint.
GS> Se a coluna tiver uma constraint como valor="A" ou "C", você tem que saber
GS> que não dá para criá-la como vazio, daí tem que inicializar diretamente na
GS> declaração como:
GS> DECLARE VARIABLE WDOCOBS TYPE OF COLUMN COBRANCAS.DOCOBS  ='A';

GS> E ter a certeza de que algo diferente de A ou C não lhe seja atribuida
GS> durante o codigo.

GS> []´s


GS> Em qua, 7 de ago de 2019 às 13:40, Mário Reis <mariodosreyx em gmail.com>
GS> escreveu:

>> Boa tarde companheiros
>> Uma situação bizarra que nunca me ocorreu antes! Tenho uma varavel nu
>> S.Procedure assim definida
>> DECLARE VARIABLE WDOCOBS TYPE OF COLUMN COBRANCAS.DOCOBS on de este , com
>> 50 de comprimento está definido com charset WIN1252 e COLLATION PXW_INTL850
>> (sempre usei assim e nunca até hoje tivera problemas)!
>> porém hoje ao receber  carregar esta variavel com
>> "ACRA0CGDI0CORE020190701003001000003" (onde aqui  o i aparece como um I em
>> debug apresenta-se como um numero 1 romano, ou seja, traço por cima traço
>> ao alto e traço por baixo.
>> e o meu select não encontra nunca esta chave já se for hardcoded ,
>> encontra!!!
>> Assim, não encontra
>> Serlect * from cobranca c1
>> where c1.docobs=:wdocobs
>> row_count=0;
>> Assim,  encontra
>> Serlect * from cobranca c1
>> where c1.docobs='ACRA0CGDI0CORE020190701003001000003'
>> row_count=1;
>> Alguma ideia? Estou há horas a tentar entender isto
>>
>> Com os meus melhores cumprimentos
>> Mário Agostinho Reis
>> 919262146
>>
>> Esta mensagem contém informação de natureza confidencial e é
>> exclusivamente dirigida ao(s) destinatário(s) indicado(s). Se, por engano,
>> receber este email agradecemos que não o copie nem o reenvie e que nos
>> notifique do ocorrido através do email de resposta.
>>
>>
>> Gladiston Santana <gladiston em vidy.com.br> escreveu no dia terça, 6/08/2019
>> à(s) 12:38:
>>
>> > constraint é uma regra de campo, aceita qualquer tipo de lógica que você
>> > possa impor com os comandos SQL, neste caso usando algo como
>> > COALESCE(VALUE,'')<>''.
>> > Eu não gosto muito de manter nulos em campos de lookup, pois nulos tem de
>> > ser tratados em agregadores e podem fazer-nos penar em algumas situações
>> > então em muitas situações em faço assim, por exemplo, numa tabela de
>> > clientes tem o campo de estado( END_UF), mas o estado informado deve
>> > existir na tabela de estados(ADMIN_UF), contudo é permissível não
>> informar
>> > o estado, mas não quero nulos. Daí imponho uma regra assim:
>> > CREATE TABLE CLIENTES (
>> > ...
>> >     END_UF   CHAR(2) DEFAULT '*' NOT NULL CHECK ((VALUE='*') OR
>> >        (EXISTS(SELECT * FROM ADMIN_UF WHERE UF=VALUE))) */,
>> > ...)
>> > Na regra acima ou é um estado pré-cadastrado ou então é "*". Nulos não
>> > entram.
>> >
>> > Sobre o unique, só me faz lembrar de indices, indices não subtraem ou
>> negam
>> > informações, apenas os ordena.
>> > São permitidos expressões como usando coalesce para tratar nulos.
>> > Normalmente o fazemos em conjunto com uma expressão matematica para
>> > ordernar as melhores compras num leque de opções ou algo do genêro, sem a
>> > intenção de provocar uma pesquisa mais rapida. Atualmente, com o advento
>> de
>> > tabelas temporarias e procedures selecionáveis é muito dificil
>> justificar o
>> > uso de indices desse tipo.
>> >
>> > [] ´s e sucesso.
>> >
>> > Em sex, 2 de ago de 2019 às 10:05, Moacir Kuhn <moacir em softin.com.br>
>> > escreveu:
>> >
>> > > Senhores,
>> > >
>> > >
>> > >
>> > > È possível criar uma CONSTRAINT  - UNIQUE levando em consideração
>> apenas
>> > os
>> > > registros que tenham conteúdo no campo desejado, desprezando os
>> > > NULL/Brancos?
>> > >
>> > >
>> > >
>> > > Att,MOacir
>> > >
>> > >
>> > >
>> > ______________________________________________
>> > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>> > Para saber como gerenciar/excluir seu cadastro na lista, use:
>> > http://www.firebase.com.br/fb/artigo.php?id=1107
>> > Para consultar mensagens antigas:
>> > http://www.firebase.com.br/pesquisa_lista.html
>> >
>> ______________________________________________
>> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>> Para saber como gerenciar/excluir seu cadastro na lista, use:
>> http://www.firebase.com.br/fb/artigo.php?id=1107
>> Para consultar mensagens antigas:
>> http://www.firebase.com.br/pesquisa_lista.html
>>






Mais detalhes sobre a lista de discussão lista