Delphi + dbExpres + Firebird

[lucas_rc 0]

Boa tarde pessoal,

 

Estou tendo um problema grave no meu sistema em alguns momentos quando dois terminais gravam juntos 2 notas os itens se misturam. Qual melhor modo para fazer um tratamento para que isso não ocorro mais?

 

Att

Lucas Ribeiro

[Eisenheim 67]

Olá amigo.

 

Isso sempre gera muita polêmica, no entanto como você está trabalhando com isso? Você utiliza transações? Explique como você está trabalhando nesse sentido para que possamos te auxiliar em como tratar esse tipo de situação.

 

Até a próxima. :thumbsup:

[lucas_rc 0]

Boa tarde Eisenheim

 

Ainda não utilizo transações nesta ação...

 

Utilizo o processo simples, campos recebendo e apos finalizar executo um ApplyUpdades.

 

O que me indica, partir para o uso de transações?

[Eisenheim 67]

Olá amigo.

 

Então, no meu caso aqui na empresa nós costumamos trabalhar com os registros em memória e só na finalização do processo é que fazemos o comm​it para que as informações sejam gravadas definitivamente no banco de dados.

 

Aqui ainda trabalhamos com os componentes da guia "BDE", então nas querys utilizamos a propriedade "CacheUpdates" como true para trabalhar em memória com os registros.

 

Em algum momento do sistema como em um botão "Gravar", nós iniciamos uma transação, realizamos todo o processamento do que deva ser feito e se tudo correu bem nós aplicamos o commit, do contrário um rollback para desfazer as alterações.

 

Só resalto que mesmo assim, ainda existem possibilidades de erro, como uma eventual queda de energia por exemplo. No entanto é uma forma de trabalhar sem que mais de uma pessoa fazendo a mesma coisa acabe influenciando no que outra estiver fazendo.

 

Até a próxima. :thumbsup:

[Eduardo Alcântara 6]

Para trabalhar com essa situação onde vários usuários podem acabar editando o mesmo registro ao mesmo tempo, você tem as seguintes possibilidades de correção:

 

1. Utilize o mecanismo de "cadeados" (lock) para travar um registro quando ele estiver sendo utilizado por um usuário. O registro só será liberado para outro usuário quando o primeiro usuário que estiver utilizando o registro efetuar um comando Post;
   
2. Utilize uma outra tabela com o nome de "Adições" cujos registros apontem para um registro na tabela anterior em "N:1" e cada alteração corresponderá a um novo registro nessa nova tabela. Assim você tem até mais segurança, podendo saber quem fez cada alteração;
   
3. Você pode criar uma tabela de controle que identifique se cada registro em cada tabela está sendo editada no momento. Somente após fazer a verificação nessa tabela, você deverá liberar o usuário para que ele edite. Quando ele salvar o registro, você poderá alterar o status dele na tabela de controle.

O que me parece estar acontecendo no seu caso é que cada máquina rodando o seu sistema deve estar apontando diretamente para o arquivo de banco de dados no computador servidor, é isso?

 

Se for, você deve, não apontar para o arquivo, mas sim, para a máquina servidor e depois para o caminho usando a seguinte forma:

 

nome-computador-ou-ip:arquivo-do-firebird

 

Exemplo: Se eu tenho 3 máquinas, "servidor", "atendimento" e "escritorio", eu preciso ter um arquivo .ini para ler o local do banco de dados em seu aplicativo, antes de abrir o mesmo. Se meu banco de dados está no "servidor" no arquivo "c:\dados.fb", então no arquivo .ini do servidor deve estar registrado "banco=c:\dados.fb", mas nos outros dois computadores, deve estar registrado como "servidor:c\dados.fb" ou ainda "\\servidor\c:\dados.fb" para que ele acesse o arquivo indiretamente pelo controlador do banco de dados firebird que está executando no servidor. Se você apontar diretamente para o arquivo, ele usará o controle da máquina cliente e não considerará as alterações que estão sendo feitas nas outras máquinas.

 

Preste atenção se não está usando o sistema dentro de uma pasta de sincronização do dropbox, google drive etc. Pois isso também dá problema se você usar o arquivo de dados dentro dessa pasta.

[lucas_rc 0]

Boa tarde Eisenheim, Eduardo

 

 

 

Eisenheim vou me aprofundar mais nas transações, talvez isso resolva meu problema...

 

 

 

Eduardo hoje eu ja uso a conexão com o banco do modo que você disse IP:Diretorio, e o problema não tem ocorrido com usuários trabalhando no mesmo registro é mais estranho ainda, são notas distintas um exemplo, tenho o setor de faturamento emitindo as NF-e e mais uma loja de produtos emitindo cupom fiscal, em alguma momento uma nota assimila 1 ou mais itens da outra nota, penso em testar a solução passada pelo Eisenheim (uso de transações), e também colocar o próprio banco para fazer a gravação dos itens, só exitei em começar esta manutenção no sistema devido a incerteza que só estas duas mudanças vão me trazer o resultado. Se puder fazer uma avaliação desta opção seria de grande ajuda.

 

Obrigado pela atenção

Att

Lucas Ribeiro

[Eduardo Alcântara 6]

As transações servem para você alterar vários registros que dependam um do outro. Exemplo: cadastra um exame do paciente e cadastra no paciente total-exames = total-exames + 1. Se você estiver usando transações e der um erro na segunda sql, a primeira é desfeita para não ficarem dados divergentes.

 

O que pode estar havendo no seu caso é alguma variável global que deveria ser local.

 

Você fez o modelo do seu sistema ou Foi logo programando?

[lucas_rc 0]

Eu entrei na empresa já tinha toda estrutura do software montada, apenas estou dando continuidade no que já roda hoje e surgiu este problema, o complica para resolver que não é sempre que ele ocorre, e neste caso ocorre por terminais diferentes, o que emite a NFe é diferente do ECF, por este motivo estou buscando ideias para minimizar os erros.

[Almir Bispo 2]

Esse é um dos grandes problemas para um sistema de bases de dados.

Ao desenvolver meu SGBD em CSV,tomei (principalmente esta preocupação).

Controle de concorrência.

O principio que usei no CSV Comp foi simples:

Mesmo que 1000 pessoas acessem a mesma tabela (arquivo csv),o sistema operacional vai direcionar uma delas como prioritário.(milésimo de segundos)

 

antes de modificar uma tabela eu uso um WHILE.

 

 

var tilt:integer;
 lock:tstringlist;
begin
tilt:=0;
//crio um tstringlist
lock:=tstringlist.create;
//verifico execução da concorrencia
  while fileexists('lock.inf') do
   begin
   inc(tilt);
   sleep(1);
   end;
//ja que é minha vez,travo concorrencia
lock.add('minha vez e ninguem tasca !');
lock.savetofile('lock.inf');
lock.free;
//mesmo que demore um ano ou mais,ninguem que usar a mesma aplicação em outra instancia ,conseguirar concorrer
//processo query
(minhaquery nas tabelas,bla,bla)

deletefile(pchar('lock.inf'));
end;

//Então,assim consegui criar um sistema excepcional para meu SGBD

 

[contento 1]

Aqui ainda trabalhamos com os componentes da guia "BDE", então nas querys utilizamos a propriedade "CacheUpdates" como true para trabalhar em memória com os registros.

[Eisenheim 67]

Aqui ainda trabalhamos com os componentes da guia "BDE", então nas querys utilizamos a propriedade "CacheUpdates" como true para trabalhar em memória com os registros.

 

Ctrl+C e Ctrl+V na cara dura...rs

 

Até a próxima. :thumbsup: