[XL-2003] Tableau qui se construit dynamiquement en fonction de données issues d'access [Résolu]

[Chagui]

Bonjour à tous,

Je me permets d'écrire ce messsage car j'ai besoin d'avoir des avis sur la marche à suivre concernant la mise en forme de données issu d'une base access. Access n'étant vraiment pas pratique pour restituer des données de facon simple, je me penche sur Ecxel qui est certainement plus apte pour cela.

La situation :

J'ai développé une application access qui fonctionne bien. Elle est en mode multi utilisateur. Un "manager" possède sa propre frontale et pilote l'activité des utilisateurs. Ce manager a besoin cependant de données précises mis en forme pour gérer efficacement l'activité.

Le besoin :

Besoin de mettre en place un tableau afin de restituer des données. Ce tableau doit être dynamique dans le sens ou en fonction de tris effectués (sur utilisateurs, sur régions...) la forme de celui ci doit s'adapter pour restituer les données. Ce tuto décris un peu mon besoin : (ICI)

Bien évidamment présenter cela via ce message est pas évident et je comprend que cela ne soit pas très clair...

Mes questions portent surtout sur la facon de procéder au niveau de l'extraction des données. Quelle est le moyen le plus adéquate pour exporter les données dans excel afin qu'elle soit mise à jour régulièrement et comment les traitées dans un tableau dynamique

Un tuto indique les différente possibilitées (ICI).


Quel est pour vous la technique la plus efficace concernant le traitement de données issu d'access avec maj ?

Merci pour votre aide

Cordialement

[Pierre Fauconnier]

Salut.

Les tableaux croisés dynamiques d'Excel représentent l'outil par excellence pour analyser des données Access.

Tu peux directement lier ton TCD à une source Access, ou passer par une feuille Excel Intermédiaire si tu as besoin de préparer tes données.

C'est à mon avis la façon la plus dynamique de gérer les données.

Que ce soit par TCD en direct sur une source Access (table ou requête) ou via une feuille Excel intermédiaire (via msquery, par exemple), une simple actualisation par clic droit rapatriera les données d'Access...

Tu peux également prévoir des actualisations de la source à l'ouverture et/ou selon une temporisation.

Bon travail.

[Chagui]

Bonjour Pierre,

Tout d'abord merci pour ta réponse .

Le TCD est la meilleure solution effectivement pour pouvoir mettre en forme les données. J'ai donc testé pour me familiariser avec, essayer de mieux cerner le fonctionnement.

J'ai lié directement une requete test afin de voir comment les données étaient rapatriées. D'apparence cela semble simple mais j'avoue que c'est bien plus compliqué que ca n'y parait... Ce que je ne comprend pas c'est que les relations des tables qui composent ma requete n'ont pas l'air d'etre correctement compris par le TCD.

Je m'explique : J'ai des données qui correspondent à un contrôle d'un dossier. Ces données remontent des incidences (documentaire -DOC- ; Non financière -INONFI- ; Financiere -IFI- ; Rsique financier -RFI-). Dans mon appli Access, des utilisateurs controlent des dossiers. Ils ont donc 4 formulaires de controle possible en fonction de la nature du dossier (1 seul form est appelé pour le contrôle). Chaque formulaire se compose de libellés qui décrivent un point du dossier à contrôler. Je souhaite dans mon TCB, remonter le nombre d'incidences rencontrées (nbre IFI, nbr IDOC, nbr RFI, nbr INONFI). J'y arrive sans soucis et ces infos sont également classées par régions. (dépend d'ou viennent les dossiers).

Là ou je ne comprend pas c'est que j'aimerai remonter les libellés qui correspondent aux incidences rencontrées.

EX : région Alpes ; 20 dossiers contrôlés ; parmis ces 20 dossiers Il y a eu 10 dossiers OK et 10 dossiers KO. Parmis les 10 dossiers KO il y a eu 8 IFI, 3IDOC, 5 RFI et 1 INONFI. (il peut y avoir plusieurs incidences par dossier). Je voudrais donc voir sur quel libellé a eu lieu l'incidence. Peut importe si ce libellé est répété (ex : 5IFI mais a chaque fois sur le meme libelle).

Le problème c'est que cela me ramène l'ensemble des libellés existants et non ceux correspondant seulement aux IFI, IDOC, INONFI, RFI. Je ne sais si ma description est claire. Je me demande donc si les relations qui existent dans les tables qui composent ma requete liée au TCD ne sont pas limitée.

