Discussion :

[lesept]

Bonjour

Je dois faire une synthèse ou une requête prenant des données sur plusieurs bases de données Access. A priori, ces bases seront dans le même répertoire. Est-ce possible ?
Faut-il concaténer les différentes bases en une seule plus grosse (même temporairement) pour ensuite faire la synthèse ou les requêtes sur cette grosse base, ou bien est-il possible avec une seule synthèse / requête de collecter et assembler les données des diverses bases ?

Merci de votre aide.

[tee_grandbois]

bonsoir,
inutile de regrouper les bases il est possible d'attacher les tables à la base où se trouve la requête (onglet Données externes) ou bien appeler la table directement en Mode création via l'affichage en mode SQL :

Code :

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

SELECT * FROM [MS Access;Database=C:\mabase1.accdb].Table1;

[PipoWIL]

intéressant. Merci. Je ne savais pas qu'il est possible d'écrire le lien vers une autre base directement dans le statement SQL.
Par contre, je trouve que la première solution, attacher les tables, offre deux avantages :

• le lien vers la table éloignée est visible sur l'écran. L'icône avec la petite flèche est explicite.
• écrire un statement SQL avec la syntaxe correcte n'est pas facile

Ces deux avantages rendront plus facile la maintenance de la base Access avec des tables liées. Si un collègue doit reprendre votre base Access dans six mois, il dégustera si vous avez écrit le lien directement dans le statement SQL !

[lesept]

Merci de toutes ces infos. Je vais tester.

[lesept]

Mon problème est finalement plus compliqué que je le pensais (notez bien que je suis un noob de base). J'ai pour l'instant une base "simple" avec plusieurs tables et requêtes. Elle fonctionne comme je le veux. Mais le problème est que cette base doit être renseignée par plusieurs personnes, et probablement de manière concurrente. Je ne dispose pas des licences qui permettent de faire ça.

Donc, l'idée est de créer une base pour chaque personne, et de faire porter mes requêtes sur les tables de ces diverses bases.

Je commence par tester avec une première requête. Voici la vue de la requête :



