Migrar uma base de dados do Access para o SQL Server

Migrar uma base de dados do Access para o SQL Server

Todos temos limites, e uma base de dados de acesso não é exceção. Por exemplo, uma base de dados de Acesso tem um limite de tamanho de 2 GB e não pode suportar mais de 255 utilizadores simultâneos. Por isso, quando for a altura da base de dados de Acesso passar para o próximo nível, pode migrar para o SQL Server. O SQL Server (seja no local ou na nuvem Azure) suporta quantidades maiores de dados, utilizadores mais simultâneos e tem maior capacidade do que o motor de base de dados JET/ACE. Este guia dá-lhe um início suave da sua jornada do SQL Server, ajuda a preservar as soluções frontais de acesso que criou e, com sorte, motiva-o a utilizar o Access para futuras soluções de base de dados. O Assistente de Upsizing foi removido do Access in Access 2013, pelo que agora pode utilizar o Microsoft SQL Server Migration Assistant (SSMA). Para migrar com sucesso, siga estas etapas.

As fases da migração da base de dados para o SQL Server

Antes de começar

As secções seguintes fornecem informações e antecedentes e outras informações para ajudá-lo a começar.

Sobre bases de dados divididas

Todos os objetos da base de dados do Access podem estar num ficheiro de base de dados ou podem ser armazenados em dois ficheiros de base de dados: uma base de dados frontal e uma base de dados traseira. Isto chama-se dividir a base de dados e destina-se a facilitar a partilha num ambiente de rede. O ficheiro de base de dados back-end deve conter apenas tabelas e relacionamentos. O ficheiro frontal deve conter apenas todos os outros objetos, incluindo formulários, relatórios, consultas, macros, módulos VBA e tabelas ligadas à base de dados back-end. Quando migra uma base de dados de Acesso, é semelhante a uma base de dados dividida em que o SQL Server está a agir como um novo back-end para os dados que estão agora localizados num servidor.

Como resultado, ainda pode manter a base de dados de acesso frontal com tabelas ligadas às tabelas SQL Server. Efetivamente, pode derivar os benefícios de um rápido desenvolvimento de aplicações que uma base de dados de Acesso fornece, juntamente com a escalabilidade do SQL Server.

Benefícios do Servidor SQL

Ainda precisa de convencer a migrar para o SQL Server? Aqui ficam alguns benefícios adicionais para pensar:

  • Utilizadores mais simultâneos    O SQL Server pode lidar com muitos utilizadores mais simultâneos do que o Access e minimiza os requisitos de memória quando mais utilizadores são adicionados.

  • Aumento da disponibilidade    Com o SQL Server, pode fazer backup dinâmico, incremental ou completo, na base de dados enquanto estiver em uso. Consequentemente, não tem de forçar os utilizadores a saírem da base de dados para criar uma cópia de segurança dos dados.

  • Alto desempenho e escalabilidade    A base de dados do SQL Server geralmente funciona melhor do que uma base de dados de Acesso, especialmente com uma grande base de dados de tamanho terabyte. Além disso, o SQL Server processa consultas muito mais rápidas e eficientes através do processamento de consultas em paralelo, utilizando múltiplos fios nativos dentro de um único processo para lidar com os pedidos do utilizador.

  • Segurança melhorada    Utilizando uma ligação fidedigna, o SQL Server integra-se com a segurança do sistema Windows para fornecer um único acesso integrado à rede e à base de dados, utilizando o melhor de ambos os sistemas de segurança. Isto torna muito mais fácil a gestão de sistemas de segurança complexos. O SQL Server é o armazenamento ideal para informações sensíveis, tais como números de Segurança Social, dados de cartões de crédito e endereços confidenciais.

  • Recuperabilidade imediata    Se o sistema operativo falhar ou a energia se desligar, o SQL Server pode automaticamente recuperar a base de dados para um estado consistente numa questão de minutos e sem intervenção do administrador da base de dados.

  • Utilização de VPN    As Redes Privadas Virtuais e de Acesso (VPN) não se dão bem. Mas com o SQL Server, os utilizadores remotos podem ainda utilizar a base de dados frontal do Access num ambiente de trabalho e o back-end do SQL Server localizado atrás da firewall VPN.

  • Servidor Azure SQL    Além dos benefícios do SQL Server, oferece escalabilidade dinâmica sem tempo de inatividade, otimização inteligente, escalabilidade e disponibilidade globais, eliminação de custos de hardware e administração reduzida.

Escolha a melhor opção Azure SQL Server

