Discussion :

[Galateo]

Bonjour à tous



Pour poser le contexte, et comprendre mon questionnement :
Je viens d’arriver dans une boite pour quelques mois, on me demande de programmer en VBA sous Access, une « appli » qui donne des infos récoltées sur les tables d’une autre application (Great Plains) qui tourne sur un serveur SQL, GP ne retourne pas les informations qu’il faut apparemment, ou du moins, tout est en vrac, il n’y pas les bons traitements, nécessité de faire du copier/coller sous Excel et même rajouter directement des infos manuellement, bref, c’est pas génial génial. Ils disposent déjà d’un fichier Access avec des formulaires et des requêtes Access (pas de VBA), le tout sur un lecteur, et donc le même fichier partagé par tous les utilisateurs (humm), fichier qui fait dans les 50 Mo, et le tout serait lent (pas encore pu tester sur place). De plus, un autre problème se pose : pour pouvoir accéder a ce fichier Access, les administrateurs doivent donner l‘accès en lecture à la BD de Great Plains pour chaque utilisateur, ce qui semble déranger. Sachant aussi que je découvre les particularités de VBA (connaissant plus la prog sous VB, C, Java..) bref, ce genre de programmation « légère » (et encore, plus je découvre VBA, plus je m’aperçois que c est plus un préjugé qu’autre chose, du moins pour un certain type d’appli) me laisse un peu dubitatif, mais bon, j’ai quand même l’impression que ca va faire le boulot, quant à Access, je connaissais un peu

1 - Les tables liées par ODBC : Access télécharge t’il la totalité des tables sur le poste client?

Si non (je me doute bien que non par défaut, le contraire serait surprenant) :
2- Existe-t-il une différence entre une requête (sur ces tables) Access (donc enregistrée comme query dans le fichier Access) et une requête dans une variable string dans du VBA (résultat avec des recordset…)? Par différence, je parle en termes de performance sur le réseau, taille du fichier Access? Car quand certains formulaires sont lancés, on a vraiment le temps d’aller faire un tour prendre un kawa

3 – la solution (rajouter du VBA est elle la bonne?) ou vaut il mieux continuer sur le fichier Access existant, en rajoutant des query Access? Ou carrément passer a du VB, ou tout autre langage? (ca risque d’être refusé)

4- Pour le problème d’accès des utilisateurs a la BD sur SQL server, existe-t-il une autre solution qui satisferait les admin de Great Plains?

5- Question plus spécifiquement VBA :
Admettons que j’ai une table avec nombre x de champs, en passant uniquement par VBA, je suis capable de récupérer le résultat d’une requête select dans un recordset, le résultat étant une liste d’enregistrement, pas de problème pour parcourir le recordset et accéder a chaque champs…..mais, voila, pour l’affichage, si je veux le faire pour un seul enregistrement, en affectant les valeurs d’un seul enregistrement à des boites de texte le représentant, c’est facile, par contre, si je veux afficher la liste entière? La solution des continuous form serait logique, et autant j’arrive a le faire en linkant une table ou une requête au formulaire, autant je n’arrive pas a trouver comment le faire avec seulement du VBA, et ce n’est pas faute d’avoir écumé les différentes faqs et le manuel que j’ai…ca doit pourtant être très facile….y a quelque chose qui a du m’échapper, si quelqu’un avait un bout de code sous la main pour exemple…??


Bref, si de bons samaritains (version VBA geek ) parmi vous avaient des réponses ou des pistes, sur une ou toutes mes questions, ce serait très apprécié, merci d’avance!!!!

[marot_r]

Bonjour à tous
1 - Les tables liées par ODBC : Access télécharge t’il la totalité des tables sur le poste client?

Non, heureusemnet mais lors de certaines requêtes qui comportent des jointures cela peut se produire. Il faut se rappeler que en Access le gros du travail est fait par le poste du client. La BD est généralement seulement un réservoir de données.

2- Existe-t-il une différence entre une requête (sur ces tables) Access (donc enregistrée comme query dans le fichier Access) et une requête dans une variable string dans du VBA (résultat avec des recordset…)? Par différence, je parle en termes de performance sur le réseau, taille du fichier Access?

Oui et non, cela dépend. J'ai plusieurs applications qui tournent très bien en utilisant des requêtes Access et d'autres où c'est l'enfer et seul du SQL dans le code donne des résultats satisfaisant.

Pour le moment je te conseille de garder les requêtes telles qu'elle sont et d'y revenir quand tu aura fait les autres amélioration que je te suggère.

Car quand certains formulaires sont lancés, on a vraiment le temps d’aller faire un tour prendre un kawa

