violação de chave primaria
quando eu dou um ApplyUpdates na minha tabela o sistema grava isso na memoria pra quando eu sair do sistema ele gravar definitivamente na tabela, certo?
eu estou fazendo um contador de códigos que está dando viloação de chave primaria, quando eu vou inserir um registro após o outro...usando o seguinte código:
Pode-se supor que como o registro anterior (que eu dei um applyupdates) ainda nao está definitivamente na tabela, esse código irá gerar violação de chave primaria...
ja tentei o código abaixo tambem e nao deu certo... alguem tem alguma sugestao que nao seja a de usar GENERATOR ???
eu estou fazendo um contador de códigos que está dando viloação de chave primaria, quando eu vou inserir um registro após o outro...usando o seguinte código:
// Contador de codigo de venda--------------- Dm.Tbl_Cond_CLI.Open; Dm.Tbl_Cond_CLI.Last; Cod1 := Dm.Tbl_Cond_CliCODIGO_VENDA.AsInteger; Cod2 := Cod1 + 1; Edit_Codigo.Text := IntToStr(Cod2); Dm.Tbl_Cond_CLI.Close;
Pode-se supor que como o registro anterior (que eu dei um applyupdates) ainda nao está definitivamente na tabela, esse código irá gerar violação de chave primaria...
ja tentei o código abaixo tambem e nao deu certo... alguem tem alguma sugestao que nao seja a de usar GENERATOR ???
Dm.Tbl_Cond_CLI.Open; DM.Tbl_Cond_CLI.SelectSQL.Clear; DM.Tbl_Cond_CLI.SelectSQL.add(´SELECT (MAX(CODIGO) + 1 ) PROX FROM Cond_CLI ´); cod4 := dm.tbl_Cond_CLI.fields[0].AsInteger;
Mahdak
Curtidas 0
Respostas
Michael
16/01/2006
Olá!
O método [b:cda22b00ac]ApplyUpdates [/b:cda22b00ac]efetivamente envia todas as alterações feitas em memória para o [b:cda22b00ac]DataSetProvider[/b:cda22b00ac], que cria os comandos SQL necessários e os executa na conexão atual com o banco de dados. Ou seja, depois do ApplyUpdates tudo que estava na memória do [b:cda22b00ac]ClientDataSet [/b:cda22b00ac]é refletido na tabela do banco.
O método [b:cda22b00ac]Post[/b:cda22b00ac], aplicado à classe [b:cda22b00ac]TClientDataSet [/b:cda22b00ac], é quem salva apenas em memória as modificações realizadas. E isso é perdido qdo o objeto é destruído, o que pode ocorrer não necessariamente qdo a aplicação termina, mas qdo o form proprietário do componente é fechado.
Apenas para compravar isso, segue a descrição do método, extraída do help do Delphi 7:
O select que vc usou, junto com a função [b:cda22b00ac]MAX [/b:cda22b00ac]não parece estar correto, pois notei a ausência da palavra-chave [b:cda22b00ac]AS[/b:cda22b00ac], para nomear o campo de retorno.
Esta query só vai funcionar corretamente se for executada após o ApplyUpdates, isto é, qdo o banco estiver atualizado.
[]´s
O método [b:cda22b00ac]ApplyUpdates [/b:cda22b00ac]efetivamente envia todas as alterações feitas em memória para o [b:cda22b00ac]DataSetProvider[/b:cda22b00ac], que cria os comandos SQL necessários e os executa na conexão atual com o banco de dados. Ou seja, depois do ApplyUpdates tudo que estava na memória do [b:cda22b00ac]ClientDataSet [/b:cda22b00ac]é refletido na tabela do banco.
O método [b:cda22b00ac]Post[/b:cda22b00ac], aplicado à classe [b:cda22b00ac]TClientDataSet [/b:cda22b00ac], é quem salva apenas em memória as modificações realizadas. E isso é perdido qdo o objeto é destruído, o que pode ocorrer não necessariamente qdo a aplicação termina, mas qdo o form proprietário do componente é fechado.
Apenas para compravar isso, segue a descrição do método, extraída do help do Delphi 7:
[b:cda22b00ac]ApplyUpdates method (TCustomClientDataSet)[/b:cda22b00ac]
Sends all updated, inserted, and deleted records from the client dataset to the provider [b:cda22b00ac]for writing[/b:cda22b00ac] to the database.
O select que vc usou, junto com a função [b:cda22b00ac]MAX [/b:cda22b00ac]não parece estar correto, pois notei a ausência da palavra-chave [b:cda22b00ac]AS[/b:cda22b00ac], para nomear o campo de retorno.
SELECT (MAX(CODIGO) + 1) AS PROX FROM Cond_CLI
Esta query só vai funcionar corretamente se for executada após o ApplyUpdates, isto é, qdo o banco estiver atualizado.
[]´s
GOSTEI 0
Mahdak
16/01/2006
michael, obrigado desde ja pela dica, vou checar o ´AS´...
mas verificando o sistema com o IBConsole aberto ao mesmo tempo, depois de eu dar um applyUpdates, os meus registros nao sao salvos definitivamente na tabela, e sim sómente depois de fechar a aplicação por completo...
estou usando os componentes da paleta interbase e o meu banco e firebird 1.5 (.FDB)
outra observação que nao sei se conta... a minha aplicação é MDI
Abraços...
mas verificando o sistema com o IBConsole aberto ao mesmo tempo, depois de eu dar um applyUpdates, os meus registros nao sao salvos definitivamente na tabela, e sim sómente depois de fechar a aplicação por completo...
estou usando os componentes da paleta interbase e o meu banco e firebird 1.5 (.FDB)
outra observação que nao sei se conta... a minha aplicação é MDI
Abraços...
GOSTEI 0
Mahdak
16/01/2006
Ok, o que vc me sugeriu resolveu o problema de chave primaria:
SELECT (MAX(CODIGO) + 1 ) AS PROX FROM COND_ITENS
mas os registros só sao salvos definitivamente na tabela quando encerro o sistema por completo, ou seja, o meu MDIForm...
Abraços
SELECT (MAX(CODIGO) + 1 ) AS PROX FROM COND_ITENS
mas os registros só sao salvos definitivamente na tabela quando encerro o sistema por completo, ou seja, o meu MDIForm...
Abraços
GOSTEI 0
Michael
16/01/2006
Então há alguma coisa errada com os componentes de acesso que vc está usando, pois o [b:42ed9ee0b8]ApplyUpdates [/b:42ed9ee0b8]envia os comandos SQL para o servidor assim que é chamado. O que poderia estar acontecendo é o banco estar com um volume muito grande dados, mas acho q não é o seu caso, em fase de desenvolvimento.
Tente rever as propriedades dos seus objetos de conexão.
[]´s
Tente rever as propriedades dos seus objetos de conexão.
[]´s
GOSTEI 0