Migração MSDAORA para ORAOLEDB

Recentemente fui procurado pela diretoria de uma empresa para resolver-lhes um problema técnico que muito lhes afligia: Com o advento do Windows 2008 Server, a Microsoft parou de dar suporte OLEDB através do seu provedor de acesso, conhecido com MSDAORA (Microsoft 'Data Access Object' for Oracle). Este acesso existia desde os tempos do Windows NT. Evidentemente uma empresa tenta colocar a responsablidade na outra.

Dessa forma, sobrou para os seus clientes o ônus de resolver o problema. E não é um problema qualquer, pelo menos para o meu cliente (acesse o site). Vejam o seu cenário:

Sua aplicação, um Sistema de Cobrança de Inadimplência (Call Center especializado em cobrança), totalmente desenvolvido para web, usa as seguintes tecnologias:

Servidor de Web: Microsoft IIS
Páginas da Web: ASP Clássico
Banco de Dados: Oracle 10 em diante
Sistema Operacional: Windows até 2003 para servidor de web / qualquer Sistema Operacional que suporte Oracle para o servidor de banco de Dados.
Características arquiteturais:
1) 95% das regras de negócio escritas em PL/SQL (liguagem para criação de Stored Procedures da Oracle)
2) As páginas ASP só tocam o BD para fazer "SELECTS" e chamar Stored Procedures.
3) Nenhum UPDATE, DELETE ou INSERT é utilizado.
4) O controle das transações (Commit/Rollback) também é feito pelas Stored Procedures.

Minha primeira ação foi buscar na Internet ferramentas que me possiilitassem fazer a conversão automática. Achei algumas, mas todas falharam na conversão da chamada as Stored Procedures.

Nos passos iniciais, contei também com a ajuda do meu amigo Alexandre Nascimento, Gerente de Desenvolvimento de Sistemas da i-Hunter que me passou os primeiros exemplos de página invocando o "provider" da Oracle. Ao Alexandre e a i-Hunter meus sinceros agradecimentos.

Quantidade de Artefatos (programas ou páginas ASP):
ASA: 3
ASP: 848
INCLUDES: 490
JS: 31
Total: 1.372

Com a consciência do cenário acima, utilizei a seguinte abordagem:
A) Conversão manual de uma página que invoca Stored Procedures.
b) Conversão manual de uma página com comando SELECT.
C) Teste das páginas convertidas manualmente.
D) Medição do tempo investido nas atividades acima ("A", "B" e "C"). O tempo foi de 1h por artefato, o que projetou um custo de cerca noventa mil reais (R$ 90.000,00), três meses de trabalho utilizando três recursos.

Passando a fase seguinte, ainda fazendo a prova de conceito, tomei as seguintes ações:
E) Criação de um modelo de dados com apenas duas tabelas (ARQUIVO [id do Arquivo, Diretório ASP, Nome do Arquivo ASP e Extensão]e LINHA [id do Arquivo, Número da Linha Original, Conteúdo da linha Original, Número da Linha Convertida, Conteúdo da Linha Convertida]).
F) Programa de carga para levar os arquivos de código para as tabelas.
G) Três programas: Um para conversão dos SELECTs, um para conversão de STORED PROCEDURE e um para gravação do resultado.
H) Teste dos artefatos convertidos e refino dos programas acima.

Quando considerei que os programas estavam maduros, coloquei o processo para executar para todos os demais artefatos do sistema.

O processo fez a conversão de todos artefatos em apenas dois (2) minutos.
Observação:
B.1) Utilizei o PL/SQL para escrever os programas de carga e migração.
B.2) Foram utilizadas cento e sessenta (160) horas nessas atividades.

O resultado final foi o seguinte:

- Troca de um projeto:
   De 1.400 horas por um projetos de 160 horas.
   De R$ 90.000 por um projeto de R$ 10.400.

Isso tudo com a confiabililidade de um processo automatizado.

Caso você precise de mais detalhes, poste um comentário ou escreva para o meu e-mail.

---

Clique aqui e veja a postagem sobre a troca do comando SQL SELECT.