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 do Access não é uma exceção. Por exemplo, uma base de dados do Access tem um limite de tamanho de 2 GB e não pode suportar mais de 255 utilizadores em simultâneo. Por isso, quando está na altura da sua base de dados do Access para ir para o nível seguinte, pode migrar para o SQL Server. O SQL Server (seja no local ou na nuvem do Azure) suporta quantidades maiores de dados, mais utilizadores simultâneos e tem uma maior capacidade do que o motor de base de dados JET/ACE. Este guia dá-lhe um início suave à sua jornada do SQL Server, ajuda a preservar as soluções de front-end do Access que criou e, felizmente, lhe motiva o acesso às futuras soluções de base de dados. O assistente de redimensionamento foi removido do Access no Access 2013, por isso agora pode utilizar o Microsoft SQL Server Migration Assistant (SSMA). Para migrar com êxito, siga estes estágios.

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

Antes de começar

As secções seguintes fornecem informações de fundo e outras informações para o ajudar a começar.

Acerca de bases de dados divididas

Todos os objetos de 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 front-end e uma base de dados de front-end. Isto chama-se dividir a base de dados e foi concebido para facilitar a partilha num ambiente de rede. O ficheiro de base de dados de extremidade anterior só tem de conter tabelas e relações. O ficheiro front-end só tem de conter todos os outros objetos, incluindo formulários, relatórios, consultas, macros, módulos de VBA e tabelas ligadas para a base de dados de extremidade anterior. Ao migrar uma base de dados do Access, é semelhante a uma base de dados dividida nesse SQL Server que está a funcionar como um novo ponto de extremidade para os dados que estão agora localizados num servidor.

Como resultado, pode continuar a manter a base de dados de front-end do Access com tabelas ligadas às tabelas do SQL Server. De forma eficaz, pode derivar as vantagens do desenvolvimento rápido de aplicações que uma base de dados do Access fornece, juntamente com a escalabilidade do SQL Server.

Vantagens do SQL Server

Ainda precisa de algum convencer para migrar para o SQL Server? Eis algumas vantagens adicionais a pensar:

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

  • Maior disponibilidade    Com o SQL Server, pode efetuar uma cópia de segurança de forma incremental ou completa, a base de dados enquanto esta está em utilização. 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 normalmente tem um desempenho melhor do que uma base de dados do Access, especialmente com uma base de dados de tamanho de terabytes grande. Além disso, o SQL Server processa consultas de forma muito mais rápida e eficiente ao processar consultas em paralelo, utilizando vários segmentos nativos num único processo para lidar com pedidos de utilizador.

  • Segurança melhorada    Com uma ligação fidedigna, o SQL Server integra-se à segurança de sistema do Windows para fornecer um único acesso integrado à rede e à base de dados, empregando o melhor dos dois sistemas de segurança. Isto torna muito mais fácil administrar esquemas de segurança complexos. O SQL Server é o armazenamento ideal para informações sigilosas, tais como números de segurança social, dados de cartões de crédito e endereços confidenciais.

  • Recuperação imediata    Se o sistema operativo falhar ou a energia for desligada, o SQL Server pode recuperar automaticamente a base de dados para um estado consistente em questão de minutos e sem qualquer intervenção do administrador de bases de dados.

  • Utilização da VPN    O Access e as VPNS (Virtual Private Networks) não se encontram em conjunto. Mas com o SQL Server, os utilizadores remotos podem utilizar ainda utilizar a base de dados front-end do Access num ambiente de trabalho e o SQL Server Infront-end localizado atrás da Firewall VPN.

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

Escolha a melhor opção do Azure SQL Server

