Fórum Problemas com interbase com edit #41389

| será que o problema esta comigo

99¬ de chance q sim. como é o código (no delphi) de insert/update que está com problema??


T+

no evento on click do botao gravar

procedure TF_Entrada.Gravar_LaudoClick(Sender: TObject);
Const

SQL = ´INSERT INTO PACIENTE ´+
´VALUES(:COD_PAC,:NOME)´;
SQL1 = ´UPDATE PACIENTE ´+
´SET NOME = :NOME ´+
´WHERE CODIGO = :CODIGO´;

Begin
DM.Q_Insere_Convenio.Close;
DM.Q_Insere_Convenio.SQL.Clear;
If Tipo = 1 // tipo variavel que indica se eu estou alterando ou incluindo 1= incluindo 2 = alterando
Case TIPO Of
1 : DM.Q_Insere_Convenio.SQL.Text := SQL;
2 : DM.Q_Insere_Convenio.SQL.Text := SQL1;
End;
DM.Q_Insere_Convenio.ParamByName(´COD_PAC´).AsInteger := StrToInt(Edit1.Text);
DM.Q_Insere_Convenio.ParamByName(´NOME´).AsSTRING := Edit2.Text;
DM.Q_Insere_Convenio.ExcSql;

Os campo cod_pac e nome est~çao declarados como not null;
porem se eu não digitar nada no nome ele aceita normalmente o código é gravado sem o nome, e quando eu vou a tabela no interbase o campo esta gravado com o código porem sem o nome. no campo codigo se ficar vazio ele reclama porque o vazio não é um número válido pois se meu codigo fosse string ele aceitaria numa boa, eu não consiguo entender.

Veja::

´´ é diferente de NULO -- ok??

então, quando vc faz:;

DM.Q_Insere_Convenio.ParamByName(´NOME´).AsSTRING := Edit2.Text;

Vc *não* está deixando o campo NULO, vc poderia fazer::

[code]
if (Edit2.Text <> EmptyStr) then
DM.Q_Insere_Convenio.ParamByName(´NOME´).AsSTRING := Edit2.Text;
[code]


ou::

[code]
if (Edit2.Text <> EmptyStr) then
DM.Q_Insere_Convenio.ParamByName(´NOME´).AsSTRING := Edit2.Text
else
DM.Q_Insere_Convenio.ParamByName(´NOME´).Clear;
[code]


T+

Valeu muito obrigado ,porem se eu fizer isso para todos os campos string do meu banco, para que declarar na tabela que o banco de dados é not null, assim eu estou verificando a integridade do meu banco por dentro do programa, ai vai por água abaixo tudo o que eu aprendi na faculdade, além disso dá uma trabalheira.

olha só !! não sei se já aconteceu isso com tigo .
a mesma coisa se você colocar>>>

Edit1.Text := IntToStr(Query.RecordCount.Asinteger); ou

Edit1.Text := IntToStr(Query.RowAfect.Asinteger);

no edit1.Text Ficará -1;

Quando eu faço numa query comum (BDE) isso não acontece.

não sei se isso acontece so comigo, por esta fazendo de maneira errada, pois eu faço desta mesma maneira com o bde e nada disso acontece.

não esqueça que tudo isso esta sendo feito numa IBQuery

|porem se eu fizer isso para todos os campos string do meu banco, para
|que declarar na tabela que o banco de dados é not null, assim eu estou
|verificando a integridade do meu banco por dentro do programa, ai vai
|por água abaixo tudo o que eu aprendi na faculdade, além disso dá uma
|trabalheira.

Bom Felipe, creio q está havendo alguns equívocos aqui::

1º -- o código q passei não representa em nenhum momento uma ´verificação de integridade´ -- mas apenas, ´transforma´ um valor (´´) em um NULO

Como já havia dito, uma ´string vazia´ (´´) é diferente de NULO -- nulo não é valor, é um estado q pode significar ´desconhecido´.

O NOT NULL no banco de dados só funciona se vc tentar informar um valor nulo, de outra forma, não há como ser diferente.

Algo como o procedimento q passei só é ´necessário´ pelo fato da abordágem de programação q vc está usando, e q poderia então ser revista (uma implementação OO por exemplo, ou até algo mais simples como encapsular o código q passei em uma função ou procedimento)