Se estiver a migrar para o Azure SQL Server, existem três opções à escolha, cada uma com diferentes benefícios:

  • Base de dados única/piscinas elásticas    Esta opção tem o seu próprio conjunto de recursos geridos através de um servidor SQL Database. Uma única base de dados é como uma base de dados contida no SQL Server. Também pode adicionar uma piscina elástica, que é uma coleção de bases de dados com um conjunto partilhado de recursos geridos através do servidor SQL Database. As funcionalidades do SQL Server mais utilizadas estão disponíveis com cópias de segurança incorporadas, remendos e recuperação. Mas não há tempo de manutenção e migração garantida do SQL Server pode ser difícil.

  • Caso gerido    Esta opção é uma recolha de bases de dados de sistemas e utilizadores com um conjunto partilhado de recursos. Um caso gerido é como um exemplo da base de dados do SQL Server que é altamente compatibilidade com o SQL Server no local. Um caso gerido tem backups incorporados, patching, recuperação, e é fácil de migrar do SQL Server. No entanto, existem um pequeno número de funcionalidades do SQL Server que não estão disponíveis e não têm um tempo de manutenção garantido.

  • Máquina Virtual do Azure    Esta opção permite-lhe executar o SQL Server dentro de uma máquina virtual na nuvem Azure. Tem controlo total sobre o motor SQL Server e uma via de migração fácil. Mas tens de gerir os teus backups, remendos e recuperação.

Para obter mais informações, consulte escolher o caminho de migração da sua base de dados para Azure e escolha a opção sql server certa em Azure.

Primeiros passos

Existem algumas questões que pode resolver à frente que podem ajudar a agilizar o processo de migração antes de executar sSMA:

  • Adicione índices de tabela e chaves primárias    Certifique-se de que cada tabela de Acesso tem um índice e uma chave primária. O SQL Server exige que todas as tabelas tenham pelo menos um índice e requer que uma tabela ligada tenha uma chave primária se a tabela puder ser atualizada.

  • Verifique as relações principais/estrangeiras    Certifique-se de que estas relações são baseadas em campos com tipos e tamanhos de dados consistentes. O SQL Server não suporta colunas unidas com diferentes tipos e tamanhos de dados em restrições de chaves estrangeiras.

  • Remover a coluna anexo    SSMA não migra tabelas que contenham a coluna attachment.

Antes de executar sSMA, dê os seguintes primeiros passos.

  1. Feche a base de dados de acesso.

  2. Certifique-se de que os utilizadores atuais ligados à base de dados também fecham a base de dados.

  3. Se a base de dados estiver no formato de ficheiro .mdb,remova a segurança ao nível do utilizador.

  4. Ressi para a sua base de dados. Para obter mais informações, consulte Protect your data with backup and restore processes.

Sugestão    Considere instalar a edição do Microsoft SQL Server Express no seu ambiente de trabalho, que suporta até 10 GB e é uma forma gratuita e fácil de passar e verificar a sua migração. Quando ligar, utilize o LocalDB como a instância da base de dados.

Sugestão    Se possível, utilize uma versão autónoma do Access. Se só puder utilizar Microsoft 365, utilize o motor de base de dados Access 2010 para migrar a sua base de dados De acesso quando utilizar o SSMA. Para obter mais informações, consulte o Microsoft Access Database Engine 2010 Redistributable.

Executar SSMA

A Microsoft fornece o Microsoft SQL Server Migration Assistant (SSMA) para facilitar a migração. O SSMA migra principalmente tabelas e seleciona consultas sem parâmetros. Formulários, relatórios, macros e módulos VBA não são convertidos. O SQL Server Metadata Explorer exibe os seus objetos de base de dados de acesso e objetos SQL Server permitindo-lhe rever o conteúdo atual de ambas as bases de dados. Estas duas ligações são guardadas no seu ficheiro de migração caso decida transferir objetos adicionais no futuro.

