Migrer une base de données Access vers SQL Server

Nous avons tous des limites et une base de données Access ne fait pas exception. Par exemple, une base de données Access a une limite de taille de 2 Go et ne peut pas prendre en charge plus de 255 utilisateurs simultanés. Par exemple, lorsqu’il est temps pour votre base de données Access de passer au niveau supérieur, vous pouvez migrer vers SQL Server. SQL Server (en local ou dans le cloud Azure) prend en charge de grandes quantités de données, un nombre d’utilisateurs simultanés et une capacité supérieure à celle du moteur de base de données JET/ACE. Ce guide SQL Server vous permet de commencer votre voyage en douceur, de conserver les solutions frontales Access que vous avez créées et, espérons-le, de vous aider à utiliser Access pour les solutions de base de données futures. L’Assistant De migration a été supprimé d’Access dans Access 2013. Vous pouvez désormais utiliser l’Assistant Migration Microsoft SQL Server (SSMA). Pour migrer correctement, suivez ces étapes.

Étapes de la migration des bases de données vers SQL Server

Avant de commencer

Les sections suivantes fournissent des informations de base et d’autres informations pour vous aider à commencer.

À propos des bases de données fractionnement

Tous les objets de base de données Access peuvent être stockés dans un seul fichier de base de données ou dans deux fichiers de base de données : une base de données frontale et une base de données principale. C’est ce qu’on appelle le fractionnement de la base de données, conçu pour faciliter le partage dans un environnement réseau. Le fichier de base de données principale doit contenir uniquement des tables et des relations. Le fichier frontal doit contenir uniquement tous les autres objets, y compris les formulaires, états, requêtes, macros, modules VBA et tables liées à la base de données principale. Lorsque vous migrez une base de données Access, cette migration est semblable à celle d’une base de données fractionnement dans le SQL Server en tant que nouveau serveur principal pour les données désormais situées sur un serveur.

Par conséquent, vous pouvez toujours conserver la base de données frontale Access avec des tables liées aux SQL Server tables. En réalité, vous pouvez dériver les avantages du développement rapide d’une base de données Access, ainsi que l’évolutivité d’SQL Server.

SQL Server avantages

Vous avez encore besoin de migrer vers un SQL Server ? Voici quelques-uns des avantages supplémentaires à prendre en charge :

  • Plus d’utilisateurs simultanés    SQL Server pouvez gérer un nombre d’utilisateurs simultanés supérieur à celui d’Access et réduire les besoins en mémoire lorsque davantage d’utilisateurs sont ajoutés.

  • Disponibilité accrue    Avec SQL Server, vous pouvez sauvegarder dynamiquement, incrémentielle ou complète, la base de données pendant son utilisation. Ainsi, vous n’êtes pas obligé de forcer les utilisateurs à quitter la base de données pour sauvegarder les données.

  • Performances et évolutivité élevées    En SQL Server, les données de base de données sont généralement plus performants qu’une base de données Access, en particulier avec une base de données de grande taille téraoctet. Par ailleurs, SQL Server processus de traitement des requêtes de façon beaucoup plus rapide et efficace en traitant les requêtes en parallèle, en utilisant plusieurs threads natifs au sein d’un même processus pour gérer les demandes des utilisateurs.

  • Sécurité améliorée    À l’aide d’une connexion fiable, SQL Server s’intègre à la sécurité du système Windows pour fournir un accès intégré unique au réseau et à la base de données, en utilisant le meilleur des deux systèmes de sécurité. Cela facilite la gestion de schémas de sécurité complexes. SQL Server stockage est idéal pour les informations sensibles telles que les numéros de sécurité sociale, les données de carte de crédit et les adresses confidentielles.

  • Récupérabilité immédiate     En cas de panne du système d’exploitation ou de coupure de courant, SQL Server peut automatiquement récupérer la base de données à un état cohérent en quelques minutes et sans aucune intervention de l’administrateur de la base de données.

  • Utilisation d’un réseau privé virtuel (VPN)    Access et les réseaux privés virtuels (VPN) ne s’entendent pas. Avec les SQL Server, les utilisateurs distants peuvent toujours utiliser la base de données frontale Access sur un ordinateur de bureau et le serveur SQL Server situé derrière le pare-feu VPN.

  • Azure SQL Server    Outre les avantages d’SQL Server, offre une évolutivité dynamique sans temps d’arrêt, une optimisation intelligente, une extibilité et une disponibilité globales, une élimination des coûts matériels et une administration réduite.