O 2º equívo é q, MESMO SE este procedimento caracterizase uma validação a nível de cliente, vc talvês tenha visto na faculdade também q em tudo é necessário ser razoável, mesmo os maiores seguidores dos grandes ´mestres´ dos SGBDR (como C.J. Date por exempo) -- concordam q, trazer pequenas ´regras de validação´ para a aplicação cliente pode ser uma boa prática. Validação de NULOS é um exemplo, já q não exige processos e geralmente nunca mudam com o tempo -- em contra-partida, a ´economia´ de rede conseguida, faz valer bastante sua utilização.


|olha só !! não sei se já aconteceu isso com tigo .
|a mesma coisa se você colocar>>>
|Edit1.Text := IntToStr(Query.RecordCount.Asinteger); ou

(esse AsInteger não existe)

RecordCount deve ser usado com muito cuidado (ou não deve ser usado) -- 1º ele funciona diferente para cada implementação de dataset, 2º no IBX, ele informa apenas quantos registros estão no Buffer do DataSet (TQuery por exemplo) -- para ele te informar o total de registros trazidos pelo SELECT, antes vc deve chamar um FetchALL (o q em alguns casos não é uma boa idéia)


|Edit1.Text := IntToStr(Query.RowAfect.Asinteger);

(aqui tb não existe esse as integer)

RowsAffected informam quantos registros foram ´afetados´ por uma (última executada) instrução UPDATE, DELETE OU INSERT -- sendo assim, só faz sentido chamá-lo após executar uma instrução dessas -- de outra forma seu valor será sempre -1


|Quando eu faço numa query comum (BDE) isso não acontece.

É verdade, o BDE não tem a mesma otimização de rede q o IBX


|não sei se isso acontece so comigo, por esta fazendo de maneira errada,
|pois eu faço desta mesma maneira com o bde e nada disso acontece.

Vc deve se deparar com pequenas diferenças entre o BDE e o IBX, todas elas, esteja certo, mesmo q não pareça no início mas são devido ao IBX ser ´melhor projetado´ (para sistemas C/S)


T+

Afarias você falou que:


Se eu usar uma TIBTable eu tenho esse Porblema usando o recordCount?


Obrigado

|Se eu usar uma TIBTable eu tenho esse Porblema usando o
|recordCount?

Assumo que SIM (nunca testei) -- Mas não é verdadeiramente um problema desde q você tenha conhecimento que o valor de retorno representa apenas os registros no Buffer.

Aproveitando, se estiver desenvolvendo um sistema para rodar em rede/multi-usuário... sugiro q não use IBTables -- componentes Table não são projetados para este tipo de aplicação.


T+

Meu Sistema tem muitos problemas que após ter analisado as resposta que obtive no forúm chequei a conclusão:

1 - Migrar do Interbase6.0 para Firebird 1.0.3

O interbase 6.0 tem muitos bugs que já foram corrigidos no Firebird e migrar para o 1.0.3 e não para o 1.5 por que o 1.0.3 é mais parecido com o interbase sem falar que para mudar de um para o outro o unico trabalho que vou ter é desinstalar o IB e instalar o FB(me corrija se eu estiver errado).

2 - Mudar de TTable, Tquery para TIBTable, tIBQuery, enfim para os componentes IBX:

Quando comecei a Desenvolver meu sistema de Automação Comercial que para meus padrões, é bastante grande, não tinha muita experiencia comecei usando paradox então migrei para o Interbase mas não mudei as TTables por TIBQuerys e IBX em geral, porque eu tinha pressa e para não ter que refazer toda a parte de cadastro que tinha seus campos como dbedit TTable, onde essa, creio eu, é a explicação para os erros totalmente sem explicação que ocorre no meu sistema(me corrija tambem se eu estiver errado).

Afarias disse que:
´se estiver desenvolvendo um sistema para rodar em rede/multi-usuário... sugiro q não use IBTables -- componentes Table não são projetados para este tipo de aplicação.´

O que vc sugere, levando em conta que eu não posso mudar todo meu sistema para TIBQuery por que demoraria muito, e eu não posso fazer isso por já ter usuarios ultilizando o sistema.

Uso generators para campos auto-incremente houvi dizer que generators não são confiaveis. Isso é verdade?

Qual a sua opnião sobre as modificações e qual sua sugestão para me ajudar?