Le partage d'une BD sur le réseau peut provoquer cela, fait un essais en copiant ta BD en local.

3 – la solution (rajouter du VBA est elle la bonne?) ou vaut il mieux continuer sur le fichier Access existant, en rajoutant des query Access? Ou carrément passer a du VB, ou tout autre langage? (ca risque d’être refusé)

À priori tu n'as pas à changer de langage. Access vient vraiment avec un tas d'outil pour l'affichage et l'exploitation des données qu'il faut reprogrammer dans les autres langages.

Pour résoudre les pb de taille, il faut compacter ta base. Access à tendance à faire gonfler les bases. Personnellement j'en ai eu une qui est passé de 10Mo compactée à 100Mo non compactée après un certain nombre de modif que j'avais faites. Après un compactage, elle avait retrouver sa taille initiale.

Quelle version d'Access utilises-tu ? Certaines permettent de faire le compactage automatiquement en sortant.

4- Pour le problème d’accès des utilisateurs a la BD sur SQL server, existe-t-il une autre solution qui satisferait les admin de Great Plains?

C'est quoi le problème exactement ? Pour pouvoir extraire des données il faut forcément pouvoir lire dans la BD. Moi, j'ai des bases Oracle avec des liaisons ODBC et j'ai accès à mes données mais pas aux fichiers physique de la BD.

5- Question plus spécifiquement VBA :
Admettons que j’ai une table avec nombre x de champs, en passant uniquement par VBA, je suis capable de récupérer le résultat d’une requête select dans un recordset, le résultat étant une liste d’enregistrement, pas de problème pour parcourir le recordset et accéder a chaque champs…..mais, voila, pour l’affichage, si je veux le faire pour un seul enregistrement, en affectant les valeurs d’un seul enregistrement à des boites de texte le représentant, c’est facile, par contre, si je veux afficher la liste entière? La solution des continuous form serait logique, et autant j’arrive a le faire en linkant une table ou une requête au formulaire, autant je n’arrive pas a trouver comment le faire avec seulement du VBA, et ce n’est pas faute d’avoir écumé les différentes faqs et le manuel que j’ai…ca doit pourtant être très facile….y a quelque chose qui a du m’échapper, si quelqu’un avait un bout de code sous la main pour exemple…??

Plutôt que d'utiliser du code, utilise un formulaire lié à ta table ou ta requête Access.

Le formulaire lié fait cela pour toi sans que tu ai une seule ligne de code à écrire et Access vient avec des assistants qui te guide pas à pas pour la création de tel formulaire.

A+

[Galateo]

Le partage d'une BD sur le réseau peut provoquer cela, fait un essais en copiant ta BD en local.

Le fait est, qu'il n'y pas de BD local, tout se trouve sur un BD distance sous SQL Server, Access ne servant qu'à construire les requêtes et pour la présentation.

À priori tu n'as pas à changer de langage. Access vient vraiment avec un tas d'outil pour l'affichage et l'exploitation des données qu'il faut reprogrammer dans les autres langages.

C'est ce dont je m'aperçois, même si je trouve encore un peu frustrant de ne pas pouvoir tout contrôler comme avec un langage classique(illusion???)

Pour résoudre les pb de taille, il faut compacter ta base. Access à tendance à faire gonfler les bases. Personnellement j'en ai eu une qui est passé de 10Mo compactée à 100Mo non compactée après un certain nombre de modif que j'avais faites. Après un compactage, elle avait retrouver sa taille initiale.

Justement, le problème est la, il n'y pas de base de données en local comme mentionné plus haut, et j'ai du mal a croire que des formulaires et des requêtes puissent faire le 50 Mo, à moins qu'une option soit activée quelque part pour mettre en cache certaines tables de la BD distante ou les tables produites par les requêtes...possibilité???

Quelle version d'Access utilises-tu ? Certaines permettent de faire le compactage automatiquement en sortant.

Version 2003

C'est quoi le problème exactement ? Pour pouvoir extraire des données il faut forcément pouvoir lire dans la BD. Moi, j'ai des bases Oracle avec des liaisons ODBC et j'ai accès à mes données mais pas aux fichiers physique de la BD.

Le problème est plutôt "humain", les admins de la BD distante sont dans un autre département à l'autre bout de la ville, donc aucun contact direct qui faciliterait les choses, et apparament, il rechignent à autoriser l'accès à la BD distante(en lecture seulement) à chaque utilisateur(le compte Windows sur le domaine) qui devrait accéder à l'appli Access, ce qui fait que le nombre de personnes qui peuvent l'utiliser pour le moment est très restreint, et on me demande s'il n'y aurait pas une solution pour permettre a plus de personnes de pouvoir utiliser les outils développés, sans devoir demander l'accès pour chacun. Bref, un mélange de paranoïa, de guerre de clochers, et de désorganisation

