[firebase-br] Compatibilidade Firebird 2 x DBExpress
Magno System
magno em speet.com.br
Sáb Mar 24 10:38:32 -03 2007
Olha Jefferson, isto pode até parecer coisa de maluco... Tenho dois
clientes, que relatei em dois posts esta semana, que estão me tirando o
sono. Tenho um sistema de vendas em que o ponto de vendas todas as
transações ficam abertas por fração de segundos. A de venda a vista (onde
ocorre o problema) eu faço assim. Tenho duas tabelas AUXVENDAS e VENDAS. Na
auxvendas ocorre o seguinte:
Inicia a transação
Insere o número do caixa + dados do produto (código, preço, valor unitário,
etc)
Fecha a transação
Como vc percebe aqui a transação fica aberta por milésimos de segundos e sem
possibilidade de deadlock uma vez que só tenho inserções.
Quando o caixa terminou de cadastrar todos os produtos ele fecha a venda. Ao
fechar a venda o sistema manda executar uma procedure
EXECUTAVENDA(numerodocaixa). Esta procedure basicamente é assim:
FOR SELECT CODIGO, PRODUTO FROM AUXVENDAS WHERE CAIXA = :NUMEROCAIXA INTO
:CODIGO, :PRODUTO DO
BEGIN
INSERT INTO VENDAS VALUES(:CODIGO, :PRODUTO);
EXECUTE PROCEDURE BAIXAESTOQUE(:CODIGO);
END
Faço assim então:
Inicia a transação;
Executa a Procedure;
Fecha a transação;
Obs.: Resumi a procedure só pra você enteder, tá...
Esta procedure, também costuma demorar frações de segundo.
Bem, em um cliente que tem 2 caixas trabalhando, aconteceram uns 5 deadlocks
em questão de 1 mês na hora de fechar a venda. Poxa, em uma procedure que
demora frações de segundos, com somente dois caixas, acontecer uns 5
deadlocks em 1 mês, com certeza deve estar havendo algum retardo no commit
ou nem está havendo commit.
O segundo problema (aconteceu em dois clientes) é que após este erro de
deadlock, meu cliente não consegue mais fechar nenhuma venda. Então ele
fecha o programa e abre novamente. Aí sim beleza. Só que todos as vendas que
ele cadastra depois que reiniciou o programa não são commitados. Quando vai
ver no outro dia, todos os dados que foram registrados após o reinicio do
programa foram perdidos.
O perfil desses dois clientes é o seguinte: Servidor Windows XP, Estação
Windows 98, Zeos 6.5.1.
Na verdade, não estou atribuindo isto ao zeos, inclusive porque em outros
clientes com o mesmo sistema não dá esse problema. Tenho até outro sistema
na área de saúde em multicamadas que trabalha com zeos + clientdataset +
datasetprovider + soap e eu não tenho problema. Mas é aquela história: Estou
tentando descobrir o problema por eliminação. Se eu trocar o componente e
der pau não é o componente, e assim vai. Mas não posso dizer que o zeos é um
mal componente (pelo menos até agora).
Mais detalhes sobre a lista de discussão lista