Construindo Aplica§µes com ClientDataSet e InterBase Express

  • View
    234

  • Download
    3

Embed Size (px)

Text of Construindo Aplica§µes com ClientDataSet e InterBase Express

Construindo Aplicaes com ClientDataSet e InterBase ExpressIsto um documento tcnico de uma conversa ocorrida na 12 conferencia anual dos desenvolvedores Borland Por Bill Todd The Database Group, Inc. Traduzido por Cludio Srgio Gonalves claudio@clarosistemas.com.brBill Todd presidente da Database Group, Inc.Empresa de consultoria em Banco de dados e Desenvolvimento que fica perto de Phoenix. Ele co-autor de quatro livros de programao de Banco de dados e mais de 80 artigos, e um membro do time que d suporte tcnico no newsgroup da Borland.Ele um orador freqente nas conferencias de desenvolvedores Borland nos EUA e Europa. Bill tambm um conhecido professor e tem diversas classes de programao nos EUA e outros paises.

Introduo Problemas com Interbase Express Usando ClientDataSet Construindo o Data Module Construindo a interface do usurio Alterando os Dados Tratando Erros de Atualizao Ordenando os Dados Mostrando o Status do Registro

IntroduoAgora que o componente ClientDataSet est disponvel nas verses Professional e EnterPrise do Delphi e C++ Builder, hora de olhar as vantagens de usar os ClientDataSets em combinao com os componentes Interbase Express para construir aplicaes Interbase. Como voc ver neste texto existem muitas vantagens em usar ClientDataSets em suas aplicaes. Esta a razo porque o componente ClientDataSet a base da nova arquitetura Dbexpress da Borland. Existem tambm muitas razes pra usar Interbase Express (IBX) para construir aplicaes Interbase. Primeiro, o IBX muito menor e fcil de desenvolver que o BDE. Segundo, o IBX tem acesso mais rpido ao banco de dados Interbase que o BDE. Finalmente, IBX d acesso a caractersticas do Interbase que no esto disponveis pelo BDE tais como mltiplas transaes simultneas, grande variedade de nveis de isolao das transaes e acesso a CommitRetaining e RollbackRetaining.

Problemas com Interbase ExpressO maior problema que desenvolvedores encontram trabalhando com os componentes IBX que todo acesso a um banco de dados Interbase deve ser feito dentro do contexto de uma transao. Isto significa que voc no pode sequer ler ou mostrar o contedo de um registro sem iniciar uma transao. O problema que quando voc d commit ou rollback na transao, todos os datasets includos no componente IBTransaction so fechados e o usurio de repente esta olhando uma tela que no mostra nenhum registro. Voc pode ver o efeito no programa IBXDemo que acompanha este texto. A tela seguinte mostra o form principal aps o boto open ter sido clicado. A prxima tela mostra o form aps o click no boto Commit

Lgico que existem modos de lidar com isto, e a aplicao IBXDEMO mostrar um deles. Se voc verificar o checkbox Reopen antes de clicar no boto Commit, o programa salva o cdigo da chave primaria das tabelas employee e salary history,

confirma (commit) a transao, reabre os dois IBDataSets e posiciona nos registros que estavam antes do commit. A mesma coisa acontece se voc clicar no boto Rollback. Isto funciona, mas um bocado de trabalho extra. Outra soluo seguir a filosofia normal do propsito Cliente/Servidor que iniciar o usurio com uma tela em branco e pedir um critrio de seleo para trazer um pequeno numero de registros para trabalho. O usurio pode ento fazer quaisquer alteraes nos registros e confirmar(commit) as alteraes. Quando as alteraes so confirmadas o usurio estar novamente com uma tela em branco para selecionar outro conjunto de registros. Este acesso requer menos cdigo, mas pode deixar as transaes abertas por um tempo longo demais. Por exemplo, suponha que um usurio precise alterar centenas de registros dos clientes do estado do Paran. Se o usurio selecionou todos os clientes do Paran de uma vez, ele gastar diversas horas de trabalho para fazer tudo. Isso causa dois problemas em potencial. Primeiro, se seu computador travar, todas as alteraes sero desfeitas(rollback) e todo o trabalho ser perdido. Segundo, a transao ficar aberta por muitas horas com centenas de registros alterados e travados e no podero ser alterados por outros usurios. Outra soluo que muitos desenvolvedores usam chamar CommitRetaining ou RollbackRetaining ao invs de Commit ou Rollback. Num primeiro momento isso parece ser a soluo ideal, pois no fecha as tabelas e permite ao usurio continuar a ver e alterar os registros selecionados. Entretanto, CommitRetaining e RollbackRetaining no fecham sua transao. Isso significa que voc est usando um isolamento de transao do momento e voc no pode ver quaisquer alteraes feitas por outros usurios at voc confirmar (commit) ou desistir (Rollback). Tambm significa que voc desabilitou a "garbage collection" do Interbase forando ele a manter a transao aberta e as informaes dos registros de quando a transao foi iniciada. Isso causa problemas graves de performance em um sistema multiusurio, com muitos usurios alterando diversos registros. Isso nitidamente o caso em que a cura pior que a doena.