Choisir la meilleure option d’SQL Server Azure

Si vous migrez vers Azure SQL Server, trois options s’offrent à vous, chacune avec des avantages différents :

  • Une base de données unique/des pools souples    Cette option possède son propre ensemble de ressources gérées via un serveur SQL base de données. Une base de données unique est comme une base de données SQL Server. Vous pouvez également ajouter un pool souple, qui est une collection de bases de données avec un ensemble partagé de ressources gérées via le serveur SQL base de données. Les fonctionnalités d’SQL Server courantes sont disponibles avec les sauvegardes, correctifs et récupération intégrés. Il n’existe cependant aucune garantie de durée de maintenance exacte et de durée SQL Server migration à partir d’un autre emplacement peut être difficile.

  • Instance gérée    Cette option est une collection de bases de données système et utilisateur avec un ensemble partagé de ressources. Une instance gérée est comme une instance de la base SQL Server de données qui est hautement compatible avec SQL Server en local. Une instance gérée possède des sauvegardes intégrées, des correctifs, une récupération et est facile à migrer à partir d’SQL Server. Toutefois, le nombre de SQL Server fonctionnalités non disponibles et de durée de maintenance exacte garantie n’est pas garanti.

  • Machine virtuelle Azure    Cette option vous permet d’exécuter des SQL Server à l’intérieur d’une machine virtuelle dans le cloud Azure. Vous avez un contrôle total sur le moteur SQL Server et un chemin de migration simple. Vous devez toutefois gérer vos sauvegardes, vos correctifs et vos récupérations.

Pour plus d’informations, voir Choisir le chemin de migration de votre base de données vers Azure et Choisir l’option demigration SQL Server droite dans Azure.

Premiers pas

Vous pouvez résoudre à l’avance certains problèmes qui peuvent vous aider à rationaliser le processus de migration avant d’exécuter SSMA :

  • Ajouter des index de table et des clés primaires    Assurez-vous que chaque table Access dispose d’un index et d’une clé primaire. SQL Server nécessite que toutes les tables soient associées à au moins un index et nécessite qu’une table liée soit associée à une clé primaire si la table peut être mise à jour.

  • Vérifier les relations entre les clés primaires et étrangères    Assurez-vous que ces relations sont basées sur des champs dont les types et tailles de données sont cohérents. SQL Server ne prend pas en charge les colonnes jointes ayant des types et tailles de données différents dans des contraintes de clé étrangère.

  • Supprimer la colonne Pièce jointe    SSMA ne migre pas les tables qui contiennent la colonne Pièce jointe.

Avant d’exécuter SSMA, vous devez suivre les premières étapes.

  1. Fermez la base de données Access.

  2. Assurez-vous que les utilisateurs actuels connectés à la base de données ferment également la base de données.

  3. Si la base de données est au format de fichier .mdb,supprimez la sécurité au niveau utilisateur.

  4. Remontez à la base de données. Pour plus d’informations, voir Protéger vos données avec les processus de sauvegarde et de restauration.

Conseil    Vous pouvez installer Microsoft SQL Server édition Express sur votre ordinateur de bureau, qui prend en charge jusqu’à 10 Go. C’est un moyen simple et gratuit de gérer votre migration. Lorsque vous vous connectez, utilisez LocalDB comme instance de base de données.

