Lier un fichier Access accdb à une base SQL Server

Hello les Docteurs SQL !

Je viens de me préparer une nouvelle installation sur PC portable avec

• Windows 10,
• MS SQL Server Developer 2019,
• MS SS Management Studio v18.5
• MS SS Migration Assistant for Access v8.10.0
• Access Runtime 2016
• Office Enterprise 2007 (32bits..., je n'ai rien d'autre sous la main)
• Je n'y ai pas encore installé SQL Server Express

Sur ce dispositif, la migration des Tables accdb 2007 avec SSMA vers une mdf fraîche SQL Server se passe très bien. C'est plus rapide que l'importation de données via SSMS Server Express. Les Tables obtenues semblent propres (pas de SSMA_TimeStamp, par exemple).

Question :

Quelle est selon vous la meilleure méthode pour lier ces tables SQL Server dans un nouveau fichier accdb vide ?

J'ai essayé

1- A partir de SS Management Studio

• Tâches
• Exportation de données
• Source : SQL Server Native Client 11.0
• Destination : Microsoft Access DB Engine
• Copy Data
  Problème : Triangle jaune : le type de données Mémo source est "nvarchar" incompatible avec le type de données destination "Long Text". Echec... La table résultante dans Access est vide... A quoi est du cet échec ??? Pourquoi Import Export Wizard n'harmonise-t-il pas automatiquement les types de données??? Les Tables accdb 2007 viennent de Tables plus anciennes mdb 2003, converties par Access 2007.

2- A partir d'Access : Link to ODBC Database

• Source de données fichier, File Data Source
  Cela fonctionnait bien sur une autre machine avec SQL Server Express pour aller chercher le fichier *mdf.dsn.
  Mais maintenant avec Developer 2019, le dsn me propose invariablement de lier ceci :
  
  
  Pièce jointe 569168
  Impraticable ! Pourtant ça devrait marcher comme avant ! Que se passe-t-il ?
  
  
• Source de données machine, Machine Data Source
  Je suis donc allé créer un nouveau driver nommé "test" (je ne sais pas si je m'exprime bien) selon les tutos en bas de page.
  
  Et là, ça marche !
  Les Tables obtenues sont correctes, complètes, et les Mémos ne sont pas tronqués...
  Simplement, elles sont encore une fois renommées dbo_* comme dans mon dernier post https://www.developpez.net/forums/d2...o-automatique/ mais c'est un écueil mineur.
  Cependant, je ne me voit pas créer un tel driver au moment de l'installation sur les machines des autres utilisateurs....

Voilà. Quel est votre avis ?

Existe-t-il vraiment une méthode 100% sûre que vous pourriez me recommander ???
Doit-on parfois se résoudre à d'horribles manipulations comme celle-ci : https://www.sqlservercentral.com/for...x-field-in-sql ?

A vous et merci !

phil


https://www.youtube.com/watch?v=HYsujwWgmJU
https://www.youtube.com/watch?v=tUiaK5fRH7k

Effectivement il faut nettoyer les scories....

Pour cela un petit programmes de migration peut être édité en VBA.

A +

Ok, on fait comme ça ! Données machine avec driver local, et loop vba pour renommer les Tables liées.

Frédéric, stp : comment interprètes-tu la liste aberrante que me donne à présent la source de données fichier ???

Encore merci !

A+

Citation:

---

Envoyé par harpyopsis

...
Frédéric, stp : comment interprètes-tu la liste aberrante que me donne à présent la source de données fichier ???

---

La liste n'est pas aberrante mais logique et vous la trouvez quelque peu gênante...
1) les objets tables dans le schéma "sys" sont des objets systèmes propriétaires (Microsoft) de type vues (TABLE_TYPE = VIEW).
2) les objets tables dans le schéma "INFORMATION_SCHEMA" sont des objets systèmes normalisées (norme SQL) de type vues (TABLE_TYPE = VIEW).
Le tout peut être remonté dans votre application Access... C'est pourquoi la liste présente TOUS les objets accessibles et non pas que les objets créés par l'utilisateur...

Cela résulte de la règle n°4 de Codd (créteurs des SGBD Relationnels). Une petite explication est données dans mon futur livre sur SQL :
Pièce jointe 569266

Ces vues (car il ne s'agit pas de tables permettent de décrire l'intégralité de la structure d'une base et facilite grandement la vie du développeur qui ne doit plus faire que des requêtes et rien d'autres (règle 0 de Codd).

A +

Oke, merci !

Donc si je comprends bien : toute Table liée dans un fichier accdb, est en fait une Vue...

C'est logique. Mais le dialogue de Access parle pourtant bien de Tables. D'où la confusion qui se maintient chez les béotiens comme moi.

Je dormirai moins bête ce soir ! Une vie ne suffirait pas à apprendre tout ce qu'il faudrait savoir ! :arf:

A+

NON, non.... pas tout à fait.
Une vue est un objet de la base de données pas de l'applicatif.
Access mélange applicatif et BD, d'ou votre confusion.
Dans Access, il n'existe pas de notion de vue à ma connaissances.
CREATE VIEW n'est pas une instruction reconnue par Access.
Access n'a que des tables et des objets de visualisation graphique des données.
Une vue est un objet logique de présentation non graphique (aucun affichage). Mais une vue permet de mieux organiser l'information. par exemple, pré établit de multiples jointures de tables entre elles, synthétiser des informations, agréger des calculs....

A +

Okay, merci beaucoup Frédéric...!

J'ai potassé hier soir, j'en étais encore à croire que Vue et Query étaient des synonymes ! Je me réveille un peu moins bête ce matin !

Entre Access et SQL Server on en arrive parfois à ne plus savoir où se trouvent réellement les données !

Voir l'exemple d'il y a quelques jours avec docmd.CopyObject et DoCmd.TransferDatabase acImport... Ainsi lorsqu'on veut permettre à l'utilisateur de gérer ses propres backups de tarifs anciens, il existe trente-six milles méthodes, mais quelle est la meilleure ??? (Ce sera pour plus tard !!!)

L'important maintenant est d'arriver à répliquer correctement les données entre les utilisateurs, puis avec l'hébergeur. On n'est pas rendus, single-handed !

Aujourd'hui j'attaque la réplication de fusion entre les DB de deux utilisateurs sur SQL Server par clef USB. Je potasse... Ca marchait si bien avec JRO sur Access 2000-2003...! Je posterai mes questions stupides sur un nouveau fil !

A+