J'ai créé pour l'instant 3 bases temporaires contenant les tables que vous voyez sur le vue ci-dessus (j'en aurai plus de 10 dans la version finale !). J'ai attaché ces 3 bases dans ma base globale avec l'onglet Données externes. Je vois les liens et les petites flèches bleues.
Il faut maintenant créer la requête qui fera la même chose que la précédente, mais en allant chercher les infos dans les 3 bases. Là, je sèche "grave" : pouvez-vous m'aider ? Faut-il que j'uploade les bases ?

[tee_grandbois]

bonjour,
si les tables sont dans une seule base (on l'appelle dorsale) c'est plus simple mais elle de doit contenir que les tables.
Ensuite, pour chaque utilisateur il faut créer une bases frontale ne contenant que les objets "programmes" (requêtes, IHM , états ...) et y attacher les tables dont il a besoin.
Tu dis que les bases sont dans un seul répertoire, mais tu ne précises pas si ce répertoire est partagé.
J'espère que c'est le cas sinon ce ne sera pas simple à mettre en place car les données de la dorsale doivent être accessibles à tous.

[lesept]

Merci de ta réponse. Je dois dire que c'est dur pour moi qui ai peu d'expérience.

Le répertoire est en effet partagé. Si je comprends bien, le mieux serait que toutes les tables soient dans une seul base "dorsale". Mais si plusieurs personnes écrivent dans cette base de manière concurrente, ça ne fonctionnera pas, exact ?
C'est pour régler ce problème d'accès concurrent que je pensais faire plusieurs bases frontales, chacune renseignée par une personne. Faut-il faire une première requête qui copie l'ensemble des données dans une base dorsale, puis une autre qui fait la requête proprement dite qui génère le rapport ?
Ou bien, chaque utilisateur utilise sa base frontale qui renseigne la dorsale, sur laquelle je ferai ensuite mes requêtes ?

[tee_grandbois]

Bonjour,
Avec une seule dorsale, cela fonctionnera si plusieurs personnes sont connectées mais il faut pouvoir gérer les accès concurrents et les verrouillages de tables et aussi d'enregistrements.

C'est pour régler ce problème d'accès concurrent que je pensais faire plusieurs bases frontales, chacune renseignée par une personne.

Dans ce cas, avec une seule dorsale si chaque personne travaille avec ses propres tables et pas celles des autres, il n'y aura pas d'accès concurrent: le problème est réglé. L'avantage c'est que toutes les tables sont accessibles pour générer le rapport.

[lesept]

Pour être sûr de bien comprendre, je reformule :

• Toutes les bases sont sur le même répertoire partagé,
• Chaque personne travaille sur sa frontale, sans jamais écrire dans la frontale d'un autre,
• La requête finale (pour générer le rapport ou faire des recherches) est faite sur une base dorsale,
• A priori, cette requête est faite lorsque tous les contributeurs ont terminé de renseigner leur frontale, donc pas de problème d'accès concurrent.

Est-ce correct ?

Maintenant, j'ai besoin de savoir comment organiser / articuler les frontales et la dorsale.

Les frontales :

• Lorsque chaque personne ouvre sa frontale, il va renseigner une table avec un formulaire qui ira chercher des données communes à tous. Faut-il que je mette ces données dans une base à part, sur le même répertoire partagé ? Ou bien je les mets dans des tables dans chaque frontale (ce qui me semble peu optimisé en cas de modification) ?
• La table renseignée par chaque utilisateur doit-elle faire partie de sa frontale ? Ou bien renseigne-t-il directement la dorsale (ce qui risque de provoquer des accès concurrents) ?

La dorsale :

• Est-elle temporaire, créée à partir des données des frontales lorsque je fais mes requêtes ? Ou bien faut-il la mettre à jour à chaque modification d'une frontale (ce qui me semble un peu lourd) ?
• Dans le premier cas, comment faire pour la créer ? En attachant les tables des frontales ?

Merci de ton aide...

[tee_grandbois]

j'avoue que je ne comprend plus et je veux être sûr que les données sont partagées ou non avant de répondre.
Actuellement, il y a plusieurs bases, donc plusieurs tables, sont-elles accessibles à tout le monde, ou bien chaque utilisateur ne peut accéder qu'à ces propres tables via sa propre base ?
Car, ce que je lis ici n'est pas clair :

Lorsque chaque personne ouvre sa frontale, il va renseigner une table avec un formulaire qui ira chercher des données communes à tous.

Concernant les données communes à tous: s'agit-il de la configuration actuelle ou celle que j'ai proposée et qui peut lire et/ou écrire dans quelles tables ?
En clair : une table peut-elle être utilisée en écriture par plusieurs utilisateurs en même temps ?

[lesept]

Je me suis mal exprimé. Il faut savoir que pour l'instant je n'ai qu'une seule base prototype qui fonctionne pour une seule personne. J'ai la structure, les formulaires, les requêtes et les rapports. Je veux donc étendre ça à plusieurs utilisateurs, en veillant à ne jamais avoir d'écriture concurrente (car je pense qu'ils le feront tous au dernier moment, donc probablement en même temps).

Ma structure actuelle est une base avec plusieurs tables :

• Des tables contenant des données communes
• Une table que l'utilisateur renseigne avec un formulaire

Je cherche à faire une base par utilisateur, personnelle donc que personne d'autre que l'utilisateur ne pourra renseigner (la frontale). Cette base ira chercher des données communes dans une base partagée que chacun pourra lire quand il travaillera sur sa base frontale. Toutes les bases seront sur un même répertoire partagé.
Une fois que tous les utilisateurs auront renseigné leur base (de manière hebdomadaire), l'utilisateur final (disons "l'admin") ira sur une base "dorsale" qui interrogera les bases frontales des utilisateurs pour (j'imagine) faire un rapport ou répondre à des requêtes.

Donc aucune base ne sera en écriture en même temps par plusieurs utilisateurs. Plus précisément : aucune base ne sera en écriture par plusieurs utilisateurs.

[tee_grandbois]

Bonjour,
OK, mais une précision: une base frontale ne contient QUE des formulaire, Requêtes, Modules, Etats et les tables de la base dorsale attachées.
Si chaque utilisateur a sa propre base avec des tables personnelles, ce n'est plus une base frontale.

Cela dit cela fonctionnera si l'utilisateur final a accès par attachement à toutes les tables des bases utilisateur (A, B ...Z) ainsi que celles de la dorsale.
Si les tables de chaque base utilisateur portent le même nom, ce n'est pas un problème car Access les suffixe avec un nombre et il est possible aussi de les renommer pour leur donner un nom plus explicite (en évitant quand même les espaces, les caractères réservés ou les lettres accentuées)

[lesept]

Je ne comprends plus...

Si les bases frontales ne contiennent pas de table personnelle, où sont stockées les données renseignées avec le formulaire ?

[tee_grandbois]

Je ne comprends plus...

Si les bases frontales ne contiennent pas de table personnelle, où sont stockées les données renseignées avec le formulaire ?

petit rappel :
dorsale = données
frontale = programmes + tables attachées de la dorsale

dans un système de dorsale et frontale, il n'y a pas, dans l'absolu, de "table personnelle" (d'ailleurs, je dirais "table interne") sauf pour gestion des objets programmes: paramètres, données temporaires ...) puisque la finalité est de mutualiser les données pour éviter des redondances et faciliter l'accès à ces données à tout le monde. Les tables peuvent se trouver dans une seule base ou plusieurs si la totalité des données peut dépasser 2Go.

Les frontales ont pour but d'accéder aux données partagées: c'est plus simple pour mettre à niveau des objets "programmes" contenus dans une base frontale car elle peut être écrasée par une nouvelle version puisqu'elle ne contient pas de données.

Dans ta configuration, si les tables personnelles ne se font pas concurrence (c'est à dire que chaque utilisateur ira écrire dans sa propre table et si les tables ne portent pas le même nom), elles peuvent très bien se trouver dans la dorsale.

[lesept]

Merci de toutes ces réponses, mais je ne comprends toujours pas : si chaque utilisateur écrit ses données dans une table personnelle (donc toutes ces tables auront un nom différent) de la dorsale, et que deux utilisateurs le font au même moment, il y aura un conflit d'accès à la dorsale et on risque d'avoir des données perdues ?

Est-ce que ce schéma est correct du coup ?

[madefemere]

Bonjour,

Je me permets de m'incruster dans l'échange parce que je pense lesept que tu commences dans Access et as peur de ne pas bien faire.
Comme expliqué par tee_grandbois, normalement une application Access peut s'utiliser en mode multi-utilisateurs avec :
- une base dorsale (avec les tables de données) sur un serveur ou un répertoire partagé du réseau.
- des frontales (avec les formulaires, requêtes, états, code..) pour chaque utilisateur installés sur chaque poste ou un domaine réservé pour chacun sur le serveur.
Pour les accès concurrents sur les tables, cela ne pose pas de problèmes si nous avons entre 5 à 20 utilisateurs (Normalement Access les gère correctement). Le verrouillage peut se gérer au niveau des tables ou des formulaires (Il y a des gens qui utilisent des applications Access avec plus d'utilisateurs, mais je ne conseille pas trop).

Tu as des discussion sur le sujet :
https://www.developpez.net/forums/d3...rrents-access/
ou plus loin : https://www.developpez.net/forums/d2...s-concurrents/
plus récent : https://www.developpez.net/forums/d1...-tables-liees/

Bonne continuation

[lesept]

Merci madefemere. En effet, je veux être sûr de ce que je fais avant de me lancer dans le codage sous Access. Je vais lire ça et revenir vers vous...

[tee_grandbois]

bonsoir,
madefemere

[lesept]

Bonjour
J'ai un peu avancé dans ma démarche. J'ai construit 3 bases frontales pour l'instant et une dorsale et je cherche à faire une première requête qui cherche un mot dans les frontales.
Voici la requête en SQL (sur 2 bases pour l'instant) :

Code :

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

1
2
3
4
5
6
7
8
SELECT ReportingL3S.DateInfo, ReportingL3S.Info, ReportingL3S.Confidentiel, Labos.NomLabo
FROM Labos INNER JOIN ReportingL3S ON Labos.IdLabo = ReportingL3S.RefLabo
WHERE (((ReportingL3S.Info) Like"*" & [Caractères cherchés :] & "*") AND ((Labos.IdLabo)=[ReportingL3S].[RefLabo]))
UNION ALL
SELECT ReportingLCE.DateInfo, ReportingLCE.Info, ReportingLCE.Confidentiel, Labos.NomLabo
FROM Labos INNER JOIN ReportingLCE ON Labos.IdLabo = ReportingLCE.RefLabo
WHERE (((ReportingLCE.Info) Like"*" & [Caractères cherchés :] & "*") AND ((Labos.IdLabo)=[ReportingLCE].[RefLabo]))
ORDER BY ReportingL3S.DateInfo DESC;

Elle fonctionne (presque) parfaitement, et me renvoie les éléments de mes deux bases qui contiennent le mot recherché. Ma question porte sur le tri des données sélectionnées. J'arrive à trier par date croissante sur une seule des deux tables :

Code :

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

ORDER BY ReportingL3S.DateInfo DESC;

Mais je voudrais que le tri se fasse sur toutes les données sélectionnées et pas uniquement sur celles de cette table.

J'ai essayé diverses choses comme

Code :

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

ORDER BY ReportingL3S.DateInfo DESC, ReportingLCE.DateInfo DESC;

mais Base me répond que je ne peux pas faire ce tri :

L'expression ORDER BY (ReportingLCE.DateInfo) inclut des champs n'étant pas sélectionnés dans la requête. Seuls les champs requis dans la première requête peuvent être inclus dans une expression ORDER BY.

Que faire pour trier sur toutes les dates ?

[tee_grandbois]

bonsoir,
il me semble que dans une requête UNION c'est dans la première requête qu'il faut mettre tri.