Conseil    Si possible, utilisez une version autonome d’Access. Si vous ne pouvez utiliser Microsoft 365, utilisez le moteur de base de données Access 2010 pour migrer votre base de données Access lors de l’utilisation de SSMA. Pour plus d’informations, voir Moteur de base de données Microsoft Access 2010 redistribuable.

Exécuter SSMA

Microsoft fournit Microsoft SQL Server Assistant Migration Logiciel (SSMA) pour faciliter la migration. SSMA migre principalement les tables et les requêtes de sélection sans paramètres. Les formulaires, états, macros et modules VBA ne sont pas convertis. L SQL Server’Explorateur de métadonnées affiche vos objets de base de données Access et SQL Server de base de données, ce qui vous permet de consulter le contenu actuel des deux bases de données. Ces deux connexions sont enregistrées dans votre fichier de migration si vous décidez de transférer d’autres objets ultérieurement.

Remarque    Le processus de migration peut prendre du temps en fonction de la taille de vos objets de base de données et de la quantité de données à transférer.

  1. Pour migrer une base de données à l’aide de SSMA, téléchargez et installez d’abord le logiciel en double-cliquant sur le fichier MSI téléchargé. Veillez à installer la version 32 ou 64 bits appropriée pour votre ordinateur.

  2. Après avoir installé SSMA, ouvrez-le sur votre bureau, de préférence à partir de l’ordinateur avec le fichier de base de données Access.

    Vous pouvez également l’ouvrir sur un ordinateur qui a accès à la base de données Access à partir du réseau dans un dossier partagé.

  3. Suivez les instructions de début de SSMA pour fournir des informations de base telles que l’emplacement SQL Server, la base de données Access et les objets à migrer, les informations de connexion et si vous souhaitez créer des tables liées.

  4. Si vous migrez vers SQL Server 2016 ou une version ultérieure et souhaitez mettre à jour une table liée, ajoutez une colonne Rowversion en sélectionnant Outils de révision > Paramètres du projet > Général.

    Le champ rowversion permet d’éviter les conflits d’enregistrement. Access utilise ce champ rowversion dans SQL Server table liée pour déterminer quand l’enregistrement a été mis à jour pour la dernière fois. Par ailleurs, si vous ajoutez le champ Rowversion à une requête, Access l’utilise pour sélectionner à nouveau la ligne après une opération de mise à jour. Cela améliore l’efficacité en évitant les erreurs d’écriture et les scénarios de suppression d’enregistrement qui peuvent se produire lorsqu’Access détecte des résultats différents de la soumission d’origine, par exemple avec des types de données de nombre à flottant et des déclencheurs qui modifient les colonnes. Toutefois, évitez d’utiliser le champ rowversion dans les formulaires, états ou codes VBA. Pour plus d’informations, voir rowversion.

    Remarque    Évitez la confusion de rowversion avec des timestamps. Bien que le mot clé timestamp soit un synonyme de rowversion dans SQL Server, vous ne pouvez pas utiliser rowversion comme moyen d’timestamp une entrée de données.

  5. Pour définir des types de données précis, sélectionnezOutils de révision > Paramètres du projet > Mappage des types. Par exemple, si vous stockez uniquement du texte en anglais, vous pouvez utiliser le type de données varchar plutôt que le type de données nvarchar.

Convertir des objets

SSMA convertit les objets Access en SQL Server objets, mais ne les copie pas immédiatement. SSMA fournit la liste des objets suivants à migrer afin que vous pouvez décider de les déplacer ou non vers SQL Server données :

  • Tableaux et colonnes

  • Sélectionner des requêtes sans paramètres.

  • Clés primaires et étrangères

  • Index et valeurs par défaut

  • Vérifier les contraintes (autoriser la propriété de colonne de longueur nulle, règle de validation de colonne, validation de table)

Il est préférable d’utiliser le rapport d’évaluation SSMA, qui présente les résultats de la conversion, notamment les erreurs, les avertissements, les messages d’information, les estimations de temps pour l’étape de migration et les étapes individuelles de correction des erreurs à effectuer avant de déplacer réellement les objets.

