Fórum Registro no BUFFER com CLIENTDATASET #283495
31/05/2005
0
Pessoal
Estive lendo um assunto sobre o ClientDataset onde ele pode fazer um controle de registros a serem bufferizadas através da propriadade packetrecords. Coloquei o valor dessa propriedade para 30, isto é, na navegação de registros, devem ser bufferizadas de 30 em 30 registros.
Achei que na navegação seria mais leve do que deixasse a o valor dessa propriedade para - 1 onde ele faz o controle total de bufferização. Mas na navegação não vi diferença nenhuma. São 10.000 registros que tem na tabela. Estou usando o Firebird 1.5 e Delphi 7
Alguém poderia explicar melhor isto ??? A navegação teria que ficar mais leve, Certo ?? Ou eu estou errado....
Rogério
Estive lendo um assunto sobre o ClientDataset onde ele pode fazer um controle de registros a serem bufferizadas através da propriadade packetrecords. Coloquei o valor dessa propriedade para 30, isto é, na navegação de registros, devem ser bufferizadas de 30 em 30 registros.
Achei que na navegação seria mais leve do que deixasse a o valor dessa propriedade para - 1 onde ele faz o controle total de bufferização. Mas na navegação não vi diferença nenhuma. São 10.000 registros que tem na tabela. Estou usando o Firebird 1.5 e Delphi 7
Alguém poderia explicar melhor isto ??? A navegação teria que ficar mais leve, Certo ?? Ou eu estou errado....
Rogério
Rogeranalista
Curtir tópico
+ 0
Responder
Posts
31/05/2005
Vinicius2k
Colega,
Não necessariamente. A configuração de PacketRecords determina quantos registros são trazidos por vez do servidor para o cliente. Normalmente, traz um ganho expressivo de performance em RecordSets com muitos registros, mas a aplicação de alguns métodos e/ou leitura de algumas propriedades do TClientDataSet invalidam a configuração, forçando o fetch de todos os registros para o lado do cliente de uma só vez.
Destes métodos/propriedades o mais comuns são: Last, Locate, IsEmpty, EOF e RecordCount, além da presença de TFields ´Lookup´ em outro DataSet referenciando este. Se algum destes estiver sendo utilizado, PacketRecords não tem efeito.
T+
Não necessariamente. A configuração de PacketRecords determina quantos registros são trazidos por vez do servidor para o cliente. Normalmente, traz um ganho expressivo de performance em RecordSets com muitos registros, mas a aplicação de alguns métodos e/ou leitura de algumas propriedades do TClientDataSet invalidam a configuração, forçando o fetch de todos os registros para o lado do cliente de uma só vez.
Destes métodos/propriedades o mais comuns são: Last, Locate, IsEmpty, EOF e RecordCount, além da presença de TFields ´Lookup´ em outro DataSet referenciando este. Se algum destes estiver sendo utilizado, PacketRecords não tem efeito.
T+
Responder
Gostei + 0
31/05/2005
Lindomar.des
Rogério,
Permita-me fazer uma introdução. Venho do paradox.. tinha um sistema que trazia todos os registros do servidor p/ o cliente e usava e abusava de : first, prior, next, last, recordcount, etc.. todos os compandos campos que recuperassem todos os registros do servidor. Após algum tempo começaram a ocorrer corrupção de algumas tabelas, e tb veio a limitação de qtd de registros. Corri para o FB. Tive que migrar a toque de caixa e sem muito tempo para aproveitar todos os recursos dessa maravilha que é o FB. Logo, continuie trazendo todos os registros do servidor, cometendo os mesmos erros. Mas optei por essa forma devido ao receio que tive do impacto que seria para os clientes não poder navegar/visualizar todos os registros. Por um lado foi bom que, eles, vendo a lentidão que o sistema virou, pude argumentar solução de usar filtros (sql´s parametrizáveis). Ainda estou reescrevendo algumas telas.
Concluindo.... não aconselho a ninguém trazer vários registros para manutenção. O cliente não irá alterar mais de um registro por vez. Hoje abro a tela totalmente vazia, daí o usuário seleciona o registro (por código,. parte do nome, etc) altera salvar seleciona outro. É claro, se ele optar por seleciona todos os produtos que contenha na sua descrição a palavra SHAMPOO, dependendo do cadastro viram algumas dezenas de registro. Mas nesse caso será de responsabilidade dele.
Espero não ter sido cansativo e ter contribuido em algo.
Permita-me fazer uma introdução. Venho do paradox.. tinha um sistema que trazia todos os registros do servidor p/ o cliente e usava e abusava de : first, prior, next, last, recordcount, etc.. todos os compandos campos que recuperassem todos os registros do servidor. Após algum tempo começaram a ocorrer corrupção de algumas tabelas, e tb veio a limitação de qtd de registros. Corri para o FB. Tive que migrar a toque de caixa e sem muito tempo para aproveitar todos os recursos dessa maravilha que é o FB. Logo, continuie trazendo todos os registros do servidor, cometendo os mesmos erros. Mas optei por essa forma devido ao receio que tive do impacto que seria para os clientes não poder navegar/visualizar todos os registros. Por um lado foi bom que, eles, vendo a lentidão que o sistema virou, pude argumentar solução de usar filtros (sql´s parametrizáveis). Ainda estou reescrevendo algumas telas.
Concluindo.... não aconselho a ninguém trazer vários registros para manutenção. O cliente não irá alterar mais de um registro por vez. Hoje abro a tela totalmente vazia, daí o usuário seleciona o registro (por código,. parte do nome, etc) altera salvar seleciona outro. É claro, se ele optar por seleciona todos os produtos que contenha na sua descrição a palavra SHAMPOO, dependendo do cadastro viram algumas dezenas de registro. Mas nesse caso será de responsabilidade dele.
Espero não ter sido cansativo e ter contribuido em algo.
Responder
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)