> ----- Original Message ----- > From: "Eduardo RC Neto" <[EMAIL PROTECTED]> > > Só tem um problema com ele: > Quando vc entra na tela que tem esse TDBEdit, vc terá que abrir a tabela a > qual esse > TDBEdit está ligado. > Agora imagine um sistema, rodando Clinet/Server, uma central de atendimento, > por exemplo. > 300 usuários trabalhando o dia inteiro, na mesma tela, com 300 conexões > simuntâneas > com o banco de dados!!!
"Malta" (*), Relembrem que nem todos os componentes descendentes de TDataSet funcionam do mesmo modo. Por isso é que esta discussão é bem difícil de gerir, se não se falar de casos concretos. Este exemplo do Eduardo é bem válido em algumas circunstâncias, mas não depende do TDBEdit, mas depende do componente de acesso a que este componente está ligado. Por exemplo, imaginemos que este TDBEdit esteja conectado a uma TIBOQuery (dos componentes TDataSet descendants do IBO do Jason). Basta configurar a TIBOQuery correctamente, que o próprio IBO ao fim de X tempo vai fechar automaticamente a transacção que está a correr (por timeout) e abrir 'graciosamente' no momento que esta query necessitar de novo da mesma. O tempo é definido como propriedade da query, pelo que pode ser no segundo seguinte a ter ido recolher os dados. Agora imaginemos vários TDBEdits ligado à query, e que o registo entra em modo de alteração, e se faz Post. A TIBOQuery não envia para o servidor o update dos campos que não foram alterados, mas apenas daqueles que o foram: foi da responsabilidade deste objecto reduzir os custos do servidor e do trafego da rede. É ainda possível a TIBOQuery fazer automaticamente um refresh de apenas aquela row que foi alterada, sem ter que fazer refresh de toda a "Tulpa". Isto apenas definindo uma propriedade da Query. Entretanto, o uso de um TDBEdit não vai trazer mais overhead a esta situação. De facto, o object TDBEdit está a fazer o que pretendemos dele, e de uma forma eficaz - reporta um valor e permite uma alteração, 'avisando' nesse caso o objecto que o "alimenta". Este é um exemplo simples de uma Query com TDBEdit que permite ser usada sem qualquer trabalho de maior num ambiente com 300 users em simultâneo, sem consumir qualquer recurso do lado do servidor, e sem uma única linha de código. Perfeito para mil e uma aplicações: simples, e faz o trabalho de uma forma limpa. Neste caso, substituir um TDBEdit por um TEdit é apenas uma questão de gostar de ter trabalho a mais, e se calhar nem fica tão bem feito. Posso porém pegar neste mesmo exemplo, e mudando apenas umas propriedades da mesma TIBOQuery, tornar o seu uso completamente impraticável nesta situação, afundando o servidor em poucos segundos com as tais 300 conexões. E ainda poderia só mudando também algumas propriedades da mesma TIBOQuery, fazer o servidor se portar decentemente com algumas poucas conexões - 10 ou 20 - que pode viver assim anos se uma empresa não crescer, e só dar por isso passando um tempo. A conclusão geral desta discussão é bem simples: depende, depende, depende. :-) E reparem que no exemplo que dei toda a realidade do comportamento da aplicação é aboslutamente independente do uso do TDBEdit ou do TEdit... Depende sim, mas de uma outra coisa. Artur (*) Malta = Galera em PT_PT :-) -- <<<<< FAVOR REMOVER ESTA PARTE AO RESPONDER ESTA MENSAGEM >>>>> Para ver as mensagens antigas, acesse: http://br.groups.yahoo.com/group/delphi-br/messages Para falar com o moderador, envie um e-mail para: [EMAIL PROTECTED] ou [EMAIL PROTECTED] Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/delphi-br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
