Página 1 de 2
Pessoal problema com a numeracao dos PEDIDOS(URGENTE)
Enviado: 10 Jan 2008 12:20
por helio
Pessoal estou com um problemao da seguinte forma tenho uma APP de automacao comercial e tenho uma arquivo que guardo o numero o ultimo numero do pedido e quando vou gerar um pedido incremento mais 1 no DBF funcionava tudo ok mais quando passei a usar FIREBIRD com SQLRDD nao deu mais certo estar saindo 2 pedidos com o mesmo numero alguem tem alguma solucao para isso ?
Valeu pela Atencao,
Helio Beltrao Jr.
helio@hrbinfo.com.br
Enviado: 10 Jan 2008 12:22
por helio
O trecho do sistema e o seguinte:
Código: Selecionar todos
sr_begintransaction()
try
*********
SELE(no)
*********
IF ! BLOQARQ()
// LOOP
ENDIF
GO TOP
IF LASTREC() = 0
IF ! ADIREG()
atencao('Nao foi possivel gerar o numero do PEDIDO')
RESTSCREEN(01,00,23,79,mtela)
// LOOP
ENDIF
ELSE
IF ! BLOQARQ()
atencao('Nao foi possivel gerar o numero da O.S.')
RESTSCREEN(01,00,23,79,mtela)
// LOOP
ENDIF
ENDIF
mnum_ped = VAL((no)->numero)+1
(no)->data_ped := mdata_sis
(no)->numero := STRZERO(mnum_ped,6)
DBCOMMIT()
DBUNLOCK()
sr_committransaction()
catch e
sr_rollbacktransaction()
end
sr_endtransaction()
Enviado: 10 Jan 2008 12:36
por Maligno
Uma vez que você utiliza o Firebird, não seria melhor trocar para um GENERATOR? Eu uso e nunca tive qualquer problema. Isso é gerenciado pelo banco de dados. Pode botar fé.
Enviado: 15 Jan 2008 17:12
por edmarfrazao
segue o conselho do maligno.
Use GENERATOR
Enviado: 17 Jan 2008 23:16
por rossine
Olá Maligno,
Como faço para usar o generator ? Tem como citar um exemplo ? Outra coisa, fazendo uns testes com firebird e usando uma tabela de 100.000 registros, o browse fica muito lento na navegação ? Você tem este problema tambem ? Reparei que ao simples toque na tecla seta para baixo, o processador chega a 100% e isto acontece tambem com o comando append. Uso o xhb + sqlrdd.
Obrigado,
Rossine.
Enviado: 17 Jan 2008 23:38
por alaminojunior
sr_committransaction()
catch e
sr_rollbacktransaction()
Apesar de não entender de FireBird, a função sr_rollbacktransaction(), não seria a culpada ? Desculpe se falei bobagem.
Pelo menos em MySql, se a condição não for satisfeita, rollback transaction volta tudo do jeito que era.
Enviado: 18 Jan 2008 00:14
por sygecom
alaminojunior escreveu:
sr_committransaction()
catch e
sr_rollbacktransaction()
Apesar de não entender de FireBird, a função sr_rollbacktransaction(), não seria a culpada ? Desculpe se falei bobagem.
Pelo menos em MySql, se a condição não for satisfeita, rollback transaction volta tudo do jeito que era.
Como esta o "sr_rollbacktransaction()" só vai executar se der algum erro na app, caso contrario ele vai executar "sr_committransaction()"
Enviado: 18 Jan 2008 00:44
por Maligno
rossine escreveu:Como faço para usar o generator ? Tem como citar um exemplo ?
Isso é bem simples de fazer se você usar um utilitário qualquer de manutenção, como o IBExpert, por exemplo. Mas se quiser fazer no braço, a sentença SQL seria:
Código: Selecionar todos
CREATE GENERATOR "nome_do_dito_cujo"
SET GENERATOR "nome_do_dito_cujo" TO 0
Outra coisa, fazendo uns testes com firebird e usando uma tabela de 100.000 registros, o browse fica muito lento na navegação ? Você tem este problema tambem ?
Eu não tenho esse problema. Mas tem um detalhe: eu jamais faria o banco me devolver volume tão grande de dados. Realmente não é aconselhável trazer 100.000 registros para um browser. Quando você faz um SELECT que lhe traz tantos registros, ele traz realmente, e é preciso manipular toda essa massa de dados em memória, o que em certo momento acaba provocando vários swaps em disco. Veja que não é uma limitação da linguagem. Em qualquer linguagem, ferramenta ou SGBD isso ficaria lento. Aliás, os que trabalham há mais tempo com esses SGBDs modernos não trabalham dessa forma, já sabendo que o resultado disso é a lentidão.
No antigo sistema DBF isso nem seria tanto problema, pois os registros são lidos conforme o browser precisa deles. Mas em gerenciadores mais modernos o esquema é diferente. O resultado de um SELECT vem todo pra memória. Cuidado com os SELECT * bla bla bla.
Reparei que ao simples toque na tecla seta para baixo, o processador chega a 100% e isto acontece tambem com o comando append. Uso o xhb + sqlrdd.
Acredite. Esse percentual de consumo de tempo de CPU seria normal em qualquer programa que fizesse isso. Seja VB, Delphi, etc. Portanto, a solução pro caso é simplesmente refazer a lógica do seu programa, pra diminuir a carga deste SELECT.
Enviado: 18 Jan 2008 08:53
por MARCELOG
Oi pessoal,
não trabalho com o Firebird, mas deve ser (ou ter) algo igual ao Mysql.
Então, não é difícil de implementar.
Eu mesmo já estou trabalhando nisso (quando tiver pronto eu posto aqui no fórum).
No Mysql existe a cláusula limit do select.
Logo, carregue os primeiros x registros e pronto.
Se o usuário estiver no último registro da consulta usar a tecla para ir para o final da consulta ou tecla para baixo, faço outro select e carrego os próximos x dados no browse/ grid.
Com hwgui e minigui usando um grid, pode-se até carregar o total dos registros e manipular ou colocar no grid apenas um parte deles.
Contudo, para garantir integridade de dados, recomendo efetuar um outro select, é rápido, mesmo para um volume grande de dados.
MarceloG
Enviado: 18 Jan 2008 09:14
por Maligno
O Firebird tem o SELECT FIRST <f> SKIP <s> <cols> FROM ...
Enviado: 18 Jan 2008 09:48
por rossine
Olá Maligno,
CREATE GENERATOR "nome_do_dito_cujo"
SET GENERATOR "nome_do_dito_cujo" TO 0
OK
Eu não tenho esse problema. Mas tem um detalhe: eu jamais faria o banco me devolver volume tão grande de dados. Realmente não é aconselhável trazer 100.000 registros para um browser. Quando você faz um SELECT que lhe traz tantos registros, ele traz realmente, e é preciso manipular toda essa massa de dados em memória, o que em certo momento acaba provocando vários swaps em disco. Veja que não é uma limitação da linguagem. Em qualquer linguagem, ferramenta ou SGBD isso ficaria lento. Aliás, os que trabalham há mais tempo com esses SGBDs modernos não trabalham dessa forma, já sabendo que o resultado disso é a lentidão.
Na verdade eu não comando nenhum select, uso o sqlrdd e praticamente não mexi em meu fonte. Na verdade esta tabela (DBF) é um contas a receber. No seu caso você tendo um banco de dados igual ao citado acima, você nunca mostra para o cliente todo ele ? Somente após ele fazer alguma pesquisa aí você executa o "select" é isto ?
Acredite. Esse percentual de consumo de tempo de CPU seria normal em qualquer programa que fizesse isso. Seja VB, Delphi, etc. Portanto, a solução pro caso é simplesmente refazer a lógica do seu programa, pra diminuir a carga deste SELECT.
Mas eu tenho problema de consumo de memória também na hora de comandar o append blank, demora uns 5 segundos para processar uma inclusão na tabela.
No ibexpert navego na tabela sem problemas. Hora nenhuma ela trava, aliás, somente quando estou no inicio do arquivo e quero ir diretamente para o fim, aí demora 7 segundos da primeira vez, depois fica rápido toda navegação.
Olá Marcelo,
não trabalho com o Firebird, mas deve ser (ou ter) algo igual ao Mysql.
Então, não é difícil de implementar.
Eu mesmo já estou trabalhando nisso (quando tiver pronto eu posto aqui no fórum).
No Mysql existe a cláusula limit do select.
Logo, carregue os primeiros x registros e pronto.
Se o usuário estiver no último registro da consulta usar a tecla para ir para o final da consulta ou tecla para baixo, faço outro select e carrego os próximos x dados no browse/ grid.
Interessante isto, a cada tecla se processa uma sentença. Você usa fwh ?
Eu mesmo já estou trabalhando nisso (quando tiver pronto eu posto aqui no fórum).
É disto que preciso, exemplos (hehe)
Estou começando agora com banco de dados e não sei nada nada sobre isto, eu só quero entender o porque da lentidão e uma maneira eficiente de dibrar este problema :)Pos
Obrigado a todos,
Rossine.
Enviado: 18 Jan 2008 11:33
por Maligno
rossine escreveu:Na verdade eu não comando nenhum select, uso o sqlrdd
Bom, neste caso já não posso dizer nada. Além de não usar o XHarbour, não conheço patavinas desse RDD. Logicamente ele tem outro esquema.
No seu caso você tendo um banco de dados igual ao citado acima, você nunca mostra para o cliente todo ele ? Somente após ele fazer alguma pesquisa aí você executa o "select" é isto ?
Não tenho nenhum caso de tabela com um volume tão grande, mas se tivesse, eu só mostraria para o cliente partes pequenas, separados por cliente ou por mês. Algo do tipo. Se o cliente procura alguma coisa, primeiro ele terá de fornecer um filtro que diminua a carga dos dados.
Mas eu tenho problema de consumo de memória também na hora de comandar o append blank, demora uns 5 segundos para processar uma inclusão na tabela.
Essa demora me parece bem anormal. Mas se é por RDD, não posso falar muito sobre isso.
No ibexpert navego na tabela sem problemas. Hora nenhuma ela trava, aliás, somente quando estou no inicio do arquivo e quero ir diretamente para o fim, aí demora 7 segundos da primeira vez, depois fica rápido toda navegação.
Não sei como o IBExpert faz, mas pelo jeito tem um sistema de cachê qualquer muito bom.
Enviado: 18 Jan 2008 11:40
por MARCELOG
Com Mysql (e Mysql.lib)
...
... 'SELECT * FROM XTABELA LIMIT 20.000'
Adiciona registros no browse/ grid
Isso só vai carregar os primeiros 20.000 registros.
Verificar no browse/ grid se o cliente está na última linha e pressionou tecla para baixo
... 'SELECT * FROM XTABELA LIMIT 20.001,20.000'
Adiciona registros no browse/ grid
Isso só vai carregar os próximos 20.000 registros.
Se o usuario pressinou 'final da consulta' (CTRL+PAGEDOWN), fazer o quê né!
... 'SELECT * FROM XTABELA'
Adiciona todos os registros no browse/ grid
Você também pode fazer como o Malígno sugeriu.
Supondo que não usa qualquer lib gráfica, basta colocar um get na janela do browse para o usuário teclar uma inicial ou data, etc.
Assim, você busca todos os registros com o filtro.
E isso pode ficar muito rápido se você usar índices.
É isso mesmo, o Mysql também usa índices!
MarceloG
Enviado: 18 Jan 2008 11:59
por Maligno
É isso mesmo, o Mysql também usa índices!
Mas todos SGBDs usam índices.
Enviado: 18 Jan 2008 22:00
por alaminojunior
Um outro fator que pode agravar a performance, (tanto em browse´s quanto, principalmente em indices) é a modelagem que se faz com os dados.
Imagine um banco de dados, seja ele qual for, DBF ou SQL, com os tais 100.000 registros, sendo indexados da seguinte forma:
index on cnome to nomes
index on ncpf to cpfs
index on dnasc to nasc
São indices simples.
Agora tente indexar assim:
index on substr(cnome,1,25)+str(ncpf,14)+dtoc(dnasc)
Concluindo...
Seria interessante, não aplicar ( na medida do possível ) nenhuma função para modelar os dados. Tanto na indexação, quanto na exibição num browse. O mais sensato seria tratar estas situações dentro da estrutura de exibição ou manipulação dos dados, como pesquisas, replaces, etc...