Nota    O processo de migração pode demorar algum tempo dependendo do tamanho dos objetos da sua base de dados e da quantidade de dados que devem ser transferidos.

  1. Para migrar uma base de dados utilizando o SSMA, primeiro descarregue e instale o software clicando duas vezes no ficheiro MSI descarregado. Certifique-se de que instala a versão adequada de 32 ou 64 bits para o seu computador.

  2. Depois de instalar o SSMA, abra-o no seu ambiente de trabalho, de preferência a partir do computador com o ficheiro de base de dados Access.

    Também pode abri-lo numa máquina que tenha acesso à base de dados Access a partir da rede numa pasta partilhada.

  3. Siga as instruções iniciais no SSMA para fornecer informações básicas, como a localização do SQL Server, a base de dados access e objetos para migrar, informações de ligação e se pretende criar tabelas ligadas.

  4. Se estiver a migrar para o SQL Server 2016 ou mais tarde e quiser atualizar uma tabela ligada, adicione uma coluna de remar, selecionando Ferramentas de Revisão > Definições de Projeto > Geral.

    O campo de remar ajuda a evitar conflitos recorde. O acesso utiliza este campo de versão de linha numa tabela ligada ao SQL Server para determinar quando o registo foi atualizado pela última vez. Além disso, se adicionar o campo de remações a uma consulta, o Access utiliza-o para reescor o reescorção da linha após uma operação de atualização. Isto melhora a eficiência ajudando a evitar escrever erros de conflito e cenários de eliminação de registos que podem ocorrer quando o Access deteta diferentes resultados da submissão original, tais como pode ocorrer com tipos de dados de números de ponto flutuante e gatilhos que modificam colunas. No entanto, evite utilizar o campo de remar em formas, relatórios ou código VBA. Para mais informações, consulte a náduse.

    Nota    Evite confundir aversão à linha com os tempos. Embora o tempo de palavra-chave seja um sinónimo de versão de linha no SQL Server, não é possível utilizar a versão de linha como forma de marcar um tempo de entrada de dados.

  5. Para definir tipos precisos de dados, selecione Ferramentas de revisão > Definições de Projeto > mapeamento do tipo. Por exemplo, se armazenar apenas texto em inglês, pode utilizar o varchar em vez do tipo de dados nvarchar.

Converter objetos

O SSMA converte os objetos de acesso a objetos do SQL Server, mas não copia os objetos imediatamente. O SSMA fornece uma lista dos seguintes objetos para migrar para que possa decidir se pretende movê-los para a base de dados do SQL Server:

  • Tabelas e Colunas

  • Selecione consultas sem parâmetros.

  • Chaves primárias e estrangeiras

  • Índices e Valores Predefinidos

  • Verificar restrições (permitir propriedade de coluna de comprimento zero, regra de validação de colunas, validação de tabela)

Como boas práticas, utilize o relatório de avaliação do SSMA, que mostra os resultados da conversão, incluindo erros, avisos, mensagens informativas, estimativas de tempo para a realização da migração e medidas individuais de correção de erros a tomar antes de mover os objetos.

A conversão de objetos de base de dados retira as definições de objetos dos metadados de acesso, converte-as em sintaxe Transact-SQL (T-SQL)equivalente, e depois carrega esta informação no projeto. Em seguida, pode ver os objetos SQL Server ou SQL Azure e as suas propriedades utilizando o SQL Server ou o SQL Azure Metadata Explorer.

Para converter, carregar e migrar objetos para o SQL Server, siga este guia.

Sugestão    Depois de migrar com sucesso a sua base de dados Access, guarde o ficheiro do projeto para utilização posterior, para que possa migrar os seus dados novamente para testes ou migração final.

Tabelas de ligação

Considere instalar a versão mais recente dos controladores SQL Server OLE DB e ODBC em vez de utilizar os controladores nativos do SQL Server que enviam com o Windows. Não só os condutores mais novos são mais rápidos, como suportam novas funcionalidades no Azure SQL que os anteriores condutores não têm. Pode instalar os controladores em cada computador onde a base de dados convertida é utilizada. Para obter mais informações, consulte o Microsoft OLE DB Driver 18 para SQL Server e Microsoft ODBC Driver 17 para SQL Server.

Depois de migrar as tabelas Access, pode ligar-se às tabelas do SQL Server que agora acolhe os seus dados. A ligação direta do Access também lhe proporciona uma forma mais simples de visualizar os seus dados em vez de utilizar as ferramentas de gestão do SQL Server mais complexas.  Pode consultar e editar dados ligados dependendo das permissões configurados pelo administrador de base de dados do SEU SQL Server.

Nota    Se criar um DSN ODBC quando ligar à base de dados do SQL Server durante o processo de ligação, ou cria o mesmo DSN em todas as máquinas que utilizam a nova aplicação ou utilizam programáticamente a cadeia de ligação armazenada no ficheiro DSN.

Para obter mais informações, consulte Link para ou importar dados de uma Base de Dados e Importação de ServidorES Azure SQLou ligue-se a dados numa base de dados do SQL Server.

Sugestão   Não se esqueça de utilizar o Gestor de Tabelas Ligado no Acesso para refrescar e reencaminhar convenientemente as tabelas. Para obter mais informações, consulte Gerir tabelas ligadas.

Teste e revisão