La conversion d’objets de base de données prend les définitions d’objets à partir des métadonnées Access, les convertit en syntaxe Transact-SQL (T-SQL)équivalente, puis charge ces informations dans le projet. Vous pouvez ensuite afficher les objets SQL Server ou SQL Azure et leurs propriétés à l’aide de SQL Server ou SQL Azure’Explorateur de métadonnées.

Pour convertir, charger et migrer des objets vers des SQL Server, suivez ce guide.

Conseil    Une fois que vous avez correctement migré votre base de données Access, enregistrez le fichier de projet pour une utilisation ultérieure, afin de pouvoir migrer à nouveau vos données pour un test ou une migration finale.

Lier des tables

Envisagez d’installer la dernière version SQL Server pilotes OLE DB et ODBC au lieu d’utiliser les pilotes SQL Server natifs qui sont installés sur Windows. Non seulement les pilotes les plus nouveaux sont-ils plus rapides, mais ils supportent de nouvelles fonctionnalités dans Azure SQL que les pilotes précédents ne le font pas. Vous pouvez installer les pilotes sur chaque ordinateur sur lequel la base de données convertie est utilisée. Pour plus d’informations, consultez le pilote OLE DB Microsoft 18 SQL Server et le pilote Microsoft ODBC 17 pourSQL Server.

Après avoir migré les tables Access, vous pouvez lier les tables dans SQL Server qui hébergent désormais vos données. La liaison directement à partir d’Access vous offre également une méthode plus simple pour afficher vos données plutôt que d’utiliser les outils de gestion SQL Server complexes.  Vous pouvez interroger et modifier des données liées en fonction des autorisations définiespar votre SQL Server base de données.

Remarque    Si vous créez un DSN ODBC lorsque vous liez votre base de données SQL Server pendant le processus de liaison, créez le même DSN sur tous les ordinateurs qui utilisent la nouvelle application ou utilisez par programme la chaîne de connexion stockée dans le fichier DSN.

Pour plus d’informations, voir Lier ou importer des données à partir d’une base de données Azure SQL Server et Importer ou lier des données d’une base de SQL Server données.

Conseil   N’oubliez pas d’utiliser le Gestionnaire de tables liées dans Access pour actualiser et lentement les tables. Pour plus d’informations, voir Gérer les tables liées.

Tester et réviser

Les sections suivantes décrivent les problèmes courants que vous pouvez rencontrer lors de la migration et comment les traiter.

Requêtes

Seules les requêtes Sélection sont converties ; Les autres requêtes ne le sont pas, y compris les requêtes Sélection qui prennent des paramètres. Il est possible que certaines requêtes ne se convertissent pas complètement et que SSMA signale des erreurs de requête pendant le processus de conversion. Vous pouvez modifier manuellement des objets qui ne sont pas convertis à l’aide de la syntaxe SQL texte. Des erreurs de syntaxe peuvent également nécessiter la conversion manuelle des fonctions et types de données spécifiques d’Access SQL Server utilisateurs. Si vous souhaitez avoir plus d’informations à ce sujet, consultez Comparaison d’Access SQL avec SQL Server TSQL.

Types de données

Access et SQL Server les types de données similaires, mais soyez conscients des problèmes potentiels suivants.

Grand numéro    Le type de données Grand nombre stocke une valeur numérique non monétaire et est compatible avec SQL type de données bigint. Vous pouvez utiliser ce type de données pour calculer efficacement des grands nombres, mais il nécessite l’utilisation du format de fichier de base de données .accdb Access 16 (16.0.7812 ou version ultérieure) et améliore les résultats avec la version 64 bits d’Access. Pour plus d’informations, voir Utiliser le type de données Grand nombre et Choisir entre les versions 64 bits et 32 bits d’Office.

Oui/Non    Par défaut, une colonne Oui/Non d’Access est convertie en SQL Server bits. Pour éviter le verrouillage d’enregistrement, assurez-vous que le champ bit est réglé pour empêcher les valeurs NULL. DANS SSMA, vous pouvez sélectionner la colonne bit pour définir la propriété Autoriser les valeurs Null sur NO. Dans TSQL, utilisez les instructions CREATE TABLE ou ALTER TABLE.

