Autor: admin

Notícias

Problemas de memória entre Access e SQL Server

maio 30, 2023 by admin

Ao utilizar o Access com SQL Server, alguns usuários relataram uso excessivo de memória

No final de 2022, surgiram relatos de um problema no Microsoft Access que afetava usuários que utilizavam o SQL Server como backend. Esse problema causava um aumento significativo no uso de memória, resultando em erros de falta de memória, especialmente durante a execução de consultas grandes ou complexas no lado do cliente. O problema foi detectado após a atualização do Office realizada em 6 de dezembro de 2022.

Os relatos vieram de várias pessoas em diferentes localidades. Segundo os usuários, tanto os arquivos accdb quanto accde apresentaram os mesmos problemas. O problema foi reportado nas seguintes versões do Office 365:

  • Versão 2211, Build 16.0.15831.20098 (32 bits)
  • Versão 2211, Build 16.0.15831.20208 (32 bits)

É importante destacar que, até o momento, a Microsoft ainda não confirmou oficialmente se isso é um bug específico do Access, do Windows ou até mesmo do SQL Server. No entanto, a gravidade do problema e os relatos consistentes levaram a equipe do Microsoft Access a investigar e solucionar essa questão o mais rápido possível.

A equipe anunciou em janeiro de 2023 que o bug foi corrigido na versão atual do Office 365. Os usuários afetados simplesmente precisam fechar e abrir o Access para que a correção entre em vigor. Além disso, a correção também foi incorporada à Versão 2212 do Canal Mensal, disponível a partir de 14 de fevereiro.

Se você estiver enfrentando esse problema ou tiver dúvidas adicionais, recomendamos que você visite o site de suporte da Microsoft, onde você encontrará informações detalhadas e poderá participar de discussões relacionadas a esse assunto.

Recomendamos sempre garantir que você esteja utilizando a versão mais recente do Office 365 para aproveitar todas as correções e melhorias disponíveis. Se você ainda não atualizou sua versão, recomendamos que você faça isso para evitar possíveis problemas no futuro. Você pode atualizar o Office 365 acessando este link.

O Microsoft Access continuará sendo uma excelente opção para o desenvolvimento de sistemas, trazendo produtividade, eficiência e resultado positivo para quem nos procura. Se quer saber mais como podemos melhorar a gestão da sua empresa ou departamento com o Access, entre em contato.

Sem categoria

Proteger ou não proteger o código VBA, eis a questão

set 26, 2020 by admin

Para quem não está familiarizado com o termo, gerar MDE (ou “compilar”) é um procedimento no qual o Access cria um arquivo (com extensão .mde ou .accde) e nele inclui os objetos de bancos de dados (tabelas, consultas, formulários, relatórios, macros e módulos), montando uma estrutura de bloqueio que impede o acesso e a modificação dos formulários, relatórios, macros e módulos. Este processo é muito utilizado pelos programadores Access para disponibilizar seus aplicativos para os clientes, pois é uma forma de impedir alterações não autorizadas (e evita uma série de problemas e suporte).

Há alguns anos atrás acompanhei uma discussão em um fórum de Access em que um dos colegas celebrava o início da prestação de serviço que prometia recuperar o código de uma aplicação MDE/ACCDE. Embora o serviço não tenha sido inovador na época (existem empresas fora do país que fazem o mesmo serviço há mais de 10 anos), gerou uma discussão pertinente e interessante. Alguns se posicionaram contra, alegando que isto abriria um precedente para que seus clientes viessem a procurar o serviço no intuito de obter o código fonte sem a devida autorização; outros se colocaram a favor, com o argumento de que isto ajudaria uma empresa que se tornou “refém” de um sistema que foi desenvolvido por um colaborador que não faz mais parte do quadro de funcionários e, por diversas razões, não disponibilizou a aplicação.

Particularmente, acredito que uma boa conversa e transparência na proposta, no contrato e sobretudo no serviço prestado resolvem este impasse sem criar rusgas entre cliente e fornecedor. É muito mais uma questão comercial do que técnica. Percebo que grande parte dos programadores Access se preocupam com a possibilidade de o cliente “trocá-lo” por outro programador (eu conheço programadores que realmente passaram por isso). Neste sentido, vale o início do parágrafo: boa conversa e transparência. 

