Bonjour,
 
Je ne suis pas un export ACCESS, mais on m'a demandé d'étudier la faisabilité de différentes évolutions demandées par un client qui utilise une "application" ACCESS" (une base avec des formulaires et états, liées à une base avec des données)
 
donc j'aimerais bien avoir vos avis sur les évolutions demandées :
 
- Possibilité de faire des tris sur des états : Je sais que ce n'est pas possible de faire des tris sur un état (qui est une simple aperçu avant impression), donc je pense qu'il faut passer par un formulaire c'est bien ça ?
 
- Possibilité de faire des recherches sur une période : pas de problème, j'ai déjà fait cela sans problème
 
- Possibilité d'enregistrer manuellement (avec conservation de l'enregistrement automatique à la fermeture du formulaire) : actuellement, il y a un formulaire (fiche client) et si on modifie le contenu du formulaire, c'est automatiquement pris en compte dans les données. Il faudrait pouvoir faire les modifications, qui seraient toutes prises en compte si l'utilisateur clique sur une bouton "Enregistrer" ou si l'utilisateur ferme le formulaire.
 
- Permettre de travail en réseau : je pense que le client souhaite que plusieurs personnes puissent travailler en même temps sur l'outil, ce qui ne devrait pas poser problème si la base "programme" est disponible sur chaque poste, et que cette base "programme" est liée à une unique base "Données" située sur le réseau.
 
- Il y a une fonctionnalité (stats) qui plante car elle utilise une requête TRANSFORM/PIVOT pour avoir en champ des types de besoins spécifiques, et donc afficher un état avec des comptages de besoins spécifiques par année et moi, mais comme il y a un type de besoin spécifique qui n'est jamais utilisé, l'état cherche à afficher quelque chose qui n'existe pas. je ne sais pas si je suis bien clair. j'ai réussi à contourner le problème, en passant par plusieurs requêtes, et avec des jointes externes, pour avoir quoi qu'il arrive tous les besoins spécifiques, et ça marche, mais dans l'état, j'ai donc un 0 sur ce besoin spécifique, avec année et moi vide, il n'y a pas une meilleures solution (niveau requête ou état) pour avoir quelque chose de plus propre ?
 
Désolé pour toutes ces questions en vrac.
 
Merci d'avance à ceux qui auront le courage de me lire et répondre à mes questions et confirmer ou non mes interrogations
 

Le point "travail en réseau" va être problématique à mon sens, Access n'étant clairement pas un vrai sgbd, donc pas prévu pour travailler en réseau. Sous Access 2000, le nb de connexions en parallèle sur une même base était de 2. mais déjà qu'avec une apli en ASP + Access avec une seule connexion, c'était franchement pas stable Access est vraiment une grosse m.... et on fait largement mieux aujourd'hui gratuitement avec du Mysql ou du postgres + PHP par ex
 
Par ailleurs, dupliquer la base sur les x postes clients n'est pas une bonne solution à cause d'un nouveau pb : la synchronisation des bd entre elles...
 
Pour ton pb de requête qui plante, normalement, en faisant un inner join (équi-jointure), il ne devrait pas y avoir de pb puisque les enregistrements retournées se trouveront forcément dans les x tables impliquées par les jointures. A mon avis, ta fameuse requête doit être mal conçue...

Merci bien.
 
pour le travail en réseau, il faut que je teste, car comme je l'ai déjà dit, la partie application (formulaires, états, requêtes) est dans un .mdb, et la partie base de données (les tables) est dans un autre .mdb.
 
pour la requête qui plante, il y a déjà des inner join, il faut que je regarde cela en détail.