Date et heure    Il existe plusieurs facteurs de date et d’heure :

  • Si le niveau de compatibilité de la base de données est 130 (SQL Server 2016) ou une table liée contient une ou plusieurs colonnes datetime ou datetime2, la table peut renvoyer la #deleted de message dans les résultats. Pour plus d’informations, voir la table liée à la base de données Access et SQL-Server renvoie #deleted.

  • Utilisez le type de données Date/heure d’Access pour faire la carte du type de données datetime. Utilisez le type de données Date/heure étendue d’Access pour faire la carte au type de données datetime2 qui a une plage de dates et d’heures plus grande. Pour plus d’informations, voir Utiliser le type de données Date/heure étendue.

  • Lorsque vous recherchez des dates dans SQL Server, prenez en compte l’heure, ainsi que la date. Par exemple :

    • DateOrdered Between 1/1/19 and 31/19 may not include all orders.

    • DateOrdered Between 1/1/19 00:00:00 AM and 31/19 23:59:59 PM inclut toutes les commandes.

Pièce jointe   Le type de données Pièce jointe stocke un fichier dans la base de données Access. Dans SQL Server, vous devez envisager plusieurs options. Vous pouvez extraire les fichiers de la base de données Access, puis stocker des liens vers les fichiers de votre base de SQL Server données. Vous pouvez également utiliser FILESTREAM, FileTables ou RBS (Remote BLOB Store) pour conserver les pièces jointes stockées dans la base SQL Server données.

Hyperlink    Les tables Access sont des colonnes de liens hypertexte SQL Server ne sont pas prise en charge. Par défaut, ces colonnes sont converties en colonnes nvarchar(max) dans SQL Server, mais vous pouvez personnaliser le mappage pour choisir un type de données plus petit. Dans votre solution Access, vous pouvez toujours utiliser le comportement des liens hypertexte dans les formulaires et états si vous définissez la propriété Lien hypertexte du contrôle sur True.

Champ à plusieurs valeurs    Le champ à plusieurs valeurs Access est converti en champ SQL Server en champ ntext contenant l’ensemble de valeurs délimités. Étant donné que SQL Server ne prend pas en charge un type de données à plusieurs valeurs qui modélise une relation plusieurs-à-plusieurs, supplémentaires de conception et le travail de conversion peuvent être nécessaire.

Pour plus d’informations sur le mappage des types de données Access SQL Server données, voir Comparer les types de données.

Remarque    Les champs à plusieurs valeurs ne sont pas convertis et ont été arrêtés dans Access 2010.

Pour plus d’informations, voir Types de date et d’heure,Types de chaîne et binaireset Types numériques.

Visual Basic

Bien que VBA ne soit pas pris en SQL Server, notez les problèmes possibles suivants :

Fonctions VBA dans les requêtes    Les requêtes Access supportent les fonctions VBA sur les données d’une colonne de requête. En effet, les requêtes Access qui utilisent des fonctions VBA ne peuvent pas être SQL Server, aussi toutes les données demandées sont transmises à Microsoft Access à des fins de traitement. Dans la plupart des cas, ces requêtes doivent être converties en requêtes de conversion.

Fonctions définies par l’utilisateur dans les requêtes    Les requêtes Microsoft Access prisent en charge l’utilisation des fonctions définies dans les modules VBA pour traiter les données qui leur sont transmises. Les requêtes peuvent être des requêtes autonomes, des instructions SQL dans des sources d’enregistrement de formulaire/état, des sources de données de zones de liste déroulante et de zones de liste sur les formulaires, états et champs de table, ainsi que des expressions de règle par défaut ou de validation. SQL Server pouvez exécuter ces fonctions définies par l’utilisateur. Vous devrez peut-être reconverti manuellement ces fonctions et les convertir en procédures stockées sur SQL Server.

