Migrar um banco de dados do Access para o SQL Server

Migrar um banco de dados do Access para o SQL Server

Todos temos limites e um banco de dados do Access não é uma exceção. Por exemplo, um banco de dados do Access tem um limite de tamanho de 2 GB e não pode dar suporte a mais de 255 usuários simultâneos. Então, quando é a hora de seu banco de dados do Access ir para o próximo nível, você pode migrar para o SQL Server. O SQL Server (seja no local ou na nuvem do Azure) oferece suporte a quantidades maiores de dados, a usuários simultâneos e tem maior capacidade do que o mecanismo de banco de dados JET/ACE. Este guia fornece um início perfeito para a viagem do SQL Server, ajuda a preservar as soluções de front-end do Access que você criou e espero que o use para futuras soluções de banco de dados. O assistente de upsizing foi removido do Access no Access 2013, portanto, agora você pode usar o Microsoft SQL Server Migration Assistant (SSMA). Para migrar com êxito, siga estes estágios.

Os estágios da migração de banco de dados para o SQL Server

Antes de começar

As seções a seguir fornecem informações básicas e outras informações para ajudá-lo a começar a usar.

Sobre bancos de dados divididos

Todos os objetos de banco de dados do Access podem estar em um arquivo de banco de dados ou podem ser armazenados em dois arquivos de banco de dados: um banco de dados front-end e um banco de dados back-end. Isso é chamado de divisão do banco de dados e é projetado para facilitar o compartilhamento em um ambiente de rede. O arquivo de banco de dados back-end só deve conter tabelas e relações. O arquivo front-end deve conter somente todos os outros objetos, incluindo formulários, relatórios, consultas, macros, módulos do VBA e tabelas vinculadas para o banco de dados back-end. Ao migrar um banco de dados do Access, ele é semelhante a um banco de dados dividido no SQL Server que está atuando como um novo back-end para os dados que agora estão localizados em um servidor.

Como resultado, você ainda pode manter o banco de dados do Access de front-end com tabelas vinculadas às tabelas do SQL Server. Efetivamente, você pode derivar os benefícios de um rápido desenvolvimento de aplicativos que um banco de dados do Access fornece, juntamente com a escalabilidade do SQL Server.

Benefícios do SQL Server

Ainda precisa de algo convincente em migrar para o SQL Server? Veja a seguir alguns benefícios adicionais a serem considerados:

  • Mais usuários simultâneos    O SQL Server pode manipular muitos usuários simultâneos do Access e minimiza os requisitos de memória quando mais usuários são adicionados.

  • Maior disponibilidade    Com o SQL Server, você pode fazer backup dinamicamente, seja incremental ou completo, o banco de dados enquanto ele está em uso. Consequentemente, não é necessário obrigar os usuários a sair do banco de dados para fazer backup dos dados.

  • Alto desempenho e escalabilidade    O banco de dados do SQL Server geralmente executa melhor que um banco de dados do Access, especialmente com um banco de dados grande e com tamanho de terabyte. Além disso, o SQL Server processa consultas de forma muito mais rápida e eficiente ao processar consultas em paralelo, usando vários threads nativos em um único processo para lidar com solicitações de usuário.

  • Segurança aprimorada    Usando uma conexão confiável, o SQL Server integra-se com a segurança do sistema do Windows para fornecer um único acesso integrado à rede e ao banco de dados, empregando o melhor dos dois sistemas de segurança. Isso torna muito mais fácil administrar esquemas de segurança complexos. O SQL Server é o armazenamento ideal para informações confidenciais, como números de CPF, dados de cartão de crédito e endereços confidenciais.

  • Capacidade de recuperação imediata    Se o sistema operacional travar ou se o sistema estiver desligado, o SQL Server pode recuperar automaticamente o banco de dados para um estado consistente em questão de minutos e sem intervenção do administrador do banco de dados.

  • Uso da VPN    O Access e as redes privadas virtuais (VPN) não ficam juntos. Mas com o SQL Server, os usuários remotos podem usar ainda usam o banco de dados de front-end do Access em uma área de trabalho e o back-end do SQL Server localizado atrás do firewall da VPN.

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

Escolher a melhor opção do Azure SQL Server

