Artigo Clube Delphi Edição 18 - O PORQUÊ DE CONCILIAR ERROS AMIGAVELMENTE

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Artigo da Revista Clube Delphi Edição 18.

Esse artigo faz parte da revista Clube Delphi edição 18. Clique aqui para ler todos os artigos desta edição

 

Atenção: por essa edição ser muito antiga não há arquivo PDF para download. Os artigos dessa edição estão disponíveis somente através do formato HTML. 

 

O PORQUÊ DE CONCILIAR ERROS AMIGAVELMENTE

 

A grande maioria dos e-mails que tenho recebido tratam de um assunto bastante complexo: quais são, dentro de uma série de situações, os métodos mais aconselháveis para tratar condições de erro no momento da gravação dos dados.

Claro que podemos – e devemos – olhar com cuidado e zelo para estas características de desenvolvimento, e é ótimo saber que tenhamos muitos desenvolvedores com esse nível de preocupação e cuidado, mas temos de ver a situação com outros olhos. Quando tentamos “manter o controle” sobre as condições em que os dados estão sendo atualizados, corremos o risco de estarmos indo além de nossas atribuições como desenvolvedores.

Normalmente, aconselho a qualquer pessoa que avalie a situação antes de “cometer” algumas perguntas, pois, em determinadas situações, conhecer mais profundamente alguns recursos nos ajuda a sermos mais criteriosos e objetivos em nossas decisões e atitudes.

A pergunta-chave que me foi enviada pede um porquê para que eu não tenha apresentado um método de conciliação onde simplesmente grava-se os dados na base, registrando-se isso em um arquivo de log e ponto final. Pois bem, a preocupação de registrar o ocorrido em um log já é alguma coisa, mas o fato de puxar para o aplicativo a responsabilidade por gravar (ou não) determinada informação dessa ou daquela forma extrapola o nível de decisão do desenvolvedor e deixa de ser uma reconciliação, passando a ser uma imposição.

O que queremos é justamente não assumir uma responsabilidade que não nos cabe. Não devemos fazer com que o software tome decisões, não é esse seu papel dentro do contexto de sua utilização, e isso deve sempre ficar a cargo do usuário. Justamente por esse motivo, não implementei uma solução tão radical.

Desta forma, os mecanismos apresentados tratam a situação de formas consideradas mais “amigáveis” para o usuário; usando raMerge, os dados são relidos da base, porém as alterações feitas pelo usuário são preservadas, e neste momento o papel do software é informar que alguma coisa está ocorrendo: mostrar as diferenças das informações e então deixar para que o usuário decida se deve ou não continuar com o processo de gravação.

Vamos a um exemplo: se o usuário tentar gravar o registro de um determinado cliente e no momento que o botão “GRAVAR” for pressionado, um aviso de que o campo “INSCRIÇÃO ESTADUAL” foi alterado e que a informação foi atualizada lhe será apresentado. Nesse momento o software executa um raMerge e apresenta o campo atualizado; ele pode ver aquilo e dizer “E daí ???” e mandar gravar assim mesmo. Ótimo, tudo se processou como devia, mas quem tomou a decisão não foi o software, e é ai que esta o ponto principal dessa técnica.

Usando TclientDataset sem BDE

Diversas vezes encontramos situações onde a base de dados ocupa uma posição secundária em um aplicativo. O foco está em outros recursos que o software pode oferecer, e nestas situações somos obrigados a recorrer a outros recursos de gravação e administração de dados menos eficientes ou mais trabalhosos que os tradicionais componentes Ttable, Tquery, Tdatasource, entre ouros, tradicionalmente colocam à nossa disposição.

TclientDataset proporciona o trabalho com dados sem a necessidade de uma conexão via BDE, DAO ou qualquer outro mecanismo externo ao seu executável.

É obvio que isto nos impõe determinadas limitações. Tudo tem seu preço e seu valor, e o fato de não termos um forte mecanismo de tratamento de dados por trás de nosso aplicativo tem a primeira conseqüência direta, e provavelmente a mais forte, sobre o controle de acesso: não podemos ter múltiplos acessos em nosso arquivo. Sendo assim, estamos trabalhando de novo em um ambiente “monousuárioL.

Existem dois formatos de arquivo suportados por TclientDataset. Quando trabalhamos com um arquivo criado nestas condições o formato adotado automaticamente é de arquivo binário.

Criando um Dataset do tipo “Single File”

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?