Em linhas gerais, a automação é o mecanismo que permite um
aplicativo (chamado cliente) acessar e manipular objetos e recursos de outro
aplicativo (chamado servidor). Via de regra, a automação é algo tecnicamente
complexo nos bastidores, pois pode envolver diversas interfaces entre cliente,
servidor e sistema operacional.
O Office é um dos mais importantes (se não o mais
importante) servidores de automação, pois além de oferecer recursos avançados (editor
de textos, planilha eletrônica/gráficos, apresentações, etc.) que complementam
vários tipos de soluções, conseguiu encapsular a complexidade da automação
tornando-a bastante simples ao desenvolvedor. Se compararmos o MS-Office a
outros pacotes concorrentes, a facilidade na programação agrega mais valor
ainda ao MS-Office, já que praticamente todos seus recursos estão disponíveis
programaticamente.
De todas as ferramentas do pacote Office, o Excel é a mais
usada como servidor de automação, especialmente por ser um produto muito
versátil (troca de dados, cálculos, gráficos, relatórios, etc.) e usado no
mercado em praticamente todos os ramos de atividade.
Abrir e fechar o aplicativo servidor
Embora a automação do Office seja fácil de se implementar, o
desenvolvedor necessita de uma atenção especial: ao abrir um aplicativo, deve
cuidar de fechá-lo.
De certa forma, a automação funciona como se um usuário
abrisse e manipulasse o aplicativo servidor. Se pegarmos o Excel como exemplo,
a automação funciona de maneira semelhante a um usuário que aciona a aplicação
Excel, abre uma pasta de trabalho, escolhe uma planilha, lê e preenche células.
Assim, um processo do Excel é iniciado no Windows e, quando o usuário fecha o
Excel, o processo é finalizado.
Nos cenários de automação, porém, é muito comum o aplicativo
servidor ser executado nos bastidores, de forma invisível ao usuário que, na
maioria das vezes, nem sabe que o Excel (ou seja lá qual aplicativo for) está
sendo executado. Se o usuário não tem a janela do Excel ativa para poder
fechar, quem deve fazer isto é a própria aplicação que o abriu, caso contrário
o processo ficará pendurado no Windows. Além de consumir memória, isto pode ter
um efeito mais nocivo: deixar a pasta de trabalho do usuário bloqueada de forma
que ele não consiga acessá-la nem abrindo o Excel manualmente, nem por outro
processo de automação.
Este erro é bastante comum nos fóruns de discussão: “[meu
arquivo] está bloqueado para edição”. O usuário diz que fechou todos os
programas (e de fato fechou), abriu seu arquivo do Excel e recebeu esta
mensagem de erro.
Ao abrirmos o Windows Task Manager na guia processos e
classificarmos por nome da imagem, encontramos repetidas vezes o “EXCEL.EXE”.
Finalizamos os processos e, momentaneamente, o problema está resolvido. Mais
tarde, porém, o problema volta a se repetir. Motivo: algum aplicativo que usa o
Excel como servidor de automação está falhando em fechá-lo. Geralmente ocorre
algum erro em tempo de execução no código depois que a aplicação foi
instanciada, deixando-a pendurada.
Como evitar o processo pendurado
Para evitar este cenário descrito acima, recomendo uma
destas duas práticas, por ordem de prioridade:
a)
Trazer a aplicação Excel para a tela do usuário:
se o objetivo da rotina de automação for preparar um arquivo e exibir o
resultado final ao usuário, nada mais óbvio que torná-lo visível, certo? Porém,
muitas vezes o desenvolvedor não faz isto: ele abre o Excel, executa as rotinas
de preenchimento, salva, fecha e, por fim, executa o comando Shell para abrir o
arquivo em uma nova instância do Excel.
O que recomendo, nestes casos, é
deixar visível a própria instância usada no preenchimento, e fazer isto logo no
início do código. Desta forma, se ocorrer algum erro durante a execução do
código, o processo não ficará perdido no Windows, pois o usuário terá domínio
da janela.
Sub MySub1()
Dim xlApp As Excel.Application
Dim xlWkb As Excel.Workbook
On Error GoTo ErrHandler
'Instancia o Excel
Set xlApp = New Excel.Application
'Deixa o Excel visível para
o usuário
xlApp.Visible = True
'Seu código aqui...
ExitHere:
Exit Sub
ErrHandler:
MsgBox Err.Description &
vbCrLf & Err.Number & vbCrLf & Err.Source, vbCritical,
"MySub"
Resume ExitHere
End Sub
b)
Controlar se a aplicação está instanciada e
fazer a finalização no tratamento de erro: é comum alguns desenvolvedores
colocarem um comando para finalizar (Quit) o Excel no tratamento de erro.
Porém, se o erro ocorrer por outro motivo que não a automação e o Excel não
tiver instanciado no momento, este tratamento vai gerar outro erro (“Object
variable or With block variable not set”):
Para que não ocorra este erro, o
mais correto é, antes de fazer o Quit, verificar se o Excel foi instanciado:
Sub MySub2()
Dim xlApp As
Excel.Application
Dim xlWkb As
Excel.Workbook
Dim blnIsOpen
As Boolean
On Error GoTo
ErrHandler
'Instancia o Excel
Set xlApp =
New Excel.Application
blnIsOpen =
True
'Seu código
aqui...
'Finaliza a aplicação
xlApp.Quit
blnIsOpen = False
ExitHere:
Exit Sub
ErrHandler:
'Verifica se o
Excel está instanciado
If blnIsOpen =
True Then
xlApp.Quit
End If
MsgBox
Err.Description & vbCrLf & Err.Number & vbCrLf & Err.Source,
vbCritical, "MySub"
Resume ExitHere
End Sub
Conclusão
Estas duas técnicas são bastante simples, mas ajudam a
evitar problemas muito comuns e recorrentes quando fazemos automação de
aplicativos, especialmente do Excel. Podem ser usadas a partir de qualquer
linguagem, seja VBA (como nos exemplos acima), seja VB6, VB.Net, C# ou outra
linguagem.
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.