As secções seguintes descrevem questões comuns que pode encontrar durante a migração e como lidar com elas.

Consultas

Apenas as consultas selecionadas são convertidas; outras consultas não são, incluindo Consultas Selecionadas que tomam parâmetros. Algumas consultas podem não se converter completamente, e sSMA reporta erros de consulta durante o processo de conversão. Pode editar manualmente objetos que não se convertam utilizando sintaxe T-SQL. Os erros de sintaxe também podem exigir a conversão manual de funções e tipos de dados específicos do Access para os do SQL Server. Para obter mais informações, consulte comparar o SQL de acesso com o SQL Server TSQL.

Tipos de dados

O Access e o SQL Server têm tipos de dados semelhantes, mas esteja atento aos seguintes problemas potenciais.

Número Grande    O tipo de dados de grande número armazena um valor numérico não monetário e é compatível com o tipo de dados de bigint SQL. Pode utilizar este tipo de dados para calcular de forma eficiente números grandes, mas requer a utilização do formato de ficheiro de base de dados Access 16 (16.0.7812 ou posterior) .accdb database file e executa melhor com a versão de 64 bits do Access. Para obter mais informações, consulte utilizar o tipo de dados de grande número e escolher entre a versão de 64 ou 32 bits do Office.

Sim/Não    Por predefinição, uma coluna Access Yes/No é convertida num campo bit sql Server. Para evitar o bloqueio de registos, certifique-se de que o campo de bits está definido para não permitir valores NU. IN SSMA, pode selecionar a coluna bit para definir a propriedade Permitir Nulos para NO. Na TSQL, utilize as declarações DE TABELA CREATE ou ALTER.

Data e Hora    Existem várias considerações de data e hora:

  • Se o nível de compatibilidade da base de dados for de 130 (SQL Server 2016) ou superior, e uma tabela ligada contiver uma ou mais colunas de data ou data 2, a tabela pode devolver a mensagem #deleted nos resultados. Para obter mais informações, consulte a tabela ligada ao Access à base de dados SQL-Server #deleted.

  • Utilize o tipo de dados data/hora de acesso para mapear o tipo de dados da data. Utilize o tipo de dados de data/hora de acesso para mapear o tipo de dados da data 2 que tem uma data e intervalo de tempo maiores. Para obter mais informações, consulte utilizando o tipo de dados data/hora estendido.

  • Ao consultar datas no SQL Server, tome em consideração a hora e a data. Por exemplo:

    • DataS Ordenado entre 1/1/1/19 e 1/31/19 pode não incluir todas as encomendas.

    • Data Ordenado Entre 1/1/1/19 00:00:00 AM E 1/31/19 11:59:59 PM inclui todas as encomendas.

Anexo   O tipo de dados anexo armazena um ficheiro na base de dados Access. No SQL Server, tem várias opções a considerar. Pode extrair os ficheiros da base de dados Access e, em seguida, considerar armazenar links para os ficheiros na base de dados do SEU SQL Server. Em alternativa, pode utilizar filestream, FileTables ou loja BloB Remoto (RBS) para manter os anexos armazenados na base de dados do SQL Server.

Hiperligação    As tabelas de acesso têm colunas de hiperligação que o SQL Server não suporta. Por predefinição, estas colunas serão convertidas em colunas nvarchar (máx) no SQL Server, mas pode personalizar o mapeamento para escolher um tipo de dado menor. Na sua solução Access, ainda pode utilizar o comportamento de hiperligação em formulários e relatórios se definir a propriedade Hyperlink para o controlo verdadeiro.

Campo multivalorizado    O campo multivalorizado Access é convertido para SQL Server como um campo ntext que contém o conjunto de valores delimitado. Como o SQL Server não suporta um tipo de dados de valores múltiplos que serve como modelo de uma relação muitos para muitos, poderão ser necessárias estruturas e conversões adicionais.

Para obter mais informações sobre os tipos de dados do Access e do SQL Server, consulte os tipos de dados do Compare.

Nota    Os campos multivalorizado não são convertidos e foram descontinuados no Access 2010.

Para obter mais informações, consulte os tipos de data e hora,tipos de cordas e binários,e tipos numéricos.

Visual Basic

Embora o VBA não seja suportado pelo SQL Server, note os seguintes problemas possíveis:

Funções VBA em Consultas    As consultas de acesso suportam funções VBA em dados numa coluna de consulta. Mas as consultas de acesso que utilizam funções VBA não podem ser executadas no SQL Server, pelo que todos os dados solicitados são transmitidos ao Microsoft Access para processamento. Na maioria dos casos, estas consultas devem ser convertidas em consultas de passagem.