Se estiver a migrar para o Azure SQL Server, existem três opções para escolher, cada uma com vantagens diferentes:

  • Uma base de dados/pools elásticos    Esta opção tem o seu próprio conjunto de recursos geridos através de um servidor de bases de dados SQL. Uma base de dados única é como uma base de dados contida no SQL Server. Também pode adicionar um pool elástico, que é uma coleção de bases de dados com um conjunto partilhado de recursos geridos através do servidor de bases de dados SQL. As funcionalidades do SQL Server utilizadas mais frequentemente estão disponíveis com cópias de versão, correção e recuperação incorporados. No entanto, não é possível a migração de tempo de manutenção e a migração do SQL Server Garantidas podem ser difíceis.

  • Instância gerida    Esta opção é uma coleção de bases de dados de sistema e de utilizador com um conjunto partilhado de recursos. Uma instância gerida é como uma instância da base de dados do SQL Server que é altamente compatível com o SQL Server no local. Uma instância gerida tem backups incorporados, patching, recuperação e é fácil de migrar a partir do SQL Server. No entanto, existe um pequeno número de funcionalidades do SQL Server que não estão disponíveis e não garantem uma hora de manutenção exata.

  • Máquina Virtual do Azure    Esta opção permite-lhe executar o SQL Server dentro de uma máquina virtual na nuvem do Azure. Tem controlo total sobre o motor do SQL Server e um caminho de migração fácil. No entanto, tem de gerir os seus backups, patches e recuperação.

Para obter mais informações, consulte o artigo escolher o caminho de migração da base de dados para o Azure e selecionar a opção do SQL Server correta no Azure.

Primeiros passos

Existem alguns problemas que pode resolver para o início, o que pode ajudar a simplificar o processo de migração antes de executar o SSMA:

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

  • Verificar as relações de chave primária/externa    Certifique-se de que estas relações se baseiam em campos com tipos e tamanhos de dados consistentes. O SQL Server não suporta colunas Unidas com diferentes tipos de dados e tamanhos em restrições de chave externa.

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

Antes de executar o SSMA, siga os primeiros passos seguintes.

  1. Feche a base de dados do Access.

  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. mdbe, em seguida, remova a segurança de nível de utilizador.

  4. Criar uma cópia de segurança da sua base de dados. Para obter mais informações, consulte o artigo proteger os seus dados com processos de cópia de segurança e restauro.

Sugestão    Considere instalar o Microsoft SQL Server Express Edition no seu ambiente de trabalho que suporta até 10 GB e é uma forma gratuita e fácil de executar e verificar a sua migração. Quando se liga, 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 o Office 365 e, em seguida, utilize o motor de base de dados do Access 2010 para migrar a base de dados do Access ao utilizar o SSMA. Para obter mais informações, consulte o motor de base de dados do Microsoft Access 2010redistribuível.

Executar o 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. Os formulários, relatórios, macros e módulos VBA não são convertidos. O explorador de metadados do SQL Server apresenta os seus objetos de base de dados do Access e os 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 decidam transferir objetos adicionais no futuro.

Nota    O processo de migração pode demorar algum tempo consoante o tamanho dos seus objetos de base de dados e a quantidade de dados que têm de ser transferidos.

  1. Para migrar uma base de dados com o SSMA, primeiro transfira e instale o software ao fazer duplo clique no ficheiro MSI transferido. Certifique-se de que instala a versão apropriada do 32 ou do 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 do Access.

    Também pode abri-lo num computador com acesso à base de dados do Access a partir da rede numa pasta partilhada.

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

  4. Se estiver a migrar para o SQL Server 2016 ou posterior e quiser atualizar uma tabela ligada, adicione uma coluna da multiversão ao selecionar ferramentas de revisão > definições do projeto > geral.

    O campo da multiversão ajuda a evitar conflitos de registo. O Access utiliza este campo de multiversão numa tabela ligada do SQL Server para determinar quando o registo foi atualizado pela última vez. Além disso, se adicionar o campo do doversion a uma consulta, o Access utiliza-o para voltar a selecionar a linha após uma operação de atualização. Isto melhora a eficiência ao ajudar a evitar erros de conflito de gravação e a um registo de cenários de eliminação que pode ocorrer quando o Access detecta resultados diferentes da submissão original, tais como podem ocorrer com tipos de dados de número de ponto flutuante e acionadores que modificam colunas. No entanto, evite utilizar o campo da multiversão em formulários, relatórios ou código VBA. Para obter mais informações, consulte a versão.

    Nota    Evite a multiversão confusa com carimbos de data/hora. Apesar de o carimbo de data/hora de palavra-chave ser um sinônimo para a versão do servidor SQL Server, não pode utilizar a versão do tipo de dados como carimbo de data/hora.

  5. Para definir tipos de dados precisos, selecione ferramentas de revisão > definições do projeto > mapeamento de tipos. Por exemplo, se armazenar apenas texto em inglês, pode utilizar 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 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 externas

  • Índices e valores predefinidos

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