Hoje com tantos códigos, frameworks, módulos e bibliotecas à disposição, vejo mais sentido em colaborar e compartilhar soluções do que seguir o contrário. Basta fazer uma pesquisa no Google e encontramos diversas ferramentas que auxiliam no desenvolvimento. Existem diversas ferramentas que prometem tanto proteger quanto recuperar o código compilado. No Brasil temos uma excelente solução de proteção construída por um grande amigo meu e que pode ser encontrada aqui.

Por aqui deixamos claro que em nossos projetos (o que consideramos entregue após a devida validação) as regras de negócio específicas são do cliente e proporcionamos liberdade para que faça alterações, desde que decorrido o tempo de garantia, evitando assim assumir uma responsabilidade sobre um problema decorrente de má manutenção ou algum erro causado por outro programador. E, neste caso, nos colocamos à disposição para dar suporte, como desenvolvimento adicional. 

Notícias

Access 2016 retorna com suporte a arquivos dBASE (.dbf)

set 26, 2020 by admin

Ao mesmo tempo em que o Access é visto por alguns como uma ferramenta “caseira”, “amadora”, para outros é uma excelente opção para tratamento de dados. Não há dúvidas de que o Access se manteve até hoje no mercado dada a facilidade de se conectar com diversos bancos e a praticidade de seus assistentes de importação e geração de relatórios.

Acredito que o maior receio dos programadores Access é que a Microsoft resolva descontinuar a ferramenta, ou até mesmo removê-la do pacote Office. Este receio se agravou quando a empresa anunciou o Office 365 sem o Access. Com o anúncio da atualização no blog, vejo muitos programadores respirarem aliviados.

O dBASE foi o primeiro banco de dados estruturado, criado nos anos 90 e utilizado nos computadores Apple e no PC, rodando no DOS. Com a chegada de outros bancos como FoxPro, Clipper e o próprio Access, e dada a sua dificuldade de operação dentro do ambiente Windows, este formato acabou ficando em desuso. Atualmente, sistemas de informação geográficas utilizam o formato .dbf para guardar os dados geoespaciais, devido à sua boa estrutura.

Ter o suporte aos arquivos .dbf no Access possibilita importar dados oriundos de sistemas legados e também dos próprios SIG’s. Com isso, o Access se torna uma opção viável para importação e tratamento destes dados.

Esta foi a resposta da Microsoft à manifestação dos usuários por meio do site UserVoice, que mantém uma página dedicada às solicitações relacionadas ao Access. Para nós que utilizamos o Access, é um sinal positivo, indicando que a empresa está atenta às necessidades dos usuários e está trabalhando para melhorar a ferramenta, tirando assim o receio de que o Access será “abandonado”.

Dicas

Resolvendo problemas com datas no SQL Server

set 26, 2020 by admin

Um dos grandes problemas que surgem quando migramos uma base de dados Access para SQL Server é relacionado às datas. Isto por que o Access gerencia as datas de uma forma diferente do SQL Server, mesmo sendo ambos os softwares do mesmo fabricante, a Microsoft.

O Access, com o motor Jet/AceDAO, geralmente utiliza como referência de formato de data a máquina onde está instalado – em máquinas com Windows em inglês, por exemplo, as datas são formatadas como mês/dia/ano. Isto costuma gerar muita confusão, principalmente em ambientes onde o Windows está em português e o Office em inglês ou vice-versa. Já o SQL Server trata, por definição, as datas como ano/mês/dia.

Com isto, há o risco de as datas serem interpretadas erroneamente, por exemplo 03/02 (fevereiro) ser interpretado como março, ou vice-versa. Para fins de busca, é um elemento muito complicador, pois pode gerar um indicador errado e tornar o sistema não confiável. E isto, por consequência, pode impactar na relação entre o cliente e o desenvolvedor.

Ao longo dos anos enfrentamos este problema em diversas vezes, e por isso adotamos uma solução que compartilho neste artigo. Adotamos uma padronização nas datas, formatando todas como ano/mês/dia, sendo o ano com 4 dígitos e ps demais com 2. Ao ler a informação no banco de dados, adotamos a formatação visual de acordo com o idioma do sistema, e ao registrar as informações, revertemos a formatação. À primeira vista isto pode soar confuso, mas é uma solução viável e que resolve, em definitivo, o problema com a exibição e tratamento das datas.

Dou um exemplo: imagine uma tela onde você tenha um filtro de período, o usuário digita 01/02/2011 (1º de fevereiro de 2011) como início e 12/02/2011 como término. Ao solicitar a listagem (com base nos filtros), fazemos a conversão das datas para, respectivamente, 2011-02-01 e 2011-02-12 e enviamos o comando SQL para o servidor processar a informação. Ao retornar a informação na lista, revertemos o formato e exibimos 01/02/2011 e 12/02/2011. Com isso, não há como ocorrer falha na interpretação das datas, pois o formato informado é o padrão adotado pelo SQL Server.