Les relations existantes entre mes tables access sont-elles à modifier dans le moteur de requête msquery présent dans excel ?
Est ce que je dois travailler mes données sur une feuille intermédiaire ?

Merci de m'avoir lu, en espérant pouvoir mieux comprendre via vos futures explications.

Cordialement

Guillaume

ps : j'ai mis en fichier joint une capture de ma requête. Les IDlibptsctrl sont les ID des "Nom des libellés".

EDIT

En faite pour être plus clair, je voudrais pouvoir enlever dans le total les lignes qui correspondent à 0. Comme je disais j'ai tous les libellés qui remontent avec en total la plupart du temps 0. Ce qui m'interesse ce sont les ligne ou le total est = à 1 ou supérieur.

[Maxence HUBICHE]

Et ce tuto, tu l'as vu ?
http://access.developpez.com/index/r...ique-d-Access/

[Maxence HUBICHE]

A relire tout cela...
J'en reviens à Access.

1- tu fais une requête, dans Access qui te fournit toutes les données que tu veux, et seulement celles que tu veux.
2- tu fais ton TCD dans Access, comme cela tu n'auras pas à passer sans arrêt d'Access à Excel
Cela implique également que, le jour où tu n'auras plus envie de mettre cette base à cet endroit là précisément, tu auras toujours ton TCD valide, et tu ne sera pas obligé de le refaire pour te connecter à la source de données perdue. (par exemple ...)

[Pierre Fauconnier]

Salut Maxence,

L'option "Tout Access" n'est pas toujours un choix possible.

Si le TCD doit être :