Funções definidas pelo utilizador em consultas    As consultas do Microsoft Access suportam o uso de funções definidas em módulos VBA para processar dados que lhes são transmitidos. As consultas podem ser consultas autónomas, declarações SQL em fontes de registo de formulário/relatório, fontes de dados de caixas de combo e caixas de lista em formulários, relatórios e campos de mesa, e expressões de regras de padrão ou validação. O SQL Server não pode executar estas funções definidas pelo utilizador. Pode ser necessário redesenhar manualmente estas funções e convertê-las em procedimentos armazenados no SQL Server.

Otimizar o desempenho

De longe, a forma mais importante de otimizar o desempenho com o seu novo SQL Server é decidir quando utilizar consultas locais ou remotas. Quando migra os seus dados para o SQL Server, também está a mover-se de um servidor de ficheiros para um modelo de base de dados de computação do servidor cliente. Siga estas orientações gerais:

  • Faça pequenas consultas só de leitura sobre o cliente para obter o acesso mais rápido.

  • Executar consultas longas, ler/escrever no servidor para tirar partido do maior poder de processamento.

  • Minimize o tráfego de rede com filtros e agregação para transferir apenas os dados necessários.

Otimizar o desempenho no modelo de base de dados do servidor cliente

Para obter mais informações, consulte Criar uma consulta de passagem.

As seguintes orientações são adicionais e recomendadas.

Coloque lógica no servidor    A sua aplicação também pode usar pontos de vista, funções definidas pelo utilizador, procedimentos armazenados, campos calculados e gatilhos para centralizar e partilhar lógica de aplicação, regras e políticas de negócios, consultas complexas, validação de dados e código de integridade referencial no servidor, em vez de no cliente. Pergunte a si mesmo, esta consulta ou tarefa pode ser realizada no servidor melhor e mais rápido? Finalmente, teste cada consulta para garantir um desempenho ideal.

Use pontos de vista em formulários e relatórios    No Acesso, faça o seguinte:

  • Para formulários, utilize uma vista SQL para um formulário apenas de leitura e uma vista indexada SQL para um formulário de leitura/escrita como fonte de registo.

  • Para relatórios, utilize uma vista SQL como fonte de registo. No entanto, crie uma visão separada para cada relatório, para que possa atualizar mais facilmente um relatório específico, sem afetar outros relatórios.

Minimizar os dados de carregamento de forma ou relatório    Não apresente os dados até que o utilizador o peça. Por exemplo, mantenha a propriedade de recordsource em branco, faça com que os utilizadores selecionem um filtro no seu formulário e, em seguida, povoem a propriedade de recursos de gravação com o seu filtro. Ou, utilize a cláusula de onde doCmd.OpenForm e DoCmd.OpenReport para exibir os registos exatos necessários pelo utilizador. Considere desligar a navegação de registos.

Tenha cuidado com consultas heterogéneas   Evite executar uma consulta que combine uma tabela local de acesso e uma tabela ligada ao SQL Server, por vezes chamada de consulta híbrida. Este tipo de consulta ainda requer acesso para transferir todos os dados do SQL Server para a máquina local e, em seguida, executar a consulta, não executou a consulta no SQL Server.

Quando usar mesas locais    Considere usar tabelas locais para dados que raramente mudam, como a lista de estados ou províncias de um país ou região. As tabelas estáticas são frequentemente utilizadas para filtrar e podem ter um melhor desempenho na frente do Access.

Para obter mais informações, consulte o Base de Dados De Afinação do Motor,Utilize o Analisador de Desempenho para otimizar uma base de dados de acessoe otimizar as aplicações de acesso do Microsoft Office Ligadas ao SQL Server.

Consulte Também

Guia de migração da base de dados Azure

Blog de migração de dados

Acesso ao Microsoft Access à migração, conversão e upsizing

Formas de partilhar uma base de dados de ambiente de trabalho do Access

Nota:  Esta página foi traduzida automaticamente e pode conter erros gramaticais ou imprecisões. O nosso objetivo é que estes conteúdos lhe sejam úteis. Pode indicar-nos se estas informações foram úteis? Eis o artigo em inglês para sua referência.​

Aumente os seus conhecimentos do Office
Explore as formações
Seja o primeiro a obter novas funcionalidades
Adira ao Office Insider

As informações foram úteis?

Obrigado pelos seus comentários!

Obrigado pelo seu feedback! Parece que poderá ser benéfico reencaminhá-lo para um dos nossos agentes de suporte do Office.

×