EMBarbosa

Minha ideia é você verificar o que está acontecendo. Se a lentidão está acontecendo com tabelas maiores, mas ela não acontece via SQL, então a explicação mais plausível é que o componente está carregando registros da tabela. Tive um problema desses uma vez com o TClientDataset. Como ele estava ligado a um IBDataSet onde colocávamos o SQL, só pra testar eu alterei o select do SQL incluindo um limite de linhas. Por exemplo: SELECT NOME FROM CLIENTES ROWS 1 TO 50 A lentidão foi embora. A partir daí eu fui verificar o que o componente estava fazendo pra abrir e consegui resolver.

Ser no applyUpdates não quer dizer nada. Esse método faz tanta coisa, que você não sabe o motivo real da lentidão. Por isso um profiler é a melhor ferramenta... Só insisti nisso porque você está indo na contramão de todos os benchmarks que vi sobre o assunto. O FireDAC desbanca o dbExpress em muito. A ideia de fazer o sql era apenas para saber sobre a velocidade mesmo. Afinal se com o SQL puro não ficasse mais rápido, o problema era o BD. Agora, se você está utilizando TClientDataset então tem outras coisas envolvidas. A dinâmica é muito diferente. Tem coisas que o TClientDataSet só faz no ApplyUpdates. Bom, não tem sentido eu ficar insistindo em algo que você não quer fazer. Mesmo porque não sou eu quem tem que lidar com os problemas. Só falei o que é minha opinião particular, de uma pessoa que já lidou com vários problemas de lentidão assim. Por outro lado seria falso da minha parte não lembrar que DBexpress é considerada tecnologia obsoleta

Já está no radar do Daniel para resolver. Mas se um de vocês puderem anexar o arquivo alterado facilitaria a análise.

Rapaz, usar os profilers é muito simples. Dá uma chance pra eles. É o tipo de ferramenta que depois de aprender a utilizar te abre uma nova visão das coisas. Mesmo uma tabela desse tamanho, se você está apenas inserindo um novo registro, o tempo gasto deveria ser bem pequeno. Você pode verificar isso executando o SQL diretamente. A menos que você esteja pensando em adotar um ORM como o mORMot, sugiro você tentar descobrir o problema e resolver.

Se resolver, por favor, anexem o arquivo alterado para que seja avaliado.

Visto que está disposto a pagar, talvez queira colocar um tópico na área de classificados. Daí talvez alguém com experiência possa te ajudar.

E você tem certeza que não está vindo nenhum registro? Em caso afirmativo, eu sugiro você utilizar algum profiler. É melhor você medir exatamente onde está a demora que a gente ficar especulando. Talvez queira tentar o dbgSpider, ou o asmprofiler, ou ainda o Sampling Profiler.

Não sei de qual tipo de Dataset é o componente TB10000, mas geralmente PacketRecords não quer dizer quantos registros você vai puxar do BD. Apenas quantos vai puxar por vez. Então setar ele como 0 não vai necessariamente impedir de puxar todos registros da tabela. Bom, no código está apenas o Post e o ApplyUpdates. Qual método do componente você está utilizando para abrir um novo registro? Insert? Append?

Depende da forma que você faz a gravação. Por exemplo, se estiver carregando dados da tabela ao gravar, isso pode acontecer.

Da mesma maneira que faria com outros TListBox não funciona? Usar a propriedade Items e o método IndexOf.

hmmmm... então basta verificar o motivo disso estar acontecendo. Daí você consegue resolver o problema.

Uma sugestão é você ter uma tabela no seu sistema e atualizar ela de vez em quando. Daí você tem o melhor dos dois modos.

Qual a mensagem de erro?

O que está disponível nesse tópico foi criado pelos usuários, mas não foi adicionado aos componentes ACBr.

Tem que verificar se o componente está usando esse site. Se tiver o problema é outro.

Com o recaptcha é bem complicado, mas se tiver outro endereço que continue funcionando o captcha antigo acho que sim.

Que tipos de problemas?

Você está debugando o exemplo do ACBrMTER ou a sua aplicação?

Temos um vídeo que fala sobre esse e outros recursos do SVN que são muito úteis ao trabalhar com o ACBr. Veja abaixo:

Se está usando versões mais novas do Delphi, marque a opção "Remover warnings de CAST causados por WideString/..." no ACBrInstall: Não marque essa opção para o Delphi 7.

Essa é uma dúvida comum. Acabei de criar um tópico sobre o assunto. Dá uma olhada por favor:

Olá pessoal, Esse tópico é para explicar como você pode voltar a versão do código ACBr usando o SVN. Em que situações que isso pode ser necessário? Imagine que você acabou de atualizar os componentes, (ou na linguagem do SVN, fazer um "update"), e percebe qualquer uma das situações abaixo: ... que algum componente que você usa foi removido; ... que um comportamento de um componente mudou; ... que propriedades foram alteradas; ... que um erro foi introduzido ; ... que algum arquivo foi removido (por exemplo um arquivo de modelo relatório); Em qualquer um desses casos o mais correto é você adaptar o seu código de acordo com as alterações (mesmo no caso do bug você talvez possa corrigir e reportar). Mas e se você precisa da solução imediata? Talvez o seu cliente precise de um novo executável agora. Ou pode ser que você precise de mais tempo pra adaptar o seu código. Ou ainda você pode querer comparar logs gerados antes e depois da atualização. Ou o precise do acesso ao arquivo removido. Em qualquer um desses casos você precisaria voltar a versão do ACBr. Como você pode fazer isso? Usando o TortoiseSVN e o Windows Explorer! Siga os seguintes passos: 1) Clique com o botão direito na pasta do ACBr e selecione "Update to revision..."; 2) Na janela que abriu, marque a opção Revision e escreva na caixa de texto para qual revisão que você deseja retornar; Por exemplo 16601; 3) Confirme; 4) Use o ACBrInstall para reinstalar o ACBr (em caso de problemas, marque a opção de apagar arquivos antigos) Pronto o código vai voltar pra versão (ou revision) que você selecionou. Vai ser como se você não tivesse atualizado. Sua próxima dúvida talvez seja: Como vou saber qual revision devo escolher? Isso vai depender do seu objetivo. Vou deixar essa explicação para um próximo post. Então, a princípio escolha a revisão em vigor na sua máquina antes de atualizar.

O ACBrMTER passou por um amplo refactoring na revisão 16602. Eu sugiro você verificar as alterações. Para investigar o caso você poderia ligar o log e comparar as duas versões, antes e depois da atualização, pra analisar o que está acontecendo de diferente. Eu faria isso.

Me parece que ninguém está desenvolvendo isso para ser disponibilizado no projeto. Infelizmente...

Só pra confirmar a alteração foi enviada na revisão 16707.