• manipulé par une personne non connectée à la base pour diverses raisons (pas d'Access installé, pas de connaissances pour manipuler Access, pas envie, ...) ;
• envoyé pour analyse sans devoir transférer toute la base ;
• ...

l'option TCD d'Excel sera meilleure.

Sans compter que, personnellement, je ne suis pas fan des TCD d'Access. A la suite de ton tuto, je les ai proposés à différentes personnes qui m'ont vite demandé de leur réaliser les TCD en Excel car ils trouvaient l'interface plus convivial. Je n'en ai à ce jour pas trouvé une qui préférait Access...

[Maxence HUBICHE]

Salut Pierre !

Envoyé par Pierre Fauconnier

L'option "Tout Access" n'est pas toujours un choix possible.

Quel rapport avec cette question posée par Chagui ?

Envoyé par Chagui

Un "manager" possède sa propre frontale et pilote l'activité des utilisateurs. Ce manager a besoin cependant de données précises mis en forme pour gérer efficacement l'activité.

Donc cette solution est un "choix possible" et donc j'y réponds...

Alors quand tu dis:

manipulé par une personne non connectée à la base pour diverses raisons (pas d'Access installé, pas de connaissances pour manipuler Access, pas envie, ...) ;

cet argument ne tient pas, puisqu'il a Access, et je me demande donc pourquoi il vient là
De même pour les autres arguments !

envoyé pour analyse sans devoir transférer toute la base ;

C'est un argument fallacieux puisque le cache - stocké dans le fichier Excel - servant à créer le TCD contient toutes données.
Il est illusoire de penser qu'un TCD est "seulement" une image.
Qui plus est, encore une fois, quel est le rapport avec la demande de Chagui .
On dirait des argument pour contrer une fonctionnalité, pas pour répondre à la question de l'utilisateur... je ne comprends pas

personnellement, je ne suis pas fan des TCD d'Access.

Argument qui n'engage donc que toi... personnellement, j'en suis fan.

A la suite de ton tuto, je les ai proposés à différentes personnes qui m'ont vite demandé de leur réaliser les TCD en Excel car ils trouvaient l'interface plus convivial. Je n'en ai à ce jour pas trouvé une qui préférait Access...

Ca, c'est de la mauvaise foi, puisque le concept est identique.
Donc, qu'une méconnaissance puisse agir sur l'avis des personnes... d'accord... dommage, mais d'accord. Mais tout le reste n'est qu'impressions et ressentiments à l'égard d'un produit.
Et encore une fois, ce sont des avis tout personnels ! Moi, j'ai fait des émules avec ! J'ai même un gars qui a dit avoir arrêté d'utiliser Excel depuis qu'il a découvert le TCD sur Access. Alors ... quelle est la valeur de cet a priori que tu délivres ici ?

En tout état de cause, le TCD doit servir au manager, qui a une base Access sous la main ; et donc, faire du tout intégré est une solution non négligeable, évitant de switcher sans arrêt entre deux applications, permettant un développement plus aisé, etc.

Après que "parce que untel préfère ceci ou cela" on ne propose pas la solution la plus adapté à la demande me parait dommageable.

Pour finir, qu'est-ce qui empèche, si le besoin s'en fait sentir, de partager cette info, d'exporter ton TCD access sur Excel ? réponse : rien !

Donc, en tout état de cause, la solution TCD Access n'enlève rien, ajoute en souplesse, en puissance, en intégration, et en ouverture sur l'extérieur.
Bref... c'est Chagui qui fera lui-même son choix, puisque, maintenant, il l'a le choix.

[Pierre Fauconnier]

Salut Maxence,

Tu réponds à mes arguments "fallacieux" et mon ressenti par des arguments qui le sont tout autant et par ton ressenti.

Cela dit, j'ai juste dit ceci "L'option Tout Access ne sera pas toujours possible", en étayant mes propos, rien de plus, rien de moins, en apportant un éclairage sur les limites des TCD dans Access.

Je vais dons rester dans la généralisation (léger hs par rapport au strict sujet de la discussion).

C'est un argument fallacieux puisque le cache - stocké dans le fichier Excel - servant à créer le TCD contient toutes données.

Le cache contient les données qui sont ramenées dans Excel, ni plus ni moins, et tu peux donc n'avoir qu'une partie de toute la base Access.

Qu'il soit en frontal ou pas, s'il doit à un moment travailler en déconnecté (déplacements, ...), Excel lui offre un cache qu'Access ne lui offre pas.

c'est Chagui qui fera lui-même son choix, puisque, maintenant, il l'a le choix.

Bien sûr, je n'ai jamais rien dit d'autre.


Le reste de nos diatribes n'est, comme tu le dis très bien, que du ressenti.

[Maxence HUBICHE]

Envoyé par Pierre Fauconnier

Qu'il soit en frontal ou pas, s'il doit à un moment travailler en déconnecté (déplacements, ...), Excel lui offre un cache qu'Access ne lui offre pas.

Si si ! C'est prévu ... cela s'appelle la réplication de bases de données...
'est super efficace.
Cela marche très bien
Tu peux travailler en déconnecté
Tu peux récupérer les modifications faites par les autres quand tu veux, si tu veux, et cela peut même être configuré pour que tu ne récupères que les données qui te concernent (réplication partielle)

Donc, même cet argument n'est pas valide.

[Pierre Fauconnier]

Ok.

Restons tout de même pragmatiques...

Il me semble qu'implémenter une réplication de données pour pouvoir utiliser un TCD en Access en mode "déconnecté" avec mise à jour des données par la suite revient à utiliser un bazooka pour tuer une mouche.

En Excel, je réalise cela en moins d'une minute et la mise à jour se réalise en un clic. Je doute que la création d'une base répliquée et sa mise à jour soient envisageables de manière aussi simple.

De plus, la réplication n'est pas prise en charge sur les formats ACCDB, et je sais que tu vas me dire que la discussion est taguée 2003, il n'en reste pas moins vrai qu'en ma qualité de professionnel, je ne proposerai jamais une réplication de bases de données uniquement pour pouvoir présenter le TCD dans Access alors qu'il me semble si simple de pouvoir le créer en quelques clics en Excel...

[Maxence HUBICHE]

En restant pragmatique, si vraiment la personne est amenée à TRAVAILLER en déconnecté (tes arguments 2 postes plus haut) alors la seule solution qui soit ET professionnelle et fonctionnelle est la réplication...
Car avec un TCD, tu peux seulement ANALYSER des données embarquées dans un cache.
Pas TRAVAILLER.

En tant que professionnel, sur un tel sujet, je n'hésiterai pas.
Surtout au vu de la facilité de créer un réplica (quelques clics)
Mais, je me permettrai ce choix peut-être parce que, outre une très bonne conncaissance d'Excel, j'ai aussi une très bonne connaissance d'Access.

[EDIT]
Comparaison
OBJET --------------------EXCEL --------- ACCESS
(travail déconnecté)
Ajout de données---------non---------------oui
Suppressions--------------non---------------oui
Mise à jour-----------------non---------------oui
Consultation---------------oui*--------------oui
Analyse---------------------oui*--------------oui
Facilité de mise en place-5/5---------------4/5
(travail connecté)
Ajout de données---------oui#---------------oui
Suppressions--------------oui#---------------oui
Mise à jour-----------------oui#---------------oui
Consultation---------------oui#--------------oui
Analyse---------------------oui#--------------oui
Facilité de mise en place-5/5---------------4/5

pour moi, il n'y a pas photo...
pour à peine plus de difficulté de mise en place que pour une solution multi-produit ne permettant pas la manipulatin de données, je préfère avoir une solution qui fonctionne parfaitement et qui a toutes les fonctionnalités.
Et ce peu de difficulté supplémentaire m'apporte, en plus, une interface unifiée, une possibilité de développement d'application, de distribution le cas échéant etc.
Je signe direct !
C'est peut-être mon côté "pro" qui veut ça.

* oui après double-blic sur la cellule => création d'une nouvelle feuille (à détruire puisqu'inutile après cette "consultation". D'autre part, les données sont celles présentes dans le cache, et n'embarquent donc pas les modifications faites depuis, puisqu'il n'y a que le cache de disponible...
# besoin de basculer entre les deux applications Excel et Access. besoin de demander la mise à jour des données sur Excel dès qu'une modification a lieu dans Access
[/EDIT]
[RE-EDIT]
... ais-je oublié que pour mettre en place cette solution, je n'ai même pas besoin d'acheter une licence Access ?
il me suffit de créer un setup.exe (gratuitement avec les outils développeurs à télécharger sur microsoft.com) et d'y ajouter le Access runtime (gratuit également) ?
Alors que la solution Excel est payante... elle
Non seulement je suis pro techniquement, mais financièrement aussi. Notamment (puisqu'on est parti dans les théories) si je travaille avec une institution qui n'utilise que les google apps... par exemple
[/RE-EDIT]

[Pierre Fauconnier]

Chaque solution s'envisage au cas par cas.

Dans un cas, je proposerai les TCD en Access, dans un autre, je les créerai en Excel, et encore ailleurs, j'irai vers une solution avec runtime, setup et tout le toutim.

Quant à la "gratuité" de la solution embarquée en "tout Access sans licence avec runtime", elle ne tient pas compte du coût du développement et de la mise en place. Je doute que ce soit souvent moins cher qu'une licence Excel, mais soit.

Le côté "pro" se mesure à mon avis à la prise en compte de tous les paramètres particuliers d'une situation pour proposer LA solution, qui sera forcément différente pour chaque cas.

Perso, je termine ici, la discussion devient stérile.

[Maxence HUBICHE]

Envoyé par Pierre Fauconnier

Quant à la "gratuité" de la solution embarquée en "tout Access sans licence avec runtime", elle ne tient pas compte du coût du développement et de la mise en place. Je doute que ce soit souvent moins cher qu'une licence Excel, mais soit.

Côté Excel :
n* licences Excel + coût dev
Côté Access :
0 licence Access + coût dev

Y'a pas photo je pense, et plus le produit sera installé sur un nombre de postes important, plus j'y aurai gagné financièrement, quand bien même le coût développement aurait initialement été plus élevé...

Le côté "pro" se mesure à mon avis à la prise en compte de tous les paramètres particuliers d'une situation pour proposer LA solution, qui sera forcément différente pour chaque cas.

Aaaah ! On en revient donc à ce que je disais quelques postes plus hauts : Chagui fera son choix
Et ce n'est pas à nous de dire qu'une solution ne fera pas l'affaire - d'après nos seuls apriori - quand deux sont valables.

Perso, je termine ici, la discussion devient stérile.

Stérile ?
Non !!! Elle permet de mettre en lumière que, la plupart du temps, les arguments portés sur Access sont dûs à une méconnaissance (au sens "mauvaise connaissance") de ce produit, et qu'il y a bien des solutions pour faire AU MOINS aussi vite ET aussi bien ce qu'on fait dans Excel avec un logiciel qui est prévu pour !
Le vrai problème repose sur l'attachement de certains à des savoirs existants (je connais Excel et pas Access...), qui gèrent mal les priorités ("j'ai pas le temps", "c'est un travail urgent", ...) - et tout ceci pourrait être un autre débat

Mais, si tu souhaites arrêter ce débat, je te remercie de m'avoir permis de montrer l'intérêt réel et les potentiels insoupçonnés d'Access face aux pseudos-avantages d'Excel.

[Pierre Fauconnier]

C'est à cause de considérations intellectuellement douteuses comme celle-ci

Côté Excel :
n* licences Excel + coût dev
Côté Access :
0 licence Access + coût dev

Y'a pas photo je pense, et plus le produit sera installé sur un nombre de postes important, plus j'y aurai gagné financièrement, quand bien même le coût développement aurait initialement été plus élevé...

que je dis que la discussion devient stérile, car tu raisonnes comme si les personnes n'avaient pas Excel (ce qui peut arriver, bien entendu) et qu'on allait leur faire acheter Excel JUSTE pour faire un TCD en faisant supporter le coût Excel juste sur ce projet-là...

A partir de là, aucune discussion sérieuse n'est possible, même si j'entends bien l'argument qui est de montrer qu'Access est capable de faire des TCD, et travailler en déconnecté et plein d'autres choses...

[Maxence HUBICHE]

Aaaah !
Eh bien, c'est parce que, dans la réalité, Excel est tellement peu utile aux utilisateur de données, que de leur installer (donc d'acheter la licence) est une perte - perte réellement constatée sur de nombreux postes.

D'ailleurs, de plus en plus d'entreprises comprennent cette aberration, y compris les grandes institutions qui utilisent de plus en plus les googleApps (par exemple, car les WebApps ont du mal à démarrer côté MS)

Donc, sur le poste... point de logiciel à part le système... et encore !
Même la messagerie est en ligne (Gmail, Outlook Web Access, ...)

Et donc, faire installer un produit comme Excel revêt un coût !

De toutes façons, il est évident que, pour des raisons de coûts les entreprises qui ne sont pas lobotomisées vont de plus en plus s'intéresser à ces solutions déportées, voir même à la location de logiciel en ligne (au temps de travail) ce qui se démocratise également.

Donc, de "intellectuellement douteuse" le raisonnement devient tout simplement financièrement intéressant et concret pour une entreprise qui réfléchit à ses dépenses ! On arrête la dépendance à une solution logicielle coûteuse pour accéder à une solution logicielle gratuite (ou, au pire, moins chère) !
De la même manière que, selon moi, le passage de Excel (pour des données) à Access est un signe d'intelligence, qui nécessite reflexion, (avant de jeter le bébé avec l'eau du bain), le passage à une solution logicielle bureautique hébergée est un signe d'intelligence.

Serait-je trop utopiste en pensant ainsi, ou est-ce l'expérience des sociétés dans lesquelles je suis intervenu qui prévaut ?

Quant à s'arrêter sur une considération financière "douteuse" pour masquer toutes les autres évidences, je ne voit là rien de bien sérieux. Et au lieu de s'arrêter sur si peu, en débattre et en discuter me parait plus favorable. La preuve, c'est qu'il y a des arguments, et que certains sont mentionnés ci-dessus.
Mais il faut savoir éviter les apriori pour éviter de juger avant de les écouter.
C'est un peu comme avec Access...

[curt]

Bonsoir Maxence et Pierre,

je passais par là et, malgré que nous ne soyons pas dans la partie Débat du site, j'avoue que les arguments évoqués par chacun sont solides. Mais j'ai un petit faible pour la vidéo de Maxence qui démontre la facilité d'établir un TCD dans Access.

Mais... eh oui Maxence, il y a un mais, les entreprises ne sont pas prêtes (le seront-elles un jour ?) à passer sur Access. Pourquoi ? Parce que personne ne sait à quoi ça sert, que c'est compliqué, etc... Mais quand on pose la question : "Tu sais utiliser Access ? .... Euh non". Par contre, on sait dire que ça n'est pas bien.

Avec Excel... pas de soucis... La preuve, on peut faire tout... ouais et surtout n'importe quoi de tordu, bourré de formule qu'une base Access rendrait simple à maintenir et à exploiter.

Vous avez raison tout les deux.... Pour ma part, je préfère, et de beaucoup, traiter les données avec Access et faire des feuilles de calcul avec Excel.... Après tout, il s'agit d'utiliser le bon outil !

Au fait, il y Chagui qui avait un problème à l'origine !!!!

Bonne soirée.
Curt

[Pierre Fauconnier]

Je n'ai jamais dit qu'il n'était pas possible de réaliser des TCD dans Access, j'ai dit, dans un de mes premiers messages, que cela n'était pas toujours possible, pour diverses raisons.

De là à dire, comme Maxence:

Excel est tellement peu utile aux utilisateur de données

il y a franchement de la marge. Dans un monde "accessien", on peut éventuellement l'envisager, quoique j'ai des doutes que les arguments de Maxence n'ont pas levés, mais le monde des gestionnaires de données ne s'arrête pas à Access, loin s'en faut. Cet "argument" me fait donc sourire et cette prise de position "de jeter Excel" est pour moi incompréhensible.

Je ne connais pas de logiciels de compta par exemple, qui gèrent donc des données, qui exportent leurs données en Access (sauf un qui les gère nativement en Access), la plupart des logiciels propriétaires qui gèrent des données permettent des exportations vers Excel et pas vers Access, Des solutions sont proposées en SAP ou autres pour extraire des données vers Excel et non vers Access.

Il y a énormément de gens qui gèrent des données dans autre chose qu'Access et qui sont bien contents d'avoir Excel pour leurs TCD, leurs analyses, ... et qui me prendraient pour un crétin si je leur disais "je vais vous créer un truc avec un runtime d'Access pour l'analyse de vos données"...

Il est donc normal que les personnes qui analysent les données de provenance diverses, (<> qui gèrent les données) se tournent naturellement vers Excel

Donc, pour résumer mon propos, puis basta, puisqu'il n'y a pire sourd que celui que ne veut entendre:
Ok pour du "tout Access" lorsque cela s'y prête;
Ok pour Excel pour l'analyse des données de façon générale;
Ok pour Access pour la gestion des données de façon générale.



Quant aux autres arguments, plaider à la fois pour des webApps gratuits et pour une développement Access sous runtime me fait sourire, avancer que de plus en plus d'entreprises passent aux webapps sans étayer ses propos me laissent p

[AlainTech]

Bonjour à tous,

J'y vais aussi de mon grain de sel.
Beaucoup de personnes en entreprise ayant besoin d'analyser des données savent utiliser Excel.
Par contre, très rares sont celles connaissant Access.

Excel n'étant pas le roi pour le stockage de données, je prépare un mix Access (pour le stockage) / Excel (pour l'interface, la présentation et l'analyse).

De cette façon, les utilisateurs ne sont pas dépaysés et bénéficient des avantages d'Access pour le stockage. J'ai bien dit avantages et pas puissance car Access se fait descendre en flammes par les défenseurs d'autres SGBD tels que Oracle, par exemple.

Je pense donc que cette combinaison à un bon rapport convivialité/prix pour des quantités de données petites à moyennes.

Perso, ayant travaillé avec les 2, je trouve le VBA d'Excel plus "propre".
Les nombreux DoCmd d'Access ressemblent plus à du langage de macros qu'à un vrai langage de programmation.
Ceci dit, mon expérience d'Access est ancienne et les choses ont, peut-être évolué depuis lors.

[Maxence HUBICHE]

Envoyé par curt

Mais... eh oui Maxence, il y a un mais, les entreprises ne sont pas prêtes (le seront-elles un jour ?) à passer sur Access. Pourquoi ? Parce que personne ne sait à quoi ça sert, que c'est compliqué, etc... Mais quand on pose la question : "Tu sais utiliser Access ? .... Euh non". Par contre, on sait dire que ça n'est pas bien.

Avec Excel... pas de soucis... La preuve, on peut faire tout... ouais et surtout n'importe quoi de tordu, bourré de formule qu'une base Access rendrait simple à maintenir et à exploiter.

Je suis COMPLETEMENT d'accord avec cela.

Envoyé par curt

Après tout, il s'agit d'utiliser le bon outil !

Et je plussoie encore et encore !
Gestion, manipulation, traitement et analyse des données => SGBDR
Calculs dans des tableaux => Tableur

Envoyé par curt

Au fait, il y Chagui qui avait un problème à l'origine !!!!

Faut croire qu'il ne l'a plus ...

[Maxence HUBICHE]

Envoyé par AlainTech

Bonjour à tous,

J'y vais aussi de mon grain de sel.

Merci de ta participation !

Alors là, je risque de retourner tout le monde en disant et en affirmant très haut un argument qui va faire mal...
Access N'EST PAS un SGBDR.

Ca y est, je l'ai dit... depuis le temps que cela me démange...
Access est un RAD. Point. Terminé.
Ce RAD dialogue nativement avec un SGBDR.
Par défaut, ce SGBDR est JET, qui évolue en ADE sur la version 2007 pour la gestion des fichiers accdb (extension mdb et accdb = "bases de données")
Mais, le SGBDR peut tout aussi bien, et nativement être SQLServer (pour les fichiers adp = "projets")

Donc, l'argumentaire de "la descente en flamme des tenants de SQLServer et Oracle sur access est avant tout une méconnaissance du produit.
Ils devraient parler du moteur JET... pas de Access.
Ensuite, comparer JET avec SQLServer ou Oracle n'a pas de sens, puisqu'ils comparent un fichier avec un serveur.
Mais il ne faut pas oublier que le créneau exploité par les bases de données access(JET) est justement les "petites" bases de données mono-utilisateurs ou petit groupes d'utilisateur ayant une faible dispersion géographique.

Or, monter un serveur pour ce genre d'objectif est pour le moins coûteux.
L'alternative Access(JET) ne cherche pas plus loin.
Si on a besoin de plus, l'alternative Access(SQLServer) tient la route, et là, les tenants des serveurs peuvent s'accrocher pour commencer à critiquer Access... puisqu'ils critiqueraient SQLServer, en fait

Envoyé par AlainTech

Beaucoup de personnes en entreprise ayant besoin d'analyser des données savent utiliser Excel.
Par contre, très rares sont celles connaissant Access.

Oui, c'est vrai !
Et c'est, à priori, côté utilisateur LE problème.
Et cela rejoint ce que j'exprimais plus haut :

Le vrai problème repose sur l'attachement de certains à des savoirs existants (je connais Excel et pas Access...), qui gèrent mal les priorités ("j'ai pas le temps", "c'est un travail urgent", ...) - et tout ceci pourrait être un autre débat

Donc, pour ce qui est de la "convivialité", je te laisse libre de ton choix, comme tout un chacun, mais ce n'est pas un avis que je partage.
Je pense que cette notion de convivialité touche à l'habitude qu'on a d'un produit.
Je pense que tout le monde peut se mettre à Access.
Certains s'y mettent sans aide extérieure (j'ai actuellement un stagiaire qui a appris access en lisant des tutoriels, et il suit un cours de perfectionnement) Certains ont besoin d'être guidé... chacun ses capacités d'apprentissage.
Mais, pour le moment, je n'ai personne qui ait suivi mes stages et qui soit sorti en disant : j'ai rien compris. j'ai même eu des personnes qui m'ont demandé une démonstration de quelques minutes pour voir ce qu'on pouvait faire avec Access et qui sont parties en disant qu'elles demanderaient une formation à Access.
Donc, s'il y avait un peu plus de gens avec l'esprit ouvert, qui avaient envie d'avoir des méthodes de travail plus efficace, il y aurait plus de personnes à utiliser des SGBDR.

Perso, ayant travaillé avec les 2, je trouve le VBA d'Excel plus "propre".
Les nombreux DoCmd d'Access ressemblent plus à du langage de macros qu'à un vrai langage de programmation.
Ceci dit, mon expérience d'Access est ancienne et les choses ont, peut-être évolué depuis lors.

le VBA est le VBA. Son socle, c'est la bibliothèque VBA
Pour programmer Access tu utiliseras la bibliothèque Access, pour programmer Excel ce sera la bibliothèque Excel, etc.
Sur Access, certaines actions seront faites à travers le fameux objet DoCmd, mais on peut faire plusieurs de ces actions sans le DoCmd...
Tu as raison de dire que DoCmd fait penser à du langage macro... c'est ce qui sert à traduire les "macros" en VBA de manière automatisée (dans les menus d'Access). Mais il ne faut pas perdre de vue que DoCmd est une méthode de la classe Application, qui renvoie un objet de type DoCmd, et que cet objet contient lui-même un certain nombre de méthodes.... bref, comme toutes les bibliothèques
Mais, bon... moi, dans Access, je programme avec des modules de classe, des collections, des interfaces, des évènements ... comme dans Excel.
En fait, il n'y a que les mots qui changent