Lier les applications Access à SQL Server à la base de données Azure SQL (AccessToSQL)

Si vous souhaitez utiliser vos applications Access existantes avec SQL Server, vous pouvez lier vos tables Access d'origine aux tables SQL Server ou SQL Azure migrées. La liaison modifie votre base de données Access de sorte que vos requêtes, formulaires, rapports et pages d'accès aux données utilisent les données du serveur SQL Server ou de la base de données Azure SQL au lieu des données de votre base de données Access.

Liaison des tables Access et SQL Server

Lorsque vous liez une table Access à une table SQL Server ou SQL Azure, le moteur de base de données Jet stocke les informations de connexion et les métadonnées de table. En revanche, les données sont stockées dans SQL Server ou SQL Azure. Cette liaison permet à vos applications Access de fonctionner sur les tables Access même si les tables et données réelles se trouvent dans SQL Server ou SQL Azure.

Pour lier des tables

1. Dans l'Explorateur de métadonnées Access, sélectionnez les tables à lier.

2. Faites un clic droit sur Tables, puis sélectionnez Lier.

L'Assistant Migration SQL Server (SSMA) pour Access sauvegarde la table Access d'origine et crée une table liée.

Après avoir lié les tables, les tables de SSMA s'affichent avec une petite icône de lien. Dans Access, les tableaux apparaissent avec une icône "liée", qui est un globe avec une flèche dirigée vers elle.

Lorsque vous ouvrez un tableau dans Access, les données sont récupérées à l'aide d'un curseur clavier. Par conséquent, pour les tables volumineuses, toutes les données ne sont pas récupérées à la fois. Toutefois, lorsque vous parcourez la table, Access récupère des données supplémentaires si nécessaire.

Dissocier les tables Access

Lorsque vous dissociez une table Access à partir d'une table SQL Server ou SQL Azure, SSMA restaure la table Access d'origine et ses données.

Pour dissocier des tables

1. Dans l'Explorateur de métadonnées Access, sélectionnez les tables à dissocier.

2. Faites un clic droit sur Tables, puis sélectionnez Dissocier.

Liaison de tables à un autre serveur

Si vous avez lié les tables Access à une instance SQL Server, et que vous souhaitez ultérieurement modifier les liens vers une autre instance, vous devez lier à nouveau les tables.

Pour lier des tables à un autre serveur

1. Dans l'Explorateur de métadonnées Access, sélectionnez les tables à dissocier.

2. Faites un clic droit sur Tables, puis sélectionnez Dissocier.

3. Cliquez sur le bouton Reconnecter à SQL Server.

4. Connectez à l'instance de SQL Server ou SQL Azure à laquelle vous souhaitez lier les tables Access.

5. Dans l'Explorateur de métadonnées Access, sélectionnez les tables à lier.

6. Faites un clic droit sur Tables, puis sélectionnez Lier.

Mise à jour des tables liées

Si les définitions de table SQL Server ou SQL Azure sont modifiées, vous pouvez dissocier, puis lier de nouveau les tables dans SSMA à l'aide des procédures présentées précédemment dans cette rubrique. Vous pouvez également mettre à jour les tables à l'aide d'Access.

Pour mettre à jour des tables liées à l'aide d'Access

1. Ouvrez la base de données Access.

2. Dans la liste Objets, cliquez sur Tables.

3. Faites un clic droit sur une table liée, puis sélectionnez Gestionnaire de tables liées.

4. Cochez la case à cocher de chaque table liée que vous souhaitez mettre à jour, puis cliquez sur OK.

Problèmes de post-migration possibles

Les sections ci-dessous répertorient les problèmes susceptibles de survenir dans les applications Access existantes après la migration des bases de données d'Access vers SQL Server ou SQL Azure, et l'établissement de liens entre les tables, ainsi que les causes et les résolutions de ces problèmes.

Performances lentes avec des tables liées

Cause : certaines requêtes peuvent être lentes après la mise à jour pour les raisons suivantes :

