INSERT INTO de SQL SERVER vers ACCESS en ADO

* Bonjour *

Avec une seule requête ensembliste, sans passer par un recordset, très lent pour un gros import de données (je suis pas sûr que la requête soit beaucoup plus rapide puisque l'essentiel de la durée de l'import devrait être causé par la latence réseau et par l'écriture disque, mais j'aimerais vérifier quand même).

Je verrais bien une connexion classique puis un Execute :

Code:

---

1 2 3

Set CnADO = New ADODB.Connection CnADO.Open [chaîne de connexion ADO à la base Access] CnADO.execute [Requête SQL]

---

Sous SQL Jet, la syntaxe de cette requête devrait être la suivante :

Code:

---

1 2	INSERT INTO Table_Access (ChampsAccess) SELECT (ChampsSQLServer) FROM Table_SQLServer IN [chaîne de connexion SQL MS Jet à la base SQLServer ]

---

Je bute sur la séquence [chaîne de connexion base SQLServer] et je ne trouve aucun exemple.

Est-ce que ce mélange des genres est-il possible ?

Ou bien est-il préférable de lier la table SQL server et ensuite de faire le INSERT INTO ?

Ou bien, encore plus tordu, on crée une connexion OLEDB vers la base SQL Server et dans la requête INSERT INTO on utilise OPENDATASOURCE pour pointer vers la base Access. Bref on ouvrirait deux canaux pour un simple INSERT .....

* Merci d'avance *

aucun exemple ?

http://www.connectionstrings.com/

;)

Par contre ce mélange je ne sais pas si c'est possible...

Salut loufab,

Des exemples de connection strings, oui, mais dans le contexte évoqué, non (clause IN de Jet pour SQL Server)

Il n'y a pas d'exemple dans l'aide pour le IN dans un contexte ODBC (je suis sur 2010 en Tech Prev et l'aide ne fonctionne plus :( )
Mais il se peut effectivement que le IN soit revervé à une utilisation FULL JET.

Citation:

---

Ou bien est-il préférable de lier la table SQL server et ensuite de faire le INSERT INTO ?

---

Je ne sais pas si ça va être vraiment plus rapide :?

L'avantage du recordset reste que dans la boucle il est possible de rendre la main avec doevents et de gérer l'affichage pour faire patienter l'utilisateur.

Tof désactive l'aide online en 2010. ça devrait refonctionner. ;)

Bonsoir,

Citation:

---

Envoyé par FMJ

Salut loufab,
Des exemples de connection strings, oui, mais dans le contexte évoqué, non (clause IN de Jet pour SQL Server)

---

Voir ici : clause IN
Exemple :

Code:

---

1 2	SELECT CLI.* FROM Clients As CLI IN "" [ODBC;DRIVER=SQL Server;SERVER=NomServeurSQL;DATABASE=NomBDDSqlServer;Trusted_Connection=Yes];

---

Mais ça reviens à avoir une table liée ODBC.
En moins souple car je ne peux pas préciser le schéma SQL Server de la table SQL Server (le propriétaire de la table).

Il y a une durée qui est incompressible : c'est le transfert des enregistrements à travers le réseau.
Là où ou peut gagner du temps, c'est si on ne veut qu'une petite partie des enregistrements d'une table SQL Server.
Dans ce cas on a tout intérêt à faire exécuter la requête de sélection par SQL Server.
Ça peut se faire via ...

• un recordset ADO dont la source est une instruction SQL Server (Transac-SQL), avec des restrictions dans le WHERE.
• un recordset ADO dont la source est procédure stockée SQL Server paramétrée
• une requête Access de type SQL-Direct (ODBC).
  Cette requête pourra servir de source (FROM) à ta requête INSERT INTO
• ...

Sinon, si je dois utiliser toutes les données d'une table SQL Server, sans restrictions, j'importe la table avec DoCmd.TransferDatabase.

A+

Merci à vous

Je teste et fais un retour.