Minha pergunta ao Gemini através do Google AI Studio: “Quando trabalhamos com o FDQuery, o qryLista por exemplo, não precisamos ter um componente FDMemTable para deixar os dados e ligar esse componente ao DataSource e ao DBGrid? Quando eu preciso usar um MemTable? Me explane sobre isso”
Essa é uma dúvida muito comum, especialmente para quem veio da “Escola Midas/DataSnap” ou usava o antigo dbExpress.
A resposta curta é: NÃO. Você não precisa (e neste caso, nem deve) usar um FDMemTable ligado ao FDQuery para exibir dados no Grid.
Vou explicar o porquê tecnicamente e quando o FDMemTable realmente é útil.
1. O Mito do ClientDataSet
Antigamente (dbExpress), o componente de Query (TSQLQuery) era Unidirecional. Ele servia apenas para passar o “cursor” banco a frente. Se você tentasse ligar um DBGrid nele, dava erro ou o Grid ficava estranho, pois o Grid precisa ir para frente e para trás.
Por isso, éramos obrigados a usar o trio: SQLQuery -> DataSetProvider -> ClientDataSet. O ClientDataSet era quem guardava os dados na memória RAM.
2. A Arquitetura do FireDAC (FDQuery)
O FDQuery já é um ClientDataSet embutido.
A arquitetura interna do FireDAC é baseada em algo chamado DatS (Data Storage).
Quando você dá um Open no FDQuery, ele faz duas coisas:
- Driver: Vai no Firebird e busca os dados.
- Memória: Armazena esses dados num buffer local interno (igualzinho o MemTable faz).
Portanto, o FDQuery é Bidirecional e Navegável. Você pode ligar o DataSource direto nele.
Por que NÃO usar FDMemTable para a sua Listagem (qryLista)?
Se você fizer FDQuery -> FDMemTable (usando DataS.Copy ou BatchMove), você mata a sua funcionalidade de Fetch On Demand.
Para o FDMemTable funcionar, ele precisa ter os dados nele. Geralmente, para preenchê-lo, você teria que varrer a Query inteira, trazendo 1 milhão de registros para a memória RAM de uma vez, travando sua aplicação.
Usando o FDQuery direto no Grid, ele gerencia a memória inteligentemente: “O Grid quer ver a linha 50? Baixo a 50. Quer ver a 100? Baixo a 100”.
3. Então, para que serve o FDMemTable?
O FDMemTable é uma ferramenta poderosa, mas para outros cenários. Use-o quando:
A. Dados Voláteis (Sem Banco de Dados)
Você precisa de uma grid para o usuário lançar “Itens do Pedido” antes de salvar.
- Não faz sentido criar uma tabela temporária no banco.
- Você cria um
FDMemTable, define as colunas (FieldDefs) manualmente via código ou design. - O usuário insere, deleta, edita tudo na memória RAM.
- No final, você percorre o
FDMemTablee grava no banco usando umaFDQueryde Insert ouArray DML.
B. Recebendo dados de API REST (JSON)
Se seu sistema Desktop consumir uma API Web.
- A API retorna um JSON.
- O FireDAC tem componentes (
FDStanStorageJSON) que carregam esse JSON direto para dentro de umFDMemTable.
C. Clonagem de Dados (Sombra)
Você quer editar um registro, mas quer ter uma cópia do original para comparar “Antes vs Depois” sem ir ao banco de novo.
FDMemTable1.CloneCursor(FDQuery1); Isso cria uma “visão” paralela dos mesmos dados em memória.
D. Mestre-Detalhe Complexo em Memória
Às vezes você quer carregar toda a estrutura de um Pedido (Cabeçalho + Itens + Parcelas) para a memória para trabalhar desconectado e salvar tudo de uma vez depois (Cached Updates em Nível de Aplicação). O FDMemTable é excelente para trabalhar desconectado.
Resumo para seu ERP
Para a tela de Listagem de Itens (UItens) que desenhamos:
- Use:
FDConnection->FDQuery (qryLista)->DataSource->DBGrid. - Ganho: Performance, Fetch on Demand, Menor consumo de RAM.