Usando ClientDataSetO componente ClientDataSet um dos componentes da palheta Midas, usado para implementar a estratgia de prover/resolver a edio de registros que foi introduzido como parte do Midas no Delphi 3. Antes de entrar em detalhes de construir uma aplicao que usa os componentes DataSetProvider, ClientDataSet e IBX, vale a pena examinar os fundamentos da estratgia de prover/resolver do Midas. A estratgia Prover/Resolver O mecanismo prover/resolve usa um componente DataSetProvider para enviar os dados de um componente Dataset a um ClientDataSet. O componente ClientDataSet guarda os registros recebidos do provedor na memria. Usurios podem inserir, apagar e alterar os registros e as alteraes tambm so guardadas na memria pelo ClientDataSet. Quando o usurio terminar as alteraes, uma chamada ao mtodo ApplyUpdates do ClientDataSet envia as alteraes para o provider. O provider ento gera as instrues SQL necessrias para executar as alteraes no banco de dados (inicia uma transao, envia as instrues SQL para o servidor e, se no houver erros, confirma (commit) a transao).

Numa explicao bsica, voc pode ver as vantagens desta arquitetura. Primeiro, as transaes ficam abertas muito pouco tempo. Quando voc abre um ClientDataSet que est conectado a um DataSetProvider, o provider que abre o dataset que est conectado a ele. Quando o dataset aberto, ele executa sua instruo de SQL SELECT e retorna os registros para o provedor que ento os envia para o ClientDataSet fechando o dataset e confirmando (commit) a transao de leitura. Quando voc chama o mtodo ApplyUpdates do ClientDataSet as alteraes so enviadas para o provider que gerar as instrues SQL necessrias, inicia a transao, envia as instrues SQL para o banco de dados e confirma (commit) a transao. Isto faz com que as transaes de leitura e escrita sejam bem rpidas, o que significa que outros usurios no estaro bloqueados por longo tempo. Transaes rpidas tambm significa que o numero de transaes abertas ao mesmo tempo sero menores e o acesso ao banco de dados menor. A segunda grande vantagem desta estratgia te dar o controle da quantidade de dados a serem trabalhados, uma vez que voc controla a instruo SQL que executada, voc controla quantos registros sero trazidos do servidor o que te da o controle sobre o trafego que ser gerado na sua rede e o quanto de memria voc usar para armazenar os registros. Isto ser particularmente valioso se voc estiver desenvolvendo uma aplicao que ser usada numa WAN ou num link de baixa velocidade. Construindo o Data Module A prxima figura mostra o data module da aplicao de exemplo CDSIBX.

Este data module projetado para suportar o form que mostra a relao um-para-muitos entre a tabela Employee e a tabela Salary_History. A tabela employee selecionada pelo departamento. Por outro lado o dataset Employee inclui um campo lookup no

campo Dept_No o qual mostra o nome do departamento. O componente IBDatabase no canto superior esquerdo est configurado exatamente como estaria numa aplicao que somente usa componentes IBX. A seguir vem trs componentes IBTransaction, um para cada tabela usada na aplicao. Quando usar ClientDataSets voc deve usar um componente de transao separado para cada tabela uma vez que diferentes tabelas podem interagir com o banco de dados simultaneamente. A seguir usa-se um componente IBQuery para cada tabela. Verifique que a propriedade Unidirectional de todos os componentes IBQuery est setado como True para reduzir o consumo de memria e aumentar a performance. Uma vez que estes componentes query sero somente usados para trazer o dados da query para o componente DataSetProvider no h necessidade de retornar os dados. Embora o componente IBQuery traga um conjunto de dados read-only, isso ser mais que necessrio uma vez que alteraes no banco de dados sero controladas automaticamente pelo componente DataSetProvider. A propriedade SQL do componente EmpQry ser:Select * from EMPLOYEE Where Dept_No = :Dept_No order by Last_Name, First_Name

ento os registros de um nico departamento sero selecionados. A instruo SQL para o componente SalHistQry :select * from SALARY_HISTORY where Emp_No = :Emp_No order by Change_Date desc

Neste caso o parmetro, :Emp_No, tem o mesmo nome que o campo da chave primaria da tabela Employee e a propriedade DataSource do componente SalHistQry esta setada para EmpSrc, o componente DataSource que esta conectado ao componente EmpQry. Isto determina ao componente SalHistQry para pegar o valor do parmetro do registro corrente de EmpQry. Isto traz somente os registros do histrico de salrios dos empregados que esta selecionado. A propriedade SQL do componente DeptQry e:select DEPT_NO, DEPARTMENT from DEPARTMENT order by Dept_No

o qual seleciona todos os nomes e nmeros dos departamento. Um nico componente DataSetProvider o provider do componente EmpQry. A propriedade Dataset do provider esta setada para EmpQry. Nenhum provider necessrio para o componente SalHistQry porque seus registros sero includos num campos d