• L'application dépend de fonctions qui n'existent pas dans SQL Server ou SQL Azure, ce qui oblige Jet à extraire des tables localement pour exécuter une requête Sélection.

• Les requêtes qui mettent à jour ou suppriment de nombreuses lignes sont envoyées par Jet en tant que requête paramétrable pour chaque ligne.

Résolution : convertissez les requêtes en cours d'exécution lente en requêtes directes, procédures stockées ou vues. La conversion en requêtes directes présente les problèmes suivants :

• Les requêtes directes ne peuvent pas être modifiées. La modification du résultat de la requête ou l'ajout de nouveaux enregistrements doit se faire d'une autre manière, par exemple en ayant des boutons explicites de modification Modify ou d'ajout Add sur votre formulaire lié à la requête.

• Certaines requêtes nécessitent une entrée utilisateur, mais les requêtes directes ne prennent pas en charge l'entrée utilisateur. L'entrée de l'utilisateur peut être obtenue par un code Visual Basic pour Applications (VBA) qui demande des paramètres. Elle peut aussi être obtenue par un formulaire qui est utilisé comme contrôle d'entrée. Dans les deux cas, le code VBA envoie la requête avec l'entrée utilisateur au serveur.

Les colonnes d'incrément automatique ne sont pas mises à jour tant que l'enregistrement n'est pas actualisé.

Cause : après avoir appelé RecordSet.AddNew dans Jet, la colonne d'incrément automatique est disponible avant la mise à jour de l'enregistrement. Il n'en est pas de même pour SQL Server ou SQL Azure. La nouvelle valeur de la colonne d'identité est disponible uniquement après l'enregistrement du nouvel enregistrement.

Résolution : exécutez le code Visual Basic pour Applications (VBA) suivant avant d'accéder au champ d'identité :

Recordset.Update  
Recordset.Move 0,  
Recordset.LastModified  

Les nouveaux enregistrements ne sont pas disponibles

Cause : lorsque vous ajoutez un enregistrement à une table SQL Server ou SQL Azure à l'aide de VBA, si le champ d'index unique de la table a une valeur par défaut, et que vous n'affectez pas de valeur à ce champ, le nouvel enregistrement n'apparaît pas tant que vous n'avez pas rouvert la table dans SQL Server ou SQL Azure. Si vous essayez d'obtenir une valeur à partir du nouvel enregistrement, vous recevez le message d'erreur suivant :

Run-time error '3167' Record is deleted.

Résolution : lorsque vous ouvrez la table SQL Server ou SQL Azure à l'aide du code VBA, incluez l'option dbSeeChanges, comme dans l'exemple suivant :

Set rs = db.OpenRecordset("TestTable", dbOpenDynaset, dbSeeChanges)

Après la migration, certaines requêtes ne permettent pas à l'utilisateur d'ajouter un nouvel enregistrement

Cause : si une requête n'inclut pas toutes les colonnes qui sont comprises dans un index unique, vous ne pouvez pas ajouter de nouvelles valeurs à l'aide de la requête.

Résolution : vérifiez que toutes les colonnes incluses dans au moins un index unique font partie de la requête.

Vous ne pouvez pas modifier un schéma de table liée dans Access

Cause : après la migration de données et la liaison de tables, l'utilisateur ne peut pas modifier le schéma d'une table dans Access.

Résolution : modifiez le schéma de table à l'aide de SQL Server Management Studio, puis mettez à jour le lien dans Access.

La fonctionnalité lien hypertexte est perdue après la migration des données

Cause : après la migration de données, les liens hypertextes dans les colonnes perdent leurs fonctionnalités et deviennent des colonnes nvarchar(max) simples.

Résolution : Aucun.

Certains types de données SQL Server ne sont pas pris en charge par Access

Cause : si vous mettez à jour ultérieurement vos tables SQL Server ou SQL Azure pour contenir des types de données qui ne sont pas pris en charge par Access, vous ne pouvez pas ouvrir la table dans Access.

Résolution : vous pouvez définir une requête Access qui retourne uniquement ces lignes avec les types de données pris en charge.

Voir aussi

Migration de bases de données Access vers SQL Server