Recursos do Access removidos na versão 2010

Sempre quando sai uma versão atualizada de algum produto, vemos muitos artigos sobre as novas funcionalidades, mas quase sempre passa despercebido algo igualmente importante: os recursos que ficaram para trás.

Este artigo tem por objetivo justamente isto: listar os recursos do Access que não estarão mais disponíveis na versão 2010. Mesmo que você hoje desenvolva com versões anteriores do Access e não esteja planejando migrar tão cedo para o 2010, vale a pena ter conhecimento dos recursos com os quais não poderá contar no futuro e assim planejar melhor a arquitetura dos novos aplicativos que venha a construir.

Formato Snapshot

O formato Snapshot (*.snp) é bastante usado por desenvolvedores, especialmente em aplicações corporativas, para salvar relatórios. O visualizador deste formato é o Snapshot Viewer, que vinha na instalação do Office e também fica disponível para download gratuito no site da Microsoft (http://support.microsoft.com/kb/175274/pt-br).

Era (na verdade, ainda é) um bom utilitário, com ótima visualização e navegação de páginas. Porém, a partir do Access 2007 SP2, o Snapshot passou a “concorrer” com o formato PDF, que é muito mais difundido e utilizado, então o Snapshot perdeu um pouco o sentido.

Controle calendário (Calendar control – mscal.ocx)

O controle calendário foi o ActiveX mais usado com o Access durante um bom tempo, mais até que o Treeview control. Não que fosse uma grande maravilha – pois não é -, mas o fato de estar ali disponível pela própria instalação do Access levou muitos desenvolvedores a utilizá-lo em suas aplicações.

O visual do controle é ok, além de ser fácil de programar e utilizar, porém muita gente – sem saber - acabava tendo problema na distribuição, pois é um controle ActiveX, não é nativo do Access, além de ter diferentes versões de acordo com o idioma do Access.

Particularmente, não deixa saudades. O Access 2007 já traz o date-time picker (que é uma espécie de combobox em que o drop-down é um calendário suspenso) nativo, e mesmo para quem desenvolve para versões anteriores, há boas alternativas de calendários desenvolvidos dentro do próprio Access, com formulários e controles nativos, mais funcionais e sem nenhum problema de distribuição. Aqui há alguns links: http://www.accessmvp.com/JConrad/accessjunkie/calendars.html

Página de acesso a dados (Data Access Pages - DAPs)

Outro recurso que não deve fazer falta (não por ser ruim, mas por ser pouco usado) são as páginas de acesso a dados (DAPs). Esta foi a primeira tentativa de levar front-ends do Access para a web, porém não foi bem sucedida. Disponível a partir do Access 2000, a tecnologia era baseada em ASP, ADO e DHTML. O desenvolvedor, por meio de um simples assistente, gerava um formulário (semelhante a um formulário Access), que na verdade era uma página ASP que acessava o banco de dados (DHTML fazendo data binding com ADO).

Considerando que a primeira bolha da internet estava sendo inflada naquela época, todas as empresas demandavam sites dinâmicos (com acesso a dados) e os desenvolvedores focavam na web, era de se esperar que as DAPs fizessem mais sucesso, afinal representavam uma forma fácil e rápida de colocar uma página no ar. Porém, ficou só na expectativa mesmo, não sei ao certo por quê. Provavelmente por uma combinação de fatores: o visual das DAPs era de formulários enlatados; a customização era difícil; as DAPs tinham o estigma de “sites de mentira”; o desenvolvedor acabaria tendo que escrever muito código ASP para atender os requisitos do cliente, então as DAPs representavam pouco ganho de produtividade dentro do escopo todo do projeto.

 Provavelmente muitos vão dizer que o desenvolvimento para Access Services – os bancos de dados web (ou web databases) do Access 2010 – é o substituto das DAPs. Embora os web databases, mesmo em sua versão inicial, sejam muito melhores e mais completos do que as DAPs jamais foram, não podem ser considerados substitutos. Os web databases são publicados apenas em sites SharePoint 2010 com Access Services (portanto, na versão paga do SharePoint), enquanto as DAPs podiam ser jogadas em qualquer servidor com IIS.

O Access 2010 ainda consegue armazenar as DAPs no arquivo e convertê-las para versões anteriores do Access, porém não permite editar nem executar. O Access 2007 também não permitia editar a estrutura, mas executar era possível.

Visualizador de conflitos de replicação

Como desde a versão 2007 o suporte a replicação de dados foi deixado de lado, nada mais natural que parar de suportar o visualizador de conflitos. Embora eu poucas vezes tenha usado os mecanismos de replicação nativos do Access, gostava muito deles. Era um recurso muito profissional disponível num banco de dados considerado de amadores (assim como a segurança em nível de usuário, que também foi descontinuada). Como eu tinha 0,5% de esperança de ver estes recursos de volta no Access, fiquei triste por ter agora 0,0%.

Quanto ao visualizador de conflitos em si, é possível criar uma versão customizada, já que tudo é baseado em objetos programáveis. Anos atrás escrevi sobre isto na revista FórumAccess, quem tiver interesse pode dar uma olhada nas edições 63 e 64, ou aqui tem o eletrônico do primeiro deles: http://linhadecodigo.com.br/Artigo.aspx?id=1220

Conexão com Paradox (3 a 7), Lotus 1-2-3 e Access 1.0 e 2.0

Dos recursos que estão ficando para trás, este item é o que mais me preocupa. Não que seja comum encontrar aplicativos que precisem permanentemente destes conectores específicos, mas sempre foi da essência do Access a facilidade de conexão com diversos bancos de dados. Isto tem se perdido ao longo das versões. Se compararmos o Access 97 com o 2010, por exemplo, veremos que o 97 se conectava com qualquer coisa, e o 2010 apenas com alguns gatos pingados. Seguindo este caminho, daqui poucos anos o Access só falará com Access, SQL Server e SharePoint.

O que perdemos com isto? Estes são os principais pontos:

a)      O Access é a melhor ferramenta de migração de dados que conheço. Posso (ou podia) vincular qualquer origem, qualquer destino e rodar consultas de acréscimo para carregar dados, consultas de atualização para manutenção de dados e consultas de exclusão para limpar bases. E é comum os desenvolvedores precisarem fazer manutenções ou migrações em bases antigas.

b)      Quando precisamos criar um sistema que consome dados de uma base antiga, ou nem tão antiga, se o Access não tem os conectores, ficamos praticamente sem alternativa de como atender o requisito. Recentemente, por exemplo, precisei criar um sistema que consumia dados de planilhas Lotus 1-2-3 enviadas diariamente, e com o Access e o Excel não é mais possível. Quem vai acabar ocupando este espaço é o OpenOffice.

Conclusão

Tão importante quanto conhecer os novos recursos do Access 2010 (para explorá-los melhor) é saber o que está parando de funcionar, e assim avaliar e criar alternativas. Muitas vezes surgem oportunidades de mercado em cima de recursos removidos.