Optimiser les performances

De loin, le moyen le plus important d’optimiser les performances avec votre nouvelle SQL Server de niveau général consiste à décider quand utiliser les requêtes locales ou distantes. Lorsque vous migrez vos données vers SQL Server, vous migrez également d’un serveur de fichiers vers un modèle de base de données client-serveur de calcul. Suivez ces instructions générales :

  • Exécutez des requêtes de petite taille en lecture seule sur le client pour y accéder plus rapidement.

  • Exécutez de longues requêtes en lecture/écriture sur le serveur pour tirer parti de la puissance de traitement accrue.

  • Réduisez le trafic réseau avec des filtres et une agrégation pour transférer uniquement les données dont vous avez besoin.

Optimiser les performances dans le modèle de base de données du serveur client

Pour plus d’informations, voir Créer une requête s’insère.

Voici des recommandations supplémentaires.

Placer la logique sur le serveur     Votre application peut également utiliser les affichages, les fonctions définies par l’utilisateur, les procédures stockées, les champs calculés et les déclencheurs pour centraliser et partager la logique d’application, les règles et stratégies d’entreprise, les requêtes complexes, la validation des données et le code d’intégrité referentielle sur le serveur, plutôt que sur le client. Posez-vous la question : cette requête ou tâche peut-elle être exécutée sur le serveur de façon plus rapide et plus rapide ? Enfin, testez chaque requête pour garantir des performances optimales.

Utiliser les affichages dans les formulaires et les états    Dans Access, vous pouvez :

  • Pour les formulaires, utilisez un SQL en lecture seule pour un formulaire en lecture seule et un SQL indexé pour un formulaire en lecture/écriture comme source d’enregistrement.

  • Pour les états, utilisez une vue SQL comme source d’enregistrement. Toutefois, créez un affichage distinct pour chaque rapport afin de mettre à jour plus facilement un rapport spécifique, sans avoir d’autres impacts sur les autres rapports.

Réduire le chargement des données dans un formulaire ou un état    N’affichez pas les données tant que l’utilisateur ne les a pas demandés. Par exemple, gardez la propriété source d’enregistrement vide, faites en sorte que les utilisateurs sélectionnent un filtre sur votre formulaire, puis remplissez la propriété de source d’enregistrement avec votre filtre. Vous pouvez également utiliser la clause where de DoCmd.OpenForm et DoCmd.OpenReport pour afficher les enregistrement(s) exact(s) nécessaires par l’utilisateur. Envisagez de couper la navigation entre les enregistrement.

Soyez prudent avec des requêtes hétérogènes   Évitez d’exécutez une requête qui combine une table Access locale SQL Server table liée, parfois appelée requête hybride. Ce type de requête nécessite toujours qu’Access télécharge toutes les données SQL Server sur l’ordinateur local, puis exécute la requête. Elle n’exécute pas la requête dans SQL Server.

Quand utiliser des tables locales    Envisagez d’utiliser des tables locales pour les données qui changent rarement, telles que la liste des états ou des membres d’un pays ou d’une région. Les tableaux statiques sont souvent utilisés pour filtrer et peuvent être plus performants sur le plan frontal d’Access.

Pour plus d’informations, voir Assistant Paramétrage du moteur de base de données,Utiliser l’Analyseur de performances pour optimiser une base de données Accesset optimiser les applications Access liées Microsoft Office auxSQL Server.

Voir aussi

Guide de migration de base de données Azurehttp://datamigration.microsoft.com/

Blog sur la migration des

Microsoft Access to SQL Server Migration, Conversion and Upsizing

Méthodes pour partager une base de données de bureau Access

Besoin d’aide ?

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoindre Microsoft Office insiders

Ces informations vous ont-elles été utiles ?

Dans quelle mesure êtes-vous satisfait(e) de la qualité de la langue ?
Qu’est-ce qui a affecté votre expérience ?

Nous vous remercions de vos commentaires.

×