Parte XIII – Aplicações desconectadas

Neste exemplo, veremos como usar o dbExpress e ClientDataSet para obter dados do banco de dados, sem no entanto manter uma conexão sempre ativa com o mesmo. Isso fará com que suas aplicações se tornem mais escaláveis e apresentem uma melhor performance quando o número de clientes aumentar.

Para isso, vamos fazer o seguinte: abriremos a conexão e o cursor de dados somente o tempo mínimo necessário para executar o select. A partir daí, o DataSetProvider irá empacotar os dados em um DataPacket que será armazenado no Data do ClientDataSet. A seguir, fechamos a consulta e a conexão, e o usuário poderá continuar trabalhando normalmente (com dados em cache). Quando for necessário aplicar os dados no servidor, abrimos novamente a conexão e enviamos o Delta.

O mais interessante de tudo é que o próprio DataSetProvider já realiza a maioria desse trabalho para nós: ele sabe exatamente o momento que se faz necessária uma conexão, se encarrega de abri-la, executar a query (que também é aberta por ele) e assim por diante. Precisamos apenar configurar algumas propriedades. Vamos a prática.

Configure uma conexão dbExpress para o banco EMPLOYEE do Interbase. Coloque um SQLConnection apontando para essa conexão. Coloque também um SQLQuery, um DataSetProvider, um ClientDataSet, um DataSource, um DBGrid, dois Buttons e um Memo. Configure os componentes conforme o código a seguir:


            object DBGrid1: TDBGrid

    DataSource = DataSource1

  end

  object DataSource1: TDataSource

    DataSet = ClientDataSet1

  end

  object ClientDataSet1: TClientDataSet

    ProviderName = 'DataSetProvider1'

  end

  object DataSetProvider1: TDataSetProvider

    DataSet = SQLQuery1

  end

  object SQLQuery1: TSQLQuery

    SQLConnection = SQLConnection1

  end

  object SQLConnection1: TSQLConnection

    ConnectionName = 'EMPLOYEE'

    LoginPrompt = False

    Connected = False

    KeepConnection = False

    Params.Strings = (

      'DriverName=Interbase'

      'Database=C:\Borland\InterBase\examples\database\employee.gdb'

      'User_Name=sysdba'

      'Password=masterkey'

      'ServerCharSet=WIN1252'

      'SQLDialect=3')

  end
        

Seu formulário deve estar semelhante ao mostrado a seguir:

Figura 1
Figura 1.
Figura 2
Figura 2.

Observe como configurei as propriedades Connected e KeepConnection do SQLConnection, ambas para False. A SQLQuery também tem o Active configurado para False.

O código do botão Executar repassa para a SQLQuery a instrução SQL (Select) digitada no Memo:


            procedure TFrmMain.BitBtn1Click(Sender: TObject);
begin

  SQLQuery1.SQL.Assign(Memo1.Lines);

  ClientDataSet1.Close;

  ClientDataSet1.Open;

end;
        

Execute a aplicação, digite uma instrução SQL e clique no botão Executar (veja a figura a seguir).

Figura 3
Figura 3.

Quando fazemos a consulta, os seguintes procedimentos foram realizados pelo dbExpress:

  • ClientDataSet (CDS) recebe a chamada ao Open;
  • CDS chama o método de interface As_GetRecords;
  • DataSetProvider (DSP) recebe a chamada ao GetRecords;
  • DSP abre a conexão (SQLConnection);
  • DSP abre o cursor da SQLQuery;
  • DSP varre os dados da consulta;
  • DSP empacota os dados;
  • DSP fecha o cursor (SQLQuery);
  • DSP verifica a propriedade KeepConnection, como está False, fecha a conexão com o BD;
  • DSP envia o DATA ao CDS;
  • CDS fica com dados em memória.

Mesmo com a aplicação em execução, podemos comprovar que não há nenhuma conexão ativa com o servidor.

Figura 4
Figura 4.

O botão Apply simplesmente chama o ApplyUpdates para atualizar o BD: o DSP se encarregará de abrir todas conexões necessárias e novamente, fechar após a operação.

Use o KeepConnection com cuidado: em um cenário onde o cliente irá frequentemente enviar solicitações (selects, updates etc.) ao BD, não é uma boa solução ter essa propriedade configurada. Ela é ideal para quando o usuário irá trabalhar de forma desconectada, em um conjunto de dados maior, por um longo período de tempo.

Outro lembrete: não use o Packet Records com essa abordagem, pois exige intensa comunicação com o servidor SQL. Pelo motivo anterior, essa combinação não faria sentido.

Leia todos artigos da série