Para uma maior eficiência na codificação, você pode transformar este processo em uma função independente, recebendo uma data e transformando-a em texto para o SQL.

Public Sub FormatarData(dtReferencia as Date) as String
    FormatarData = "'" & Format(dtReferencia,"yyyy-mm-dd") & "'"
End Sub

Dicas

Resolvendo problemas de resolução nos formulários

set 26, 2020 by admin

A partir da versão 2007, a Microsoft disponibilizou um comando muito útil e que nos ajudou em nosso desenvolvimento: o comando “Ancoragem”. Com esse recurso, resolvemos o problema com as diferentes resoluções.

Um dos problemas mais comuns quando desenhamos as telas dos sistemas em Access é dimensionar os campos e controles da tela de forma que fiquem visíveis em todos os tipos de monitores.

Na maioria das vezes, as telas são desenvolvidas tendo como base uma única resolução (geralmente 1024×768 pixels). A vantagem é que temos aí uma referência para o layout que serve para todas as telas da aplicação. O problema é que em resoluções menores as telas acabam ficando distorcidas ou alguns objetos acabam ficando ocultos. A saber, por padrão, todos os controles e objetos que são colocados em um formulário (bem como o próprio) é alinhado à esquerda e ao topo da tela. Isto significa que se uma tela preenche completamente uma resolução de 800×600 pixels, em um monitor com resolução maior o Access exibe a tela com um espaço vazio nas extremidades inferior e direita.

Até a versão 2003 este era um grande desafio para nós. Para contornar, desenvolvemos uma série de funções que desenhavam os controles a partir da resolução do monitor utilizado. Apesar de atender à necessidade, este redimensionamento acabava impactando na performance da aplicação, e em alguns casos havia travamento.

Porém, a partir da versão 2007, a Microsoft disponibilizou um comando muito útil e que nos ajudou em nosso desenvolvimento: o comando “Ancoragem”.

Ancoragem? 

Ancoragem (Access 2013)

Este comando permite criar um efeito “responsivo” em um controle no formulário. Com isso, é possível desenvolver a tela sem se preocupar com a resolução do monitor do cliente.

Tela desenvolvida sem Ancoragem, no formato Access até 2003. Veja que os controles estão alinhados à esquerda e ao topo.
A mesma tela com Ancoragem. Veja que os controles estão bem distribuídos na tela.

Tipos de ancoragem

Existem 9 tipos de ancoragem:

  • Superior esquerdo: alinha o controle à esquerda e ao topo da tela (esta é a opção padrão de todos os objetos do Access).
  • Alongar para cima: “estica” o controle na horizontal, alinhado ao topo da tela.
  • Superior direito: alinha o controle à direita e ao topo da tela
  • Alongar para baixo: “estica” o controle na vertical, alinhado à esquerda
  • Alongar para baixo de um lado a outro: “estica” o controle ocupando as laterais da tela
  • Alongar para baixo e para a direita: “estica” o controle tanto na vertical quando na horizontal, ocupando o espaço disponível
  • Inferior esquerdo: alinha o controle à esquerda e no rodapé da tela
  • Alongar para baixo: “estica” o controle na horizontal, alinhado ao rodapé da tela
  • Inferior direito: alinha o controle à direita e ao rodapé da tela

Abaixo, um exemplo de como podemos aplicar a ancoragem em nossos formulários.

Exemplo de tela em tamanho normal – a ancoragem não é percebida
A mesma tela maximizada – veja que a ancoragem ainda não está ativada
Tela redimensionada e ancoragem ativada em todos os controles, cada um com seu tipo

A ancoragem é um recurso muito útil, porém deve ser usado com atenção, pois os controles podem “atropelar” uns aos outros, dependendo de como for configurado.

A tela acima com erro – veja que um campo está “atropelando” o outro.

Conclusão

A ancoragem, se bem utilizada, pode ajudar muito no desenvolvimento das aplicações. Este recurso irá dar um toque “moderno” nas suas aplicações e com isso se tornar um diferencial em seus projetos.

A dica aqui é criar um esboço da tela e definir antes quais campos serão “esticados” e como isto será configurado. Feito isso, é só criar seus formulários.

Bom desenvolvimento!