Se você estiver migrando para o SQL Server do Azure, há três opções de seleção, cada uma com diferentes benefícios:

  • Um único banco de dados/pools elásticos    Essa opção tem seu próprio conjunto de recursos gerenciados por meio de um servidor de banco de dados SQL. Um único banco de dados é como um banco de dados independente no SQL Server. Você também pode adicionar um pool elástico, que é uma coleção de bancos de dados com um conjunto compartilhado de recursos gerenciados por meio do servidor de banco de dados SQL. Os recursos do SQL Server mais comumente usados estão disponíveis com backups incorporados, correção e recuperação. Mas não há tempo exato de manutenção garantido e a migração do SQL Server pode ser difícil.

  • Instância gerenciada    Essa opção é uma coleção de bancos de dados de sistema e de usuários com um conjunto compartilhado de recursos. Uma instância gerenciada é como uma instância do banco de dados do SQL Server que é altamente compatível com o SQL Server local. Uma instância gerenciada tem backups incorporados, patching, recuperação e fácil de migrar do SQL Server. No entanto, há um pequeno número de recursos do SQL Server que não estão disponíveis e nenhum tempo exato de manutenção garantido.

  • Máquina Virtual Azure    Essa opção permite executar o SQL Server dentro de uma máquina virtual na nuvem do Azure. Você tem controle total sobre o mecanismo do SQL Server e um caminho de migração simples. Mas você precisa gerenciar seus backups, patches e recuperação.

Para obter mais informações, consulte escolhendo o caminho de migração do banco de dados para o Azure e escolha a opção correta do SQL Server no Azure.

Primeiras etapas

Há alguns problemas que você pode solucionar para cima que podem ajudar a simplificar o processo de migração antes de executar o SSMA:

  • Adicionar índices de tabela e chaves primárias    Verifique se cada tabela do Access 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 vinculada tenha uma chave primária se a tabela puder ser atualizada.

  • Verificar as relações de chave primária/estrangeira    Verifique se essas relações se baseiam em campos com tipos e tamanhos de dados consistentes. O SQL Server não oferece suporte a colunas Unidas com tipos de dados e tamanhos diferentes em restrições de chave estrangeira.

  • Remover a coluna de anexos    O SSMA não migra tabelas que contenham a coluna de anexos.

Antes de executar o SSMA, faça o seguinte primeiro procedimento.

  1. Feche o banco de dados do Access.

  2. Certifique-se de que os usuários atuais conectados ao banco de dados também fechem o banco de dados.

  3. Se o banco de dados estiver no formato de arquivo. mdb, remova a segurança em nível de usuário.

  4. Fazer backup do banco de dados. Para obter mais informações, consulte proteger seus dados com processos de backup e restauração.

Dica    Considere a instalação do Microsoft SQL Server Express Edition na área de trabalho, que oferece suporte a até 10 GB, e uma maneira gratuita e fácil de executar e verificar a migração. Quando você se conecta, use o LocalDB como a instância do banco de dados.

Dica    Se possível, use uma versão autônoma do Access. Se você só puder usar o Office 365, use o mecanismo de banco de dados do Access 2010 para migrar seu banco de dados do Access ao usar o SSMA. Para obter mais informações, consulte mecanismo de banco de dados do Microsoft Access 2010redistribuível.

Executar o SSMA

