Artigo Clube Delphi Edição 37 - Do Clipper para o Delphi

Do Clipper para o Delphi

Migração tranqüila com o Advantage Database Server

Um problema que, vez por outra, aparece para os desenvolvedores é a necessidade de migrar sistemas antigos, escritos em Clipper, para Delphi. Normalmente são sistemas implantados há vários anos na empresa, já com diversas "atualizações" e uso bastante difundido. Sua substituição não pode ser feita de qualquer maneira, pois o sistema está implantado em praticamente todos os departamentos e os arquivos DBF contêm a vida da empresa dos últimos 10 a 15 anos. Além disso, o desenvolvimento de um novo sistema, do porte do que está implantado, levaria muito tempo para ser finalizado.

Como fazer para que o novo sistema conviva pacificamente com o antigo, enquanto os módulos vão sendo desenvolvidos? É necessário que ambos os sistemas acessem e atualizem os mesmos dados de maneira transparente, sem conflitarem entre si.

Pensando numa solução

A primeira idéia que vem à mente é usar o BDE com arquivos DBF. Mas essa abordagem tem o  problema de não permitir o uso dos índices nativos do Clipper (arquivos NTX), além de apresentar problemas de locking – o sistema de travamento de registros do BDE não é o mesmo do Clipper; usando-se a RDD MDX, para dBase IV, disponível no Clipper 5.01, 5.2 ou 5.3, pode-se solucionar o problema dos índices, mas não o problema do travamento. Além disso, o driver BDE para arquivos dBase não traz muita confiabilidade, e reindexações constantes são ainda necessárias. Assim, o que parecia uma solução passa a ser um problema ainda maior.

A segunda idéia é abandonar, definitivamente, os arquivos DBF, passando para uma solução cliente/servidor mais robusta – MS SQL Server, Oracle, InterBase, MySQL, PostgreSQL são alguns dos bancos de dados sugeridos quando analisamos essa idéia. Sem dúvida, o uso de um desses bancos traria  grandes vantagens ao sistema; maior confiabilidade e robustez, maior velocidade e menor tráfego na rede são algumas delas.

Porém há um problema: o que fazer enquanto o sistema estiver sendo desenvolvido? Seguindo essa abordagem, o sistema precisaria ser construído completamente e implantado de uma vez só. Um dia os usuários, ao chegarem ao trabalho, ligariam seus computadores, e no lugar de sua velha e familiar tela DOS encontrariam um sistema novinho em folha, escrito em Delphi, acessando um banco de dados cliente/servidor.

Essa idéia, na teoria, é excelente, mas na prática... Imagine só, nesse dia, quando os chamados de suporte começarem a aparecer de todos os departamentos da empresa, sejam eles relativos a partes do programa que não funcionam, a consolidações que não foram feitas ou estão incorretas, ou de operadores que não sabem trabalhar com o sistema. Tudo isso, além do problema de o que fazer com os dados antigos – temos de garantir uma migração para a nova plataforma com o mínimo de perdas possível. Sem dúvida, é uma idéia viável, mas de difícil implementação.

Uma abordagem mais conveniente

O mais conveniente seria uma solução que permitisse usar os arquivos DBF antigos, com o mínimo de modificações no sistema em Clipper (se possível, sem nenhuma mudança), e que tivesse confiabilidade para não trazer mais problemas. Dessa maneira, o sistema poderia ser desenvolvido modularmente, ou seja, com cada módulo sendo testado antes de implantado, e com problemas na implantação podendo ser solucionados antes da passagem para o próximo módulo. Uma opção é usar o Advantage Database Server (ADS), que permite acessar tabelas DBF com a confiabilidade de um banco de dados cliente/servidor.

O ADS, que já se encontra na versão 6, é uma ferramenta cliente/servidor multiplataforma, que permite acessar tabelas DBF, mas trabalha de maneira muito diferente do Clipper ou do dBase. Estas são ferramentas desktop, nas quais todo o processamento é feito na estação, e o servidor é um mero armazenador de informações; por exemplo, quando queremos saber o total de vendas do dia anterior, devemos trazer toda a tabela de vendas do servidor para a estação, totalizar as vendas e mostrar o resultado, o que aumenta muito o tráfego de rede.

Outro problema que ocorre com freqüência com ferramentas desktop, é a necessidade de reindexação. Como todo o processamento é feito no cliente, ao inserir alguma informação o índice é atualizado também no cliente. Caso a estação saia do ar, o DBF estará atualizado mas o índice não, obrigando a reindexação.

Além desses problemas, temos um não ligado diretamente à arquitetura do Clipper: a ausência do gerenciamento de transações. Quando a impressora trava no meio da nota fiscal, parando o sistema, como saber o que foi gravado e o que não foi ?

Cliente/servidor com o ADS" [...] continue lendo...