Plutôt que d'utiliser du code, utilise un formulaire lié à ta table ou ta requête Access.

Le formulaire lié fait cela pour toi sans que tu ai une seule ligne de code à écrire et Access vient avec des assistants qui te guide pas à pas pour la création de tel formulaire.

ça j'avais déjà vu, et je ne comptais pas réinventer la roue pour des requêtes de base, par contre, j'en aurais certaines qui demandent un traitement, des calculs, et des choix, et et je ne sais pas trop encore comment je vais m'y prendre, puisque j'aimerais simplement pouvoir insérer mon vecteur d'enregistrement(qui aura été traitée au préalable) dans une datasheet quelconque pour l'afficher à la fin du processus, ce qui se fait facilement dans d'autres langages, mais là, je sèche. Et comme le vecteur peut être de taille variable, impossible de prévoir un formulaire statique.



En tout cas, merci beaucoup d'avoir pris le temps pour me répondre!!!!

[marot_r]

Quand je parle de base en local, je parle de ta base Access qui est partagée entre plusieurs utilisateurs et qui est sur le serveur. Je t'invite donc à copier cette base sur ton poste client et de faire un test.

A+

[Galateo]

Quand je parle de base en local, je parle de ta base Access qui est partagée entre plusieurs utilisateurs et qui est sur le serveur. Je t'invite donc à copier cette base sur ton poste client et de faire un test.

A+

Déjà fait, ça améliore un peu les performances pour certaines requêtes, mais l'essentiel du problème, je crois l'avoir découvert, en regardant de plus la structure des requêtes qui avaient deja été faites, je me suis aperçu, qu'il y'en avaient certaines qui en appelaient plusieurs autres, et en cascade sur plusieurs niveaux..d'autant que plusieurs de ces requêtes, en appellent d'autres, pour ne récupérer qu'un champs....autant dire qu'on est loin de l'optimisation

[marot_r]

Alors à propos de ton accès à la BD SQL, un solution simple serait d'avoir un utilisteur 'Lecteur' qui permettrait de se connecter à la base. Tous tes utilisateurs seraient des 'Lecteur' sans avoir besoin de les identifier individuellement. Cet utilisteur peu être défini dans la chaîne de connexion.

L'autre solution serait d'avoir l'appuis d'un Big Boss dans ton projet pour 'imposer' tes besoins aux responsables de la BD SQL.

À propos de tes résultats à structure variable. Access gère assez mal ce genre de chose. Une BD Relationnelle c'est supposée avoir une structure fixe et fournir des résultats à structure fixes.

Si tes résultats sont obtenu à partir d'une requête tu pourrais demander à Access d'afficher la requête plustôt qu'un formulaire. Tu n'aurais aucun contrôle sur le comportement de l'objet (pas de procédure événementielle ou autre) mais cela te permettrait d'avoir simplemement une structure variable.

Tu peux aussi par programme modifier la structure d'une table donc tu pourrais créer une table qui aurait les champs dont tu as besoin puis en faisant un Select * from TaTable afficher cela comme une requête.

C'est un peu bricolo bricola mais ça va marcher.

Autre solution : afficher ton résultat dans un objet listbox.

Tu peux générer ta liste de façon dynamique. La source d'une liste peut être un chaine de caratère dont les élément sont séparés par des ";". En utilisant une liste de par exemple 100 colonnes et en définissant des colonnes de largeur 0 pour les colonnes inutilisées, tu peux obtenir un effet semblable à un GridControl.

A+

[Galateo]

Alors à propos de ton accès à la BD SQL, un solution simple serait d'avoir un utilisteur 'Lecteur' qui permettrait de se connecter à la base. Tous tes utilisateurs seraient des 'Lecteur' sans avoir besoin de les identifier individuellement. Cet utilisteur peu être défini dans la chaîne de connexion.

Aprés quelques essais, cette solution la fonctionne

L'autre solution serait d'avoir l'appuis d'un Big Boss dans ton projet pour 'imposer' tes besoins aux responsables de la BD SQL.

Je préfère m'en tenir à la solution de la chaine de connexion, c'est moins frustrant

Tu peux aussi par programme modifier la structure d'une table donc tu pourrais créer une table qui aurait les champs dont tu as besoin puis en faisant un Select * from TaTable afficher cela comme une requête.

C'est un peu bricolo bricola mais ça va marcher.

J’ai testé un peu cette solution, et quoiqu’un peu « bricolo bricola », ca a le mérite de faire ce que je veux

En tout cas, merci beaucoup pour ton aide, c’est vraiment gentil de ta part!