A Microsoft oferece 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 Gerenciador de metadados do SQL Server exibe seus objetos de banco de dados do Access e objetos do SQL Server, permitindo que você examine o conteúdo atual de ambos os bancos de dados. Essas duas conexões são salvas no arquivo de migração, caso você decida transferir objetos adicionais no futuro.

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

  1. Para migrar um banco de dados usando o SSMA, primeiro Baixe e instale o software clicando duas vezes no arquivo MSI baixado. Verifique se você instalou a versão apropriada do 32 ou do bit 64 para o seu computador.

  2. Depois de instalar o SSMA, abra-o na área de trabalho, de preferência do computador com o arquivo de banco de dados do Access.

    Você também pode abri-lo em um computador que tenha acesso ao banco de dados do Access a partir da rede em uma pasta compartilhada.

  3. Siga as instruções iniciais do SSMA para fornecer informações básicas, como o local do SQL Server, o banco de dados do Access e os objetos para migrar, informações de conexão e se você deseja criar tabelas vinculadas.

  4. Se você estiver migrando para o SQL Server 2016 ou posterior e quiser atualizar uma tabela vinculada, adicione uma coluna do doversion selecionando ferramentas de revisão > configurações do projeto > geral.

    O campo da timeversion ajuda a evitar conflitos de registro. O Access usa este campo de timeversion em uma tabela vinculada do SQL Server para determinar quando o registro foi atualizado pela última vez. Além disso, se você adicionar o campo de linha de linha a uma consulta, o Access o usará para selecionar novamente a linha após uma operação de atualização. Isso aumenta a eficiência, ajudando a evitar erros de conflito de gravação e registros de exclusão que podem ocorrer quando o Access detecta resultados diferentes do envio original, como pode ocorrer com tipos de dados numéricos de ponto flutuante e gatilhos que modificam colunas. No entanto, evite usar o campo de timeversion em formulários, relatórios ou código VBA. Para obter mais informações, consulte doversion.

    Nota    Evite a multiversão confusa com carimbos de data/hora. Embora a palavra-chave timestamp seja um sinônimo para a multiversão no SQL Server, você não pode usar o timeversion como uma maneira de usar o carimbo de data/hora em uma entrada de dados.

  5. Para definir tipos de dados precisos, selecione ferramentas de revisão > configurações do projeto > mapeamento de tipos. Por exemplo, se você só armazenar texto em inglês, você pode usar o tipo de dados varchar em vez do nvarchar .

Converter objetos

O SSMA converte objetos do Access em objetos do SQL Server, mas não copia os objetos imediatamente. O SSMA fornece uma lista dos seguintes objetos a serem migrados para que você possa decidir se deseja movê-los para o banco de dados do SQL Server:

  • Tabelas e colunas

  • Selecione consultas sem parâmetros.

  • Chaves primárias e estrangeiras

  • Índices e valores padrão

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

Como prática recomendada, use o relatório de avaliação do SSMA, que mostra os resultados da conversão, incluindo erros, avisos, mensagens informativas, estimativas de tempo para executar a migração e etapas de correção de erro individuais a serem tomadas antes de realmente mover o Eles.

A conversão de objetos de banco de dados usa as definições de objeto dos metadados do Access, os converte na sintaxe Transact-SQL (T-SQL)equivalente e, em seguida, carrega essas informações no projeto. Em seguida, você pode exibir os objetos SQL Server ou SQL Azure e suas propriedades usando o SQL Server ou o Gerenciador de metadados do SQL Azure.

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

Dica    Depois de migrar com êxito seu banco de dados do Access, salve o arquivo de projeto para uso posterior para que você possa migrar seus dados novamente para teste ou migração final.

Vincular tabelas

Considere a instalação da versão mais recente do SQL Server OLE DB e dos drivers ODBC em vez de usar os drivers nativos do SQL Server fornecidos com o Windows. Não só os drivers mais recentes são mais rápidos, mas oferecem suporte aos novos recursos do Azure SQL que os drivers anteriores não fazem. Você pode instalar os drivers em cada computador em que o banco de dados convertido é usado. Para obter mais informações, confira Microsoft OLE DB driver 18 para SQL Server e Microsoft ODBC Driver 17 para SQL Server.

Depois de migrar as tabelas do Access, você pode criar um link para as tabelas no SQL Server que agora hospeda seus dados. Vincular diretamente do Access também fornece uma maneira mais simples de exibir seus dados em vez de usar as ferramentas de gerenciamento do SQL Server mais complexas.  Você pode consultar e editar dados vinculados dependendo das permissões configuradas pelo administrador do banco de dados do SQL Server.

Nota    Se você criar um DSN ODBC ao vincular ao banco de dados do SQL Server durante o processo de vinculação, crie o mesmo DSN em todas as máquinas que usam o novo aplicativo ou use programaticamente a cadeia de conexão armazenada no arquivo DSN.

Para obter mais informações, consulte vincular ou importar dados de um banco de dados do SQL Server do Azure e importar ou vincular a dados em um banco de dados do SQL Server.

Tampa   Não se esqueça de usar o Gerenciador de tabelas vinculadas no Access para atualizar e vincular as tabelas convenientemente. Para obter mais informações, consulte gerenciar tabelas vinculadas.

Testar e revisar

As seções a seguir descrevem problemas comuns que você pode encontrar durante a migração e como lidar com eles.

Consultas

