Discussion :

[Barbrady]

Bonjour,

Je travail actuellement dans mon entreprise sur une nouvelle base de données Access et j'ai besoin d'exécuter certaines de mes requêtes SQL vers une autre base de données Access.

Voici un exemple de requête que je dois exécuter =>

BDD_01.mdb =>
Tables :
- table_01
- table_02

BDD_02.mdb =>
Tables :
- table_03

La requête SQL se trouvant dans BDD_01.mdb =>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
SELECT t1.nom_t1, t2.nom_t2, t2.date_t2, t3.date_t3
FROM table_01 AS t1, table_02 AS t2, table_03 AS t3 IN '\\127.0.0.1\mon\chemin\bdd\access.mdb'
WHERE t1.id_t1 = t2.id_t1
AND t2.id_t3 = t3.id_t3;

Avec ce type de requête, certains me diront d'utiliser les tables liées, mais non car les tables liées si on effectue une requête de sélection c'est beaucoup plus lent qu'un IN.
Apparemment Access se connecte, puis se déconnecte à chaque enregistrement lors d'une sélection de données sur une table liée.
Je préfère donc me connecter manuellement ayant eu l'expérience une fois (1h 50 minutes pour synchroniser des données via des tables liées ET <2 minutes avec une méthode de connexion manuel aux tables (requêtes SQL identiques))

Brèf.

Mon problème c'est que dans mon exemple j'ai à la fois des tables de ma BDD courante et d'autres sur une autre BDD.

Est-il possible de pouvoir faire mes jointures comme dans mon exemple plus haut en une seule requête SQL ?

Sinon je peux faire une sous requête avec du IN() mais bon ce n'est pas le top et encore difficile à gèrer car je ne pourrais pas extraire de champs car le SELECT sert de condition à la fonction IN(), sauf si je me trompe et qu'une méthode existe =>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
SELECT t1.nom_t1, t2.nom_t2, t2.date_t2
FROM table_01 AS t1, table_02 AS t2 
WHERE t1.id_t1 = t2.id_t1
AND t2.id_t3 IN(
SELECT t3.id_t3
FROM table_03 AS t3 IN '\\127.0.0.1\mon\chemin\bdd\access.mdb'
);

Ou encore le gèrer côté code VBA mais si je peux éviter aussi (si j'ai pas le choix on fera comme ça).

Quelqu'un aurait une solution à me proposer ?

N.B. : Je n'utilise pas : JOIN, INNER JOIN, LEFT / RIGHT JOIN car si on a plus d'une jointure sous Access c'est super chiant à imbriquer le tout. Surtout si on doit effectuer des modifications par la suite une fois l'application en test chez les utilisateurs.


Merci par avance de vos réponses.


Barbrady,

[Jean-Philippe André]

Bonjour,
bienvenue sur DVP
une idée de piste si tu estimes que tes données dans la table Table_3 ne sont pas modifiées en masse durant ton traitement:
- copier le contenu de la table "liée" en local

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * INTO Temp FROM table_3 IN '...'

- travailler sur la table Temp pour faire les jointures

[Barbrady]

Merci de ta réponse et désole de y répondre si tard.

Oui en effet cela peut-être une idée, et si j'en ai pas d'autres je pense l'adopter même si c'est pas le top mais bon, la situation l'oblige.

[alassanediakite]

Salut

Je préfère donc me connecter manuellement ayant eu l'expérience une fois (1h 50 minutes pour synchroniser des données via des tables liées ET <2 minutes avec une méthode de connexion manuel aux tables (requêtes SQL identiques))

Peux tu nous decrire l'environnement qui provoque cela.
J'ai une application (pour la comptabilité et le porte feuille d'une caisse d'épargnes et de crédits) à une journée de moi, dépuis 2 ans, 4 à 5 postes connectés sur une BD principale de taille actuelle un peu plus de 10 Mo: Pas de problème!
@+

[Barbrady]

L'environnement est :
- L'application en cours de développement sera sur chaque machines clientes (pas un simple raccourci sur le réseau)
- L'autre BDD qui en faite ne contient que des tables (archivée et purgée manuellement tous les mois à 2 mois dès qu'elle atteint 1 Go ; la personne qui s'en occupe anticipe largos les 2 Go d'Access) brèf.
Cette BDD est sur un serveur de fichier car elle accueil des tables pour tout un tas d'applications clientes.
Le tout orchestrée par des types de champs et clés primaires sur les tables qui ne se font pas ou qui s'évitent par exemple : clé composé de 2 champs en guise de clé primaire de type texte de 255 caractères * 2, bien entendu cela fonctionne et ce n'est pas interdit mais bon
- Plusieurs (> 10) connexions simultanées sur la même BDD qui est sur le réseau
- Mon entreprise connus de toutes personnes ou presque résidente en France travail encore sous Access avec une quantité de données faramineuses et malgré mes compétences dans d'autres SGBDR et langages de programmation je suis tenu de perpétuer la tradition de l'entreprise

------------------------------------

La douleur de l'application est de parcourir le réseau intranet à chaque fois sur une BDD bien pleine.

Dans cette application j'ai une fonction qui exécute 7 requêtes au maximum et une autre qui en exécute 5 avec des temps d'exécution de 1H50 chacune environ (j'ai le temps de vider la machine à café, de jouer au solitaire et de jouer au démineur , non je rigole).

Que dire de plus, à quand PHP par exemple dans mon entreprise car on a bien un SGBDR récent qui est Microsoft SQL Server mais aucune migration n'est prévu car il y a trop d'application à revoir (à la louche je dirais entre 50 - 100 applications) avec des tables liées etc... Donc un foutoir monstre.

[Tofalu]

Le IN est une clause de la requête et non une sous clause du FROM.

Donc à part passer par des sous requêtes, je ne vois pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
SELECT 
  TLOCAL.ID,
  TDISTANT.ID
FROM
 
  (
     SELECT  
       ID 
     FROM  
       TblTemp
  ) TLOCAL
 INNER JOIN 
  (
     SELECT 
       ID 
     FROM 
       Customers 
     IN 'c:\nwind.accdb'
  ) TDISTANT 
 ON 
  TDISTANT.ID=TLOCAL.ID

[Barbrady]

Impec cela fonctionne nikel !

En plus cette syntaxe je ne savais pas que c'était possible au niveau du FROM.