Como prática recomendada, 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 efetuar a migração e passos de correção de erros individuais a efetuar antes de realmente mover o objetos.

Converter objetos de base de dados leva as definições de objeto dos metadados do Access, converte-as em sintaxe equivalente de Transact-SQL (T-SQL)e, em seguida, carrega estas informações no projeto. Em seguida, pode ver os objetos SQL Server ou SQL Azure e as propriedades ao utilizar o SQL Server ou o explorador de metadados do SQL Azure.

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

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

Ligar tabelas

Considere instalar a versão mais recente do OLE DB e dos controladores ODBC do SQL Server em vez de utilizar os controladores nativos do SQL Server que são fornecidos com o Windows. Os controladores mais recentes não apenas estão mais rápidos, mas suportam novas funcionalidades no Azure SQL que os drivers anteriores não o fazem. Pode instalar os controladores em cada computador no qual a base de dados convertida é utilizada. Para obter mais informações, consulte o artigo Microsoft OLE DB driver 18 para SQL Server e Microsoft ODBC Driver 17 para SQL Server.

Depois de migrar as tabelas do Access, pode criar uma ligação para as tabelas no SQL Server que agora alojam os seus dados. A ligação directamente a partir do Access também fornece uma forma mais simples de ver os seus dados, em vez de utilizar as ferramentas de gestão mais complexas do SQL Server.  Pode consultar e editar dados ligados consoante as permissões configuradas pelo seu administrador de bases de dados do SQL Server.

Nota    Se criar um DSN ODBC ao ligar à base de dados do SQL Server durante o processo de ligação, crie o mesmo DSN em todas as máquinas que utilizem a nova aplicação ou utilize programaticamente a cadeia de ligação armazenada no ficheiro DSN.

Para obter mais informações, consulte o artigo ligar ou importar dados de uma base de dados do Azure SQL Server e importar ou ligar a dados numa base de dados do SQL Server.

Mostram   Não se esqueça de utilizar o gestor de tabelas ligadas no Access para atualizar e ligar de forma conveniente as tabelas. Para obter mais informações, consulte o artigo gerir tabelas ligadas.

Testar e rever

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

Consultas

Apenas as consultas selecionar são convertidas; as outras consultas não são, incluindo a seleção de consultas que levam parâmetros. Algumas consultas podem não ser completamente convertidas e o SSMA relata erros de consulta durante o processo de conversão. Pode editar manualmente objetos que não são convertidos utilizando a 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 em servidores do SQL Server. Para obter mais informações, consulte comparar o acesso SQL com o SQL Server TSQL.

Tipos de dados

O Access e o SQL Server têm tipos de dados semelhantes, mas tenha em atenção os seguintes problemas potenciais.

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. Pode utilizar este tipo de dados para calcular de forma eficaz números grandes, mas necessita de utilizar o formato de ficheiro de base 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 o artigo utilizar o tipo de dados número grande e escolher entre a versão de 64 bits ou de 32 bits do Office.

Sim/Não    Por predefinição, uma coluna Sim/não é convertida num campo de bits do SQL Server. Para evitar a proteção contra gravações, Certifique-se de que o campo bit está definido para não permitir valores nulos. NO SSMA, pode selecionar a coluna bit para definir a propriedade Allow NULLs para não. Em TSQL, utilize as instruções CREATE TABLE ou ALTER TABLE .

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

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

  • Utilize 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, bem como a data. Por exemplo:

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

    • DateOrdered entre 1/1/19 00:00:00 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 do Access. No SQL Server, tem várias opções a considerar. Pode extrair os ficheiros da base de dados do Access e, em seguida, considerar armazenar ligações para os ficheiros na base de dados do SQL Server. Em alternativa, pode utilizar FILESTREAM, filetables ou EDR (Remote BLOB Store) para manter os anexos armazenados na base de dados do SQL Server.