Somente as consultas selecionadas são convertidas; outras consultas não estão, incluindo consultas seleção que usam parâmetros. Algumas consultas podem não ser completamente convertidas e o SSMA relata erros de consulta durante o processo de conversão. Você pode editar manualmente objetos que não são convertidos usando a sintaxe T-SQL. Erros de sintaxe também podem exigir a conversão manual de funções específicas de acesso e tipos de dados para o SQL Server. Para obter mais informações, consulte comparando o Access SQL com TSQL do SQL Server.

Tipos de dados

O Access e o SQL Server têm tipos de dados similares, mas lembre-se dos seguintes possíveis problemas.

Número grande    O tipo de dados número grande armazena um valor numérico não monetário e é compatível com o tipo de dados bigint do SQL. Você pode usar esse tipo de dados para calcular com eficiência números grandes, mas requer o uso do formato de arquivo de banco de dados do Access 16 (16.0.7812 ou posterior). accdb e funciona melhor com a versão de 64 bits do Access. Para obter mais informações, consulte usando o tipo de dados número grande e escolha entre a versão de 64 bits ou 32 bits do Office.

Sim/Não    Por padrão, uma coluna do Access Sim/não é convertida em um campo de bits do SQL Server. Para evitar o bloqueio de registros, Certifique-se de que o campo de bits esteja definido para impedir valores nulos. NO SSMA, você pode selecionar a coluna de bits para definir a propriedade permitir nulos como não. Em TSQL, use as instruções CREATE TABLE ou ALTER TABLE .

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

  • Se o nível de compatibilidade do banco de dados for 130 (SQL Server 2016) ou superior, e uma tabela vinculada contiver uma ou mais colunas DateTime ou datetime2, a tabela poderá retornar a mensagem #deleted nos resultados. Para obter mais informações, consulte a tabela vinculada do Access para o banco de dados SQL-Server retorna #deleted.

  • Use o tipo de dados datetime2 que tem um intervalo de datas maior do que DateTime.

  • Ao consultar datas no SQL Server, leve em conta a hora e a data. Por exemplo:

    • DateOrdered entre 1/1/19 e 1/31/19 pode não incluir todos os pedidos.

    • DateOrdered entre 1/1/19 00:00:00 AM e 1/31/19 11:59:59 PM inclui todos os pedidos.

Anexo   O tipo de dados anexo armazena um arquivo no banco de dados do Access. No SQL Server, há várias opções a serem consideradas. Você pode extrair os arquivos do banco de dados do Access e, em seguida, considerar o armazenamento de links para os arquivos em seu banco de dados do SQL Server. Você também pode usar FILESTREAM, filetables ou RBS (Remote BLOB Store) para manter os anexos armazenados no banco de dados do SQL Server.

Hiperlink    As tabelas do Access têm colunas de hiperlink que o SQL Server não suporta. Por padrão, essas colunas serão convertidas em colunas nvarchar (max) no SQL Server, mas você pode personalizar o mapeamento para escolher um tipo de dados menor. Na sua solução do Access, você ainda pode usar o comportamento de hiperlink em formulários e relatórios se definir a propriedade Hyperlink para o controle como verdadeiro.

Campo de múltiplos valores    O campo Access multivalued é convertido no SQL Server como um campo ntext que contém o conjunto de valores delimitado. Como o SQL Server não oferece suporte a um tipo de dados de múltiplos valores que modela uma relação muitos para muitos, pode ser necessário um trabalho adicional de design e conversão.

Para obter mais informações sobre o mapeamento de tipos de dados do Access e do SQL Server, consulte comparar tipos de dados.

Nota    Os campos de vários valores não são convertidos e descontinuados no Access 2010.

Para obter mais informações, consulte tipos de data e hora, tipos de cadeia de caracteres e tipos bináriose tipos numéricos.

Visual Basic

Embora o VBA não seja compatível com o SQL Server, observe os seguintes possíveis problemas:

Funções VBA em consultas    As consultas do Access dão suporte a funções do VBA em dados em uma coluna de consulta. Mas consultas do Access que usam funções VBA não podem ser executadas no SQL Server, portanto todos os dados solicitados são passados para o Microsoft Access para processamento. Na maioria dos casos, essas consultas devem ser convertidas em consultas de passagem.

