EMBarbosa

Você deve procurar o suporte do sistema em questão.

Tenta usar o IB DataPump. https://www.clevercomponents.com/products/datapump/dp-tour.asp

Na imagem abaixo circulado está a sua dll (no caso uma bpl). Sublinhado está as dlls que sua dll precisa. Algumas tem dependências em outras dlls. Normal, principalmente quando são as dlls do Windows como essa kernel32. Mas não se preocupe com essas. Seguindo a seta você vai verificar as outras dlls. Verifique se elas existem.

Pelo visto você está utilizando o firebird, mas o SQL que você montou não é compatível com o SQL do Firebird. Se você apenas quiser copiar as tabelas eu sugiro você utilizar uma aplicação específica para isso como: ib datapump fbcopy fbextract ibexpert entre outros. Tem vários tópicos aqui no fórum sobre isso.

Não nesse caso. Esse é um callstack da IDE. Mas não tem nenhuma informação adicional que seja interessante. Acho que se você for usar o Dependency walker e analisar a sua bpl, vai conseguir identificar quais dlls estão faltando.

Várias maneiras. Qual a melhor vai depender dos objetivos e do seu ambiente. Aqui mesmo no fórum tem alguns tópicos sobre o assunto.

Se não puder pagar pelos componentes como da DevExpress ou da TMS, tente usar o DBUltimateGrid da JVCL como o Juliomar disse. Se em todo o caso não for possível e você não quiser muito trabalho para desenhar no canvas, é bem simples você alterar a fonte da barra de título colocando um negrito na coluna ordenada. Não fica tão didático, mas funciona e é muito simples de implementar.

Veja o comando TDataset.FetchAll

De que tipo é esse campo? String|VARCHAR? Ou TDateTime|Timestamp

Oi Daniel, Essa mensagem "Não foi possivel encontrar o módulo especificado" acontece quando não foi possível carregar uma dll. Então pode ser várias coisas. Sugiro verificar o seguinte: Como uma bpl é uma dll com algumas especificações diferentes, verifique que no momento da instalação realmente existe o arquivo mencionado na mensagem de erro. A saber "C:Projetos\Componentes\Controle\Proprios\Controle.bpl"; Verifique se seus componentes precisam de outras dlls, e que elas também existam na pasta da bpl ou do Delphi; Se seus componentes foram convertidos do Delphi 7 ou anterior pode ser que existam algumas dependências que o Delphi não conseguiu encontrar. Você pode usar um aplicativo como o "Dependency Walker" ou "SysInternals ProcessMonitor" para verificar qual dll está faltando para essa bpl funcionar. Daí copie o arquivo pra pasta da bpl

Fico feliz de ter ajudado. Mas é como eu tinha dito antes: O problema é que há registros que estão sendo carregados na hora da inserção. Eu teria que ver o código novamente pra poder te dar mais detalhes, mas na minha cabeça é mais ou menos assim que está: Você faz o Insert e preenche o registro no TClientDataset; O TClientDataset faz as validações de acordo com os TFields e por isso não precisa de acessar o BD; Quando você faz um post, o TClientDataset confirma os dados, mas ainda não manda pro BD; Na hora que você faz um ApplyUpdates, o "cds" vai enviar os dados pro BD; ele executa um open no componente que é a fonte dos dados; Ele converte o registro para o formato que é a fonte dos dados (por exemplo um "insert em formato SQL"); Daí executa o insert e faz o commit; Esse passo 5 acima é onde acontece a lentidão. Porque ao abrir a fonte de dados ele carrega muitos registros. Mas aí você vai dizer: "Mas e o packedRecords?" E a resposta é que PackedRecords não é quantidade de registros. É quantidade de registros no pacote. Isso quer dizer que quando você diminui você pode até mesmo tornar a situação ainda mais lenta. É como um pacote que você usa no mercado. Se ele couber poucos volumes, você vai precisar fazer mais viagens. É mais ou menos isso...

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.