Hiperligação    As tabelas do Access têm colunas de hiperligação que não suportam o SQL Server. Por predefinição, estas colunas serão convertidas em colunas nvarchar (max) no SQL Server, mas pode personalizar o mapeamento para selecionar um tipo de dados mais pequeno. Na sua solução de acesso, pode continuar a utilizar o comportamento de Hiperligação em formulários e relatórios se definir a propriedade hiperligação para o controlo como verdadeiro.

Campo de valor múltiplo    O campo de múltiplos valores do Access é convertido no 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 o mapeamento de tipos de dados do Access e do SQL Server, consulte comparar tipos de dados.

Nota    Os campos de valores múltiplos não são convertidos e descontinuados no Access 2010.

Para obter mais informações, consulte o artigo tipos de data e hora, tipos de cadeia e binarye tipos numéricos.

Visual Basic

Apesar de o VBA não ser suportado pelo SQL Server, tenha em atenção os seguintes problemas possíveis:

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

Funções definidas pelo utilizador em consultas    As consultas do Microsoft Access suportam a utilização de funções definidas em módulos VBA para processar dados transmitidos aos mesmos. As consultas podem ser consultas autônomas, instruções SQL em origens de registos de formulário/relatório, origens 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 de validação predefinidas. O SQL Server não pode executar estas funções definidas pelo utilizador. Poderá ter de reestruturar estas funções manualmente e convertê-las em procedimentos armazenados no SQL Server.

Otimizar o desempenho

Até à data, a forma mais importante de otimizar o desempenho com o seu novo SQL Server do início é decidir quando utilizar consultas locais ou remotas. Ao migrar os seus dados para o SQL Server, também está a mudar de um servidor de ficheiros para um modelo de base de dados de cliente/servidor de computação. Siga estas diretrizes gerais:

  • Execute as consultas pequenas e só de leitura no cliente para obter um acesso mais rápido.

  • Execute as consultas de leitura/escrita longas no servidor para usufruir do maior poder de processamento.

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

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

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

Seguem-se as diretrizes recomendadas adicionais.

Colocar lógica no servidor    A sua aplicação também pode utilizar vistas, funções definidas pelo utilizador, procedimentos armazenados, campos calculados e acionadores para centralizar e partilhar a lógica da aplicação, regras e políticas empresariais, consultas complexas, validação de dados e código de integridade referencial no Server, em vez de no cliente. Perguntar-se, esta consulta ou tarefa pode ser executada no servidor de forma mais rápida e fácil? Por fim, teste cada consulta para garantir um desempenho ideal.

Utilizar vistas em formulários e relatórios    No Access, faça o seguinte:

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

  • Para relatórios, utilize uma vista SQL como origem do registo. No entanto, crie uma vista separada para cada relatório, para que possa atualizar de forma mais fácil um relatório específico, sem afetar outros relatórios.

Minimizar o carregamento de dados num formulário ou relatório    Não apresentar dados até que o utilizador o peça. Por exemplo, mantenha a propriedade OrigemDoRegistro em branco, faça com que os utilizadores selecionem um filtro no seu formulário e, em seguida, preencha a propriedade OrigemDoRegistro com o seu filtro. Em alternativa, utilize a cláusula WHERE de DoCmd. OpenForm e o DoCmd. OpenReport para apresentar os registos exatos necessários para o utilizador. Considere desativar a navegação no registo.

Tenha cuidado com consultas heterogêneas   Evite executar uma consulta que combine uma tabela do Access local e uma tabela ligada do SQL Server, por vezes denominada consulta híbrida. Este tipo de consulta ainda requer o Access para transferir todos os dados do SQL Server para o computador local e, em seguida, executar a consulta, este não executa a consulta no SQL Server.

Quando utilizar tabelas locais    Considere utilizar tabelas locais para dados que raramente são alterados, como a lista de Estados ou províncias num país ou região. As tabelas estáticas são frequentemente utilizadas para filtrar e podem ter um melhor desempenho no front-end do Access.

Para obter mais informações, consulte o supervisor de otimização do motor de bases de dados, utilizar o analisador de desempenho para otimizar uma base de dados do Accesse otimizar as aplicações do Microsoft Office Access ligadas ao SQL Server.

Consulte Também

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

blogue de migração de dados da Microsoft

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

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.

×