Funções definidas pelo usuário em consultas    As consultas do Microsoft Access dão suporte ao uso de funções definidas em módulos VBA para processar dados passados a elas. As consultas podem ser consultas autônomas, instruções SQL em fontes de registro de formulário/relatório, fontes de dados de caixas de combinação e caixas de listagem em formulários, relatórios e campos de tabela e expressões de regra padrão ou de validação. O SQL Server não pode executar essas funções definidas pelo usuário. Talvez seja necessário redesenhar manualmente essas funções e convertê-las em procedimentos armazenados no SQL Server.

Otimizar o desempenho

Até agora, a maneira mais importante de otimizar o desempenho com o novo SQL Server do back-end é decidir quando usar consultas locais ou remotas. Ao migrar seus dados para o SQL Server, você também está mudando de um servidor de arquivos para um modelo de banco de dados de servidor cliente de computação. Siga estas diretrizes gerais:

  • Executar consultas pequenas e somente leitura no cliente para obter acesso mais rápido.

  • Executar uma longa consulta de leitura/gravação no servidor para tirar proveito da maior capacidade 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 banco de dados do servidor cliente

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

Veja a seguir as diretrizes adicionais recomendadas.

Colocar lógica no servidor    Seu aplicativo também pode usar modos de exibição, funções definidas pelo usuário, procedimentos armazenados, campos calculados e gatilhos para centralizar e compartilhar a lógica do aplicativo, regras e políticas comerciais, consultas complexas, validação de dados e código de integridade referencial no Server, em vez do cliente. Pergunte-se, esta consulta ou tarefa pode ser executada no servidor melhor e mais rápida? Por fim, teste cada consulta para garantir o desempenho ideal.

Usar modos de exibição em formulários e relatórios    No Access, faça o seguinte:

  • Para formulários, use um modo de exibição SQL para um formulário somente leitura e um modo de exibição indexado SQL para um formulário de leitura/gravação como fonte de registro.

  • Para relatórios, use um modo de exibição SQL como fonte de registro. No entanto, crie um modo de exibição separado para cada relatório para que você possa atualizar mais facilmente um relatório específico, sem afetar outros relatórios.

Minimizar o carregamento de dados em um formulário ou relatório    Não exiba os dados até que o usuário solicite. Por exemplo, mantenha a propriedade RecordSource em branco, faça com que os usuários selecionem um filtro em seu formulário e, em seguida, preencham a propriedade OrigemDoRegistro com o filtro. Ou use a cláusula WHERE de DoCmd. AbrirFormulário e DoCmd. AbrirRelatório para exibir o (s) exato (s) registro (s) necessário (s) pelo usuário. Considere desativar a navegação de registros.

Cuidado com consultas heterogêneas   Evite executar uma consulta que combine uma tabela de acesso local e uma tabela vinculada do SQL Server, às vezes chamadas de uma consulta híbrida. Esse tipo de consulta ainda requer acesso para baixar todos os dados do SQL Server para o computador local e, em seguida, executar a consulta, ele não executa a consulta no SQL Server.

Quando usar tabelas locais    Considere o uso de tabelas locais para dados que raramente mudam, como a lista de Estados ou províncias em um país ou região. Geralmente, as tabelas estáticas são usadas para filtragem e podem ter melhor desempenho no front-end do Access.

Para obter mais informações, consulte o supervisor de sintonia do mecanismo de banco de dados, use o analisador de desempenho para otimizar um banco de dados do Accesse otimizar os aplicativos do Microsoft Office Access vinculados ao SQL Server.

Confira também

Guia de migração do banco de dados do Azure

do blog de migração de dados da Microsoft

Microsoft Access para migração, conversão e upsizing do SQL Server

Maneiras de compartilhar um banco de dados da área de trabalho do Access

Observação:  Esta página foi traduzida automaticamente e pode apresentar erros gramaticais ou imprecisões. Nosso objetivo é que este conteúdo seja útil para você. Você pode nos dizer se as informações foram úteis? Use o artigo em inglês como referência.​

Expanda suas habilidades no Office
Explore o treinamento
Obtenha novos recursos primeiro
Ingressar no Office Insider

Essas informações foram úteis?

Obrigado por seus comentários!

Agradecemos pelos seus comentários! Parece que pode ser útil conectar você a um de nossos agentes de suporte do Office.

×