Discussion :

[CRUSOE13]

Bonjour à tous,

Salut {F1},

J'aimerais bien aller sur votre île (de France) !
Sachez que j'admire sans retenue la brillante synthèse que représente votre article publié le 15/10/2004.

Coïncidence : La case à cocher pour sélection individuelle d'enregistrements sans point commun est la toute première fonctionnalité personnalisée que j'ai ajoutée, moi aussi, lorsque j'ai abordé le travail avec des formulaires dans MsACCESS !

Quant à votre dernier post, je m'empresse de le recopier dans ma collection d'arguments en sa faveur.
Cela fait toujours du bien d'avoir sous la main de quoi rabattre le caquet de ceux qui critiquent sans fondement.

Je n'y trouve pas de contradiction d'idées avec les miennes bien que j'aie utilisé le mot "béquille" qui n'était pas approprié.
(Cela dit, ôtez sa béquille à quelqu'un qui en a besoin : Il y a de fortes chances pour qu'il se retrouve par terre !)

Votre conception d'une architecture "composite" (ERP/MsACCESS) dès le départ me semble être une idée remarquable.
Elle éviterait bien des errements, dus à la difficulté que représente pour les informaticiens de cerner correctement un besoin vu de l'extérieur.
Malgré toutes les méthodes d'analyse existantes, il leur faudrait ajouter à leurs compétences une vue "métier" que seuls les gens du milieu peuvent avoir, et qui leur permettrait de distinguer clairement le spécifique du "standard".
De leur côté, les gens du métier ne voient pas les choses d'un point de vue exploitable pour un informaticien.
D'où l'intérêt pour l'entreprise d'avoir recours à un informaticien attitré, voire de l'embaucher.
Vaste sujet !

Pour en revenir à la question posée au départ dans ce débat, elle me semble être un faux problème (ou plutôt un problème mal posé).
En revanche les réponses ainsi que le contenu de votre article ont l'immense mérite de recadrer une quantité impressionnante d'idées reçues et de notions de base (de données) mal assimilées !

Quant au possibilités offertes par MsACCES dans le prototypage, y compris celui de produits destinés à une architecture client/serveur, elles sont, comme vous l'avez si bien montré, quasi illimitées.
Mais il existe un prérequis à cela, qui est de connaître son outil sur le bout des doigts, comme un compositeur connaît son instrument, et de travailler dans les règles de l'art (en queue de pie au clavier).

L'élaboration de maquettes fonctionnelles, même sur une quantité relativement faible de données, fait immédiatement ressortir un défaut de structure.
Ces maquettes permettent de tester le comportement des éléments critiques, voire de les mettre en évidence s'ils n'avaient pas été considérés comme tels.
Ce serait trop bête de s'en priver !
A plus forte raison losqu'on sait qu'un client ou une entité cliente n'a pas nécessairement la clairvoyance requise pour préciser l'évolution d'un besoin : Savoir anticiper est précisément ce qu'on attend de l'analyste/informaticien.

À cet égard, MsACCES s'avère être aussi un outil de spécification au moyen d'un modèle éprouvé.
J'ai connu ce cas, toujours dans le spatial, pour un logiciel de gestion "qualité bord" :
Après quelques années de fonctionnement sous MsACCESS, la transposition vers un grand système, pour raisons de montée en charge, s'est effectuée en un temps record !
Économie, sécurité de retrouver un découpage pertinent de l'information, une structure fiable et des fonctionnalités bien rodées, que souhaiter de mieux ?

Attention, vous risquez de lever un (gros) lièvre avec votre remarque à propos de MsEXCEL !
Très performant dans son domaine, on a souvent le tort de le "préférer" à MsACCESS pour "développer des bases de données" !!! (sic).
Peu d'usagers font la différence entre une gestion matricielle (cellules) et la gestion d'enregistrements (lignes) du moteur Jet.
Pourtant tout est là !
Il y aurait amplement matière à un autre débat !

Cordialement.

CRUSOE13

[malzouave]

Bonjour à tous,

Je suis un nouveau venu chez vous et vous remercie de m'accueillir

Je n'ai pas lu toutes les pages relative à ce sujet mais les 8 premières et c'était trés intérréssant.
Je constate que vous êtes des techniciens et rentrez dans des débats techniques qui n'ntérsse pas un décideur, qui cherche à pour savoir s'il va utiliser ACCESS ou ORACLE avec un langage JAVA ou VB, mais il y a un certain nombre de question que je vais me poser, et remplir un tableau de descisions avec des critéres éxclusifs, qui par définition éxclurons le choix et des critéres avec des coéfficients qui vont orienter mon choix final. Si je vous donne ce tableau, vous allez chacun le remplir à votre façon et de manière contradictoire et donc je vous demanderez dans discuter en ma présence pour essayer de me faire une idée, ce qui est déjà fait, j'ai lu toutes les questions que vous vous posez et j'en ai conclu ce qui suis.

1 - la base de données ACCESS est elle une vrai SGBDR
OUI
2 - la base de données ACCESS est elle sécurisée et entièrement
OUI
3 - la base de données ACCESS me permettra-elle de faire des requêtes non prévues initialement ?
OUI
4 - la base de données ACCESS est elle évolutive ?
OUI
5 - la base de données ACCESS permettra-elle d'être manipulées sous INTERNET et de mainiére sécurisée ?
OUI
6 - la base de données ACCESS peut-elle enregistrer des fchiers de toutes natures
OUI
7 - La taille maximum de la base de données ?
2 Go
8 - L'encombrement du réseau est-il plus important ?
Ca dépend, comment vous faite votre base, si c'est sur internet NON pas plus qu'une autre,
Si c'est tout le fichier et avec des tables attachée je ne sais pas ce qu'il en est exactement et je pense poser la question à Microsoft lui même, puisque vous n'avez pas su répondre exactement ce qu'il se passe
9 - le cout de l'opération ?
Cela dépend si je veux pouvoir modifier moi même la base : alors ça me coute une licence ACCESS en plus
Sinon, dans tous les cas ça va me couter le prix du développement et que se soit eb VB en C en JAVA ou en Assemleur se sera le même.
Il ne faut pas oublier le cahier des charges qui est le même sur ACCESS ou ORACLE ou SQL serveur ou MySQL
- mais il ne faut pas oublier le cout du matériel, le cout de l'apprentissage pour l'utilisateur, le cout de la maintenance, le cout de l'évolution, je veux dire les peties évolutions qui ne se font sentir qu'aprés un certain temps d'utilisation par exemple des aspects érgonomiques, mais aussi des requêtes non prévues initialement.

J'attend vos contradictions, mais avec des argument valables pour moi, c'est à dire que je ne m'inttéresse pas à l'aspect de vos outils de développements, ce qui m'intérresse c'est possible ou pas, le cout est-il plus fort avec un outil qu'avec un autre? chez vous personnemellement oui, mais si je vais chez un concurent?

Je vous remercie de m'avoir lu

[Papy Turbo]

Très brièvement, sur le coût : j'ai fait presque autant de VB que d'Access, depuis 90.

La simple création d'un formulaire avec saisie de données, ajout, suppression... est quasi instantanée (disons : presque négligeable) en Access, ce qui n'est pas du tout le cas avec VB et tous langages liés à des bases Client/serveur.
Access est le seul langage de ma connaissance ou le "binding" (liaison des contrôles avec un champ de la base de données) marche, sans aucun problème.
Je ne connais aucun gourou en VB, qui recommande d'utiliser le binding, au contraire. J'ai essayé, j'ai perdu beaucoup de temps, je ne le ferai plus.
Choisir Access, quand c'est possible, me permet généralement, non pas de faire un logiciel 'moins cher' (sauf si très petit budget, logiciel 'jettable' ou similaire), mais de consacrer beaucoup plus de temps à la structure (donc maintenance + facile, débogage quasi transparent), et à l'ergonomie (d'où gain de temps + confort pour utilisateurs)...

Il y a de très nombreux autres arguments pour la baisse des coûts :
- en gros, Access se situe entre Excel et les langages + lourds, lorsqu'on veut du vite fait - bien fait. Mais peut aussi servir pour de petites (peu d'accès concurrentiels) applis très sophistiquées.
- la base de données, directement sous la main et très flexible, permet aussi d'importantes réductions (par rapport à la même en SQL Server, je crois que c'est une évidence ) au niveau de l'analyse et création d'une application. D'où : excellent outil de prototypage, pour des applis lourdes.

[malzouave]

Bonjour !

J'ai réaliser des bases de données qui gére des entreprises la partie commerciale, les commandes la facturation, le stock, la caisse, le planning, les ordres de fabrication, les tarif fourisseurs etc.
Je ne comprend pas coment vous avez des bases de données dépassant 100 Mo puisque l'enssemble de mes base de donées remplie par les clients depuis plus de 10 ans ne dépasse pas 45 Mo, je ne parle que des données et je ne parle pas des tarif fournisseurs qui peuvent atteindre prés de 100 Mo chacune ni des fichiers WOrd, excel et autre qui peuvent atteindre 100 Go.
Pour moi un fichier prend trés peu de place dans la base de données puisque j'utilise son emplacement comme donnée.
Pour moi les tarifs fournisseurs sont des tables attachées chacune dans une base de données
Alors pour moi, ça me parait inconcevable même en ayant plusieurs centaine de mille de client avec 1000 octets par client ça fait 100Mo en effet, mais ce n'est pas la majorité des cas de base de données il me semble qu'Oracle serait plus adapé comme base de donnée, mais avant d'investir dans Oracle j'étudirais bien la question. Je n'investirerai pas sur MySQL pour de type d'application qu'il m'obligerait à programmer toutes les contraintes référentiel du type effacement en cascade ou suppresion non autorisée si des enregistrements connexe existe etc. Ou alors j'investirai dans SQL server.


Merci encore une fois de m'avoir lu

[davidlandi]

Un autre aspect négatif d'Access:
il ouvre des tas de fenêtres et c'est très lourd à gérer dans la barre des tâches!
Bon ok... je sors...

[malzouave]

Bonjour à tous,

Je vous fais part de mes investigations dans le domaine ACCESS pour ou contre

L'aspect CLient/Serveur est un bon argument contre ACCESS, car ACCESS n'est pas Client/serveur, que veut dire Client/serveur ? Et bien ça veut dire qu'en mode client/serveur, votre base est sur le serveur et vous en tant que client allez interroger la base (1 requête), la requête va s'executer sur le serveur et à la fin va répondre (1 réponse).
Ce qui limite pas mal le flux de données sur le réseau. Alors que dans une base de type fichier comme ACCESS ou DBASE ou PARADOX ou FOXPRO ou MySQL, c'est le client qui va exécuter la requête, c'est à dire que le client va lire l'essemble des données nessecaire pour écécuter la requete puis en donner la réponse et cette réponse ne sera peut-être qu'un enregistrement et il aura fallut lire 100 ou 1000 ou 1 Million d'enregistrements.

En plus de ca ACCESS n'accepte pas d'étre transactionnelle, dans le sens client serveur, et ne dispose pas de Triggers ce qui fait qu'ACCESS est limitée en nombres d'utilisateurs et nessecite une rapidité en réseau importante.

Mais néanmoins, c'est un logiciel exellent pour un petit nombre d'utilisateur, ce qui ne veut pas dire pour pour une application simple, car mais même pour de trés grooses applications ACCESS peut faire l'affaire à condition d'étre peu nombreux à l'utiliser( au maximum 10 personnes)

au dela de 10 personnes, je vous conseille d'utiliser soit Oracle soit SQL serveur ou Sybase ou encore DB2.

si votre base est sur intenet alors là vous avez tout gagnez en ce qui concerne le trafic sur le réseau, puisque l'HTML est client serveur, mais coté dévellopement , il faudra tout refaire dans un autre langage comme ASP par exemple associé à du VBScript ou à du JavaScript.

Je vous remercie de votre attention

[B.AF]

Salut à tous,

Je voulais d'abord vous remercier pour la quantite de ressources que vous rendez disponible sur Access. C'est vraiment très utile et très bien maintenu donc :

Cependant,

Je lis des choses qui me surprennent un peu. Je developpez actuellement un projet de grosse taille ( actuellement un MPD de 78 tables intégrées avec formulaires et traitements fonctionnels, avec un MPD cible de 450 table).

Pour ce projet, j'ai choisi un client Access et un serveur SQL Server, le tout en ADO / ADO Shape.

Premiérement, je suis très surpris de voir des développeur

Systèmatiquement confondre JET et Access.

Le moteur Jet est peut être limité ( proc stocks, UDF, trigger...)
Le moteur Access sur SQL ne l'est pas (Trigger, procs stocks...)
Le moteur MSDE est un bon compromis

Aujourd'hui je ne vois aucun langage qui permettent de réaliser des clients avec un cycle de développement aussi court.

Deuxiémement, je me sens un peu seul au monde sur cette méthode :
Utiliser Access sur SQL Server ( Pas MSDE)

En effet, je suis extremement surpris de ce que mon Access arrive à faire en volume par rapport à ce que je lis....Qu'evidemment JET n'aurait peut être pas pu faire ou plus lentement.

Meme qu'il est possible de faire un fake relationnel / objet avec les modules de classe, et là, pour developper c'st le bonheur, et grace à un petit outil Excel, les modules de classe sont générés directement depuis les modéle des tables.

Clairement, si l'objectif fonctionnel est à 6 mois / 1 ans,
L'objectif technique econd est ADO RDS ( n tiers).

En tout cas Access me permet aujourd'hui :
De prototyper (JET)
De designer (projets ADP)
De faire des Schemas
De generer une doc
De developper (aussi !!! ;-) )
De produire un reporting cote client (quand on voit le prix des moteurs de report pro, on en comprend ici tout l'intérêt....) en utilisant un recordset en memoire sur le CLIENT (donc customisable par le client)

J'ai peu de choses à lui reprocher, car le peu que nous avons porté sur .NET (GUI en VB et classes en C#), c'est 5 fois plus de temps en terme de developpement pour un resultat qui reste tres proche, sauf technologiquement (dataset / datareader vs. recordset)

Alors j'aimerai bien que cette methode de developpement soit davantage reconnue, car c'est bien. Ca fait ce qu'il faut, c'est rapide, c'est performant.

Vos avis sont les bienvenus, mais j'aimerai surtout ici pouvoir confronter desavis avec des gens qui se sont servi d'Access comme client sans utiliser Jet.

Merci !

Frederic.

[random]

Messieurs les informaticiens
je ne sais pas si access est un outil pro mais si à 8 heures on me demande de donner au plus tôt un calcul impliquant pour
200 000 lignes sur deux ou trois axes un calcul un peu évolué
prenant en compte 5 ou 6 paramètres je disposerais le soir même
des résultats avec un jeu de graphiques excel

Si je demande la même chose à l'informaticien de service j'aurais
rendez vous avec lui la semaine prochaine, je passerais une demie
journée pour lui expliquer les calculs, et je récupérerais un état figé
pour resaisie excel

Bien entendu son application sera pro et pas la mienne, elle sera évolutive, il suffira de reprendre rendez vous avec mon informaticien,
de lui dire que je veux prendre en compte un axe supplémentaire de modifier ainsi les calculs, et d'attendre un peu.

De même quand, Monsieur l'informaticien m'explique que ce que je veux
est infaisable je crée une nouvelle base, et je le fais.

Evidemment un non pro est capable le bougre de développer sans
utiliser la programmation objet, sans hérédité, sans même (horreur absolue) de gestion d'erreur, je le fais tous les jours, sans me poser de question.

N'est pas seulement pro toute approche institutionnelle avec son cortège
de normes, de documentation ahurissante, de MCD et de Merise, mais aussi toutes les solutions métiers mises en place par des utilisateurs.

Quand vous arrivez enfin, la base n'est pas utilisable ??
et alors ?? vous êtes justement là pour en créer une autre...
les données sont présentes et récupérables.

Et si nous parlions aussi du rapport qualité/prix ?

[B.AF]

Justement, ce serait bien d'arrêter de voir Access comme cela.

L'avantage d'access est justement de pouvpir toucher un public large :
Du bidouilleur bureautique qui y trouvera l'outil pour faire ses traitements un peu spécifiques au développeur qui pourra fare une application packagée et fonctionnelle.

Cependant, il faut aussi coupé un peu cette iage de SGBD fichier.

Que se passe t-il si je fais de ma base uniquement un repository de forms et de classes/modules VBA et ue j'utilise ADO pour me connecter en ODBC sur une base Sybase, ou Oracle, ou DB2 ou peu importe ????

[tintinmarre]

Etant mécanicien de formation j'utilise Access despuis dix ans pour mes besoins professionnels perso (atelier de boulonnerie)
Comme l'info n'est pas le sujet principal de ma boite (mais les boulons) j'ai appris tout seul comme un grand et 1stagiaire m'a appris le VB (comme quoi les stagiaires, c'est bien utile)
Aujourd'hui, l'aplication est grosse et velue. 20Mo, 20tables, 20000lignes dans la plus grosse, 60requètes, 40 formulaires et quelques états, avec aussi des interpolations surfaciques qui sont d'un niveau légèrement supérieur au pourcentage
Après m'être fait ridiculiser par une supporter inconditionnelle des vraies bases, j'ai téléchargé MySQL et j'ai réussi! mon Nom et mon Prénom dans une table à 3 colonnes.... après 3 jours et avec une console MySQL qui ressemble aux télétypes (vous savez ces machines à écrire qui perforaient des rubans à coté des machine outils à commande numérique)
En fin j'ai téléchargé les MySQL Migration et Browser qui m'ont fait oublier le télétype mais je ne comprend pas pourquoi ces outils ne sont pas intégrés et pourquoi ils ne migrent pas les requètes puisqu'il m'a suffit de faire du copier coller du SQL Accesss dan MySQL pour que ça marche... enfin!!!!!
D'autre part j'ai essayé le module Base de OppenOffice qui a par ailleurs toute ma sympathie mais il faut reconnaitre qu'un éditeur graphique qui ne sait pas faire une simple requète de non correspondance c'est limité
Je suis donc encore à la recherche du SGBDR "pro" qui puisse être une 'continuité' d'Access
PS je précise quand même que Access permet de servir de support à une analyse qui ne dépend que de l'analyste. Les types de données restent, les données elles mêmes aussi (5 ans de saisies journalières, ça a une certaine valeur), l'analyse des besoins de l'utilisateur aussi, les états, même non récupérables directement donnent bien la trame du besoin, etc...

[Blibli]

AAAaah ! Vous n'êtes pas seuls, moi aussi j'ai fait du développement Access + SQL-Server à bloc.
A mon avis, Access, comme RAD sur un système d'information, y'a pas meilleur rapport qualité/prix.
Quelques infos sur mes projets (Bases sur SQL Server) :
- 140 tables, dont certaines avec + de 3 000 000 d'enregistrements
- Interface graphique sous Access
- Des bases de données identiquues de plusieurs Go (de 2 à 6) dans plusieurs pays, accessibles à distance depuis l'interface sous Access, et qui ne cessent de grandir.
- les maquettes faites sous Access, et aussi des applis d'analyse rapide (du genre à faire pour hier et à usage unique) qui pouvaient contenir 300 000 à 1 000 000 d'enregistrements.
Et ça marche.

Bref, je déconseille Access (ou plutôt Jet) en tant que SGBDR, mais en tant qu'environnement de développement rapide et pas cher, c'est vraiment bien. Si on veut, on peut acheter Business Object et Oracle... mais rajouter un 0 sur la facture, et oublier MySQL pour de si grosses BdD (accédées 24h/24, avec les sauvegardes et autres joyeusetés administratives en tache de fond sans perturber la production).

Maintenant que j'ai changé de boulot, je me penche du côté du libre, et regarde des solutions basées sur OpenOffice 2 + MySQL... et bin y'a encore du chemin à faire pour que ça soit aussi efficace, mais ça viendra sans doute un jour. Le seul problème, c'est qu'on dirait bien que les développeurs OpenOffice sont encore trop axés "Linux-Apache-MySQL-JeTapeToutEnTexte", et ils ont encore du mal à comprendre qu'on puisse créer et concevoir une BdD entièrement à la souris, sans taper un seul "CREATE TABLE".
J'ai hâte que ça change...

J'admets quand même que pour les grosses grosses analyses, les procédures stockées et autres triggers de SQL Server étaient obligatoires.

[Blibli]

Je suis donc encore à la recherche du SGBDR "pro" qui puisse être une 'continuité' d'Access.

Tu pourrais peut-être essayer d'attaquer une base de données MySQL avec Access avec une connexion ODBC.
Tu y gagnerais en fiabilité niveau données et certainement en rapidité (si tu utilises une base Access sur du réseau).

[Arkham46]

Argument pour :
--> on peut programmer PacMan dans un contrôle image!

Si avec ça vous êtes pas convaincu!

[loufab]

et DOOM ou QUAKE ? c'est possible ?

[Golzinne]

Je crois malheureusement qu'on ne changera pas l'informaticien qui croit toujours que ce qu'il connait est la seule technique valable qui suplante toutes les autres.

Le développeur Vb dira que par rapport à access, lui fait de l'objet, le développeur dotNet dira la même chose par rapport au développeur VB et surtout, le développeur Java se croira au dessus du lot !

Par une expérience personnelle et celle de collègues proches, expérience qui accumule des milliers de jours dans chacun de ces environnements, je retiens seulement qu'il y a moyen de faire de belles choses dans chaque environnement?

Et puisque le sujet ici est Access, des applications écrites pour des industries avec plusieurs centaines d'utilisateurs, avec Oracle et accès en Passthrough, répondent avec une souplesse incroyable à tous leurs besoins, s'adaptent facilement, se mettent à jour automatiquement, sont (parfaitement (en tout cas suffisamment) sécurisées et performantes. On constate également que ces développements, bien que professionnels, en access prennent 2 fois moins de temps que leur équivalent en DotNet et 4 fois moins qu'en Java.

C'était pour relancer un peu le débat qui s'endormait tout doucement

[kissmytoe]

D'après moi, je ne sais pas si ca a été dit je n'avais pas 10 heures a passés sur ce sujet lol ma pause n'est que de 15 min alors je m'excuse si jamais je répète.

Access = SIMPLICITÉ

Access est très utile pour les newbie de l'informatique qui veule se créer une petite base de donnée rapidement et simplement. Dès que l'on parle de base de donnée importante (tant au niveau de l'importance des données que du nombre d'enregistrement) on doit voir autre chose.

Lorsqu'on est programmeur ou qu'on a une grande notion de programmation on ne choisit pas Access par choix (Moi jlai fais par obligation dans mon stage)(L'informatique est TRES mal géré ici hehe)

[B.AF]

"Lorsqu'on est programmeur ou qu'on a une grande notion de programmation on ne choisit pas Access par choix"

Si si, je t'assure, en bon paresseux, je prends toujours ce qui va le plus vite.

Je crois surtout que pour bcp d'informaticiens (pour être large) il y a vraiments deux langages qui sont inconnus :
Le langage commercial
Combien de produits connaissent une mort douce grace aux papes de la techniques qui allongent les cycles de developpements par facteur 2, parlent à leurs clients de prè requis techniques....
Le langage utilisateur
Il s'en tape de ce que tu utilises.Il veut un résultat

Je suis comme un autre, je préfére faire du distribué, du mapping OR, du client léger. Oui intellectuellement c'est stimulant.

Mais alors que je trouve bcp de ressources sympas sur ce site, certains commentaires sont du niveau collége. "Moi j'ai 14 de moyenne en français" "Oui mais moi j'ai 15 en maths" "Oui mais en rédaction j'avais 16 l'année derniére".

Et des développeurs qui se plaignent tout le temps que ce qu'ils font ne les fait pas vibrer j'en connais. Ceux là même qui peine à écrire une procédure stockée en SQL (Rhaaaa....Dégradant le SQL !!!!)

Ca me fait penser à un copain qui m'a appellé aujourd'hui.
En rigolant il me dit qu'un developpeur a monter un modéle de donnée qui permet de gérer 10^45 solutions différentes d'un contexte.
Et en DK siouplait ! (10 tables)
Super.
Pourtant en théorie, le modéle est beau
MAIS (il y en a toujours)
C'est de l'argent jeté par les fenêtre
L'utilisateur final n'y trouvera rien de plus en terme d'usage
les autres developpeurs s'arrachent la tête.
Le coût de maintenance va exploser
le risque d'instabilité va se multiplier.

C'est une donnée standardisée disponibles, il y a 700 référence effective.

La stupidité rigoriste, ca laisse rêveur.

Comment se rendre compte de la connerie ?
Prendre Access
Faire le proto
Tester

En 45 minutes, on a déjà toruvé une 3F qui fait tout pareil, plus souple, plus simple.

C'est aussi ca access.Ca permet d'éviter beaucoup de conneries...

[rawsrc]

Je développe sur Access depuis 10 ans maintenant et je peux vous garantir que c'est un petit produit qui n'est pas prêt de disparaître.

Malgré ses limitations, il est tout à fait possible d'adapter une approche POO sur Access.
Avec les modules, modules de classe, évènements personnalisé, contrôles tiers (Treeview, WebNavigator...), l'accès à l'API et l'intéropérabilité totale avec Excel et Word, je peux vous certifier qu'il est tout à fait possible de faire du développement très propre et maintenable sur Access.

D'après mon expérience, 70 % des besoins des entreprises peuvent être satisfaits en utilisant et/ou en combinant Access, Excel et Word.
Mais le problème est que 90 % des utilisateurs ne connaissent à peine que 5 % des fonctionnalités de ces produits, d'où l'intérêt de développer une interface simple sur Access et de combiner avec le VBA les autres logiciels du pack Office.

Pour ne rien gâcher et pour des développements plus importants Access vous permet d'attaquer à peu près tout ce qui existe en matière de SGBD.
(SQL Server et mySQL, c'est du gâteau)

Sur le pack Office, le cycle de développement est assez court et permet de créer vraiment des outils très pro pour un prix restant abordable.

Pour l'avenir, Access gagnerait à suivre un peu plus près la POO pour les développeurs professionnels tout en conservant son approche volontairement simplifiée de la programmation pour tous les autres utilisateurs.

[LostIN]

De mon coté, utilisateur d'access (principalement 97/2000) depuis maintenant qq années (8).
J'ai touché, d'autre part à VB6(base access).
Puis Delphi, (puis Progress), puis Windev(base hyperfile/sql server).

Je ne vais pas parler du nombre d'utilisateurs, ni des triggers, du transactionnels ...car dans ce cas, utilisez tout de suite du SQLServer, Oracle.... C'est pas le job d'access. Je trouve que les repriches fait dans ce sens ne sont pas malin.
D'autre part, le débat est faussé, car les réponses ne sont pas forcement cohérentes en fonction de la personne utilisatrice.

Un gars qui bidouille une base (non service info) se sert d'access comme base et outil de dév. Ne lui parlez donc pas d'oracle(ce n'est pas son job).
Un informaticien qui sort des reproches sur les triggers,..., utilise access comme outil de dév et peut utiliser autre chose pour les données.
Donc il ferait mieux de ne pas les faire car il a les possibilité, lui, d'utiliser autre chose.

On additionne pas les choux avec des carottes.

L'avantage et le prob d'access selon moi, c'est sa simplicité.

Donc l'utilisateur farfelu ou ferru d'excel (que je ne suis pas) va s'y mettre, et va rapidement monter des usines à gaz (très souvent) que tout informaticien un tantinet organisé va détesté et ne pourra maintenir sans en revoir une bonne partie..

L'avantage c'est que l'informaticien un poil débrouillard et pas feignant sur le code pourra sortir pas mal de chose et performantes.



Donc le souci, c'est qu'un jour, le newbie va se rendre compte qu'il est coincé et va devoir se trouver dans le bureau de l'informatique, qui ne voudra pas continuer dans cette usine à gaz (car il ne savent pas faire ce que le newbie a fait).
Donc l'utilisateur va etre frustré. Car il ne pourra pas toucher à son "bébé", car l'informatique aura codé, alors que lui utilisait des macros...

Dans une société, il y a des services.
Certains devraient faire uniquement leur job (de compta, de controle de gestion, de prod..) et demander à l'informatique de repondre à leur besoin de A à Z.

Ne me dites pas que je veux faire de l'informatique, un coté ellitiste. Sinon je ne parlerais même pas d'access.
Mais chacun son métier et chacun ses outils.

D'un avis perso, je ne vais mentionner que le coté développement, IDE.
Et dans le lot, sans hésitation, je mettrais en tête Windev.
On ne réinvente pas la poudre, il y a une multitude de fonctions qu'access n'offre pas (mais qui sont codables), les objets sont déjà distribué.
La programmation se fait bcp plus vite.

[CAMIC]

Salut tout le monde

Bon sujet de discutions, car en quelques lignes, j'ai appris des choses que je n'ai encore trouvé nulle part ailleurs.

Voici mon opinion qui est très partielle, car j'aurai beaucoup à dire sur les manquements de MS-Access, car j'ai repris une application MS-Access écrit par une autre personne et ce depuis plus de 6 mois, mais quelle galère pour des besoins très basic.

Dans mes précédents job, j'utilisais X-Motif pour le graphique, C++, C et OCI pour Oracle, ainsi que Java (AWT et swing) et jdbc pour les accès aux bases.
Donc je suis bien placé pour dire ce qui pêche dans MS-Access et son VBA.

Mis à part la petite guerre en les amateurs et les professionnels, en vous lisant, vous ne parler que performance (dans mon cas pas terrible et pourtant je n'ai qu'une centaine de lignes) ou de langage mais rien concernant simplement l'interface graphique qui est votre carte de visite vis-à-vis de vos clients et qu'est-ce qu'ils vont en penser de vos « magnifiques développements »?
Cette à croire que vous ne développer que de simple formulaire avec peu être des sous formulaires,!!!

Personnellement MS-Access est peu ou pas convivial du tout, je ne parle pas de la façon de construire les formulaires, mais du comportement des contrôles, comme argumentation, voici quelques cas parmi d'autre basés uniquement sur un simple formulaire continue, car si je vous parle de formulaire imbriqué sur plusieurs niveaux statique ou dynamique ainsi que des rapport/ sous rapport dynamique plus personne ne voudrait utiliser MS-Access à moins d'être maso. (pour le moment je ne peut faire autrement pour des raisons de délai).
De plus, malgré les versions étalées sur plus de 10 ans cet outil est encore bâclé, je suis presque sûr que la version 2007 ne résoudra pas les cas ci-dessous. (quelqu'un peut-il confirmer, merci d'avance).

Les cas suivant sont là uniquement pour démontrer que la gestion du scrolling des enregistrements (ascenseurs) est déplorable.

Prenez par exemple un formulaire continu avec un en-tête qui prend 1/5 de la hauteur, le corps qui prend le 3/5 et pour finir le pied qui prend, le 1/5 restant.
Lorsque l'utilisateur ouvre ce formulaire, il voit que l'ascenseur utilise toute la hauteur du formulaire. Ne sachant pas comment ce formulaire a été créé, il pourrait logiquement croire qu'il ne peut pas voir tout le formulaire (en l'occurrence que le pied du formulaire est partiellement masqué), donc, s'il bouge l'ascenseur vers le bas, il devrait voir la partie cachée du formulaire, mais en fait, il verra pas le formulaire bougera mais plutôt les enregistrements défilés pour autant qu'il y en a un nombre suffisant (voir paragraphe suivant)!!!

Maintenant, si vous ouvrez le formulaire ci-dessus et que vous n'avez que 3 enregistrements affichés, alors que la zone permet d'en voir plus, vous voyez toujours l'ascenseur, vous me direz c'est pas grave, mais le plus pire, c'est que si vous cliquer quand même sur la flèche du bas pour le même motif que ci-dessus (pied partiellement caché) plusieurs fois car vous ne voyer toujours pas le formulaire bouger parce que vous avez les yeux concentrés sur le bas du formulaire et que par conséquent vous ne faite pas attention que le peu d'enregistrements ce déplace vers le haut jusqu'à n'afficher que le dernier enregistrement, l'utilisateur ne verra pas qu'il a masqué un certain nombre d'enregistrement, pourquoi, c'est que la barre central de l'ascenseur indique toujours que la totalité des enregistrement est affiché alors que c'est absolument faux, donc l'utilisateur peut croire qu'il n'y a qu'un seul enregistrement!!!!
Cette impression peut aussi être provoquée quand on revoit ce formulaire plus tard suite à la fermeture d'un autre formulaire qui le masquait.

J'ouvre un formulaire qui peut afficher 5 enregistrements sur les 21 de ma base, quand je l'ouvre, la barre centrale de l'ascenseur m'indique logiquement qu'en divisant la longueur du scrolling de l'ascenseur avec la hauteur de la barre central que je ne vois que 1/20 de la totalité des enregistrements donc 20 * 5 = 100, ce qui est faux puisque j'en ai que 21, d'ailleurs si maintenant je clique sur la barre ou la flèche vers le bas la hauteur de la barre devient correcte!!!

Dans le formulaire ci-dessus, j'ai mis un bouton pour aller directement sur le nouvel enregistrement plutôt que de descendre l'ascenseur jusqu'en bas, mais quand je clique sur ce bouton, il m'affiche bien le nouvel enregistrement, mais je ne vois plus que lui tout en haut de la zone, donc si je veux voir les derniers enregistrements, je suis obliger de bouger quand même l'ascenseur!!!!

Les clients ou bien vos supérieurs n'ont rien à faire de la façon dont vous avez travaillé, ils vont se focaliser sur des aspects visuels avant les fonctionnalités (un de mes anciens directeurs voulait me foutre dehors pour le choix des couleurs en phase de prototypage).

Je ne vous ai parlé que sur une petite partie de l'interface graphique. Mais j'aurai pu aussi parler sur le VBA, l'environnement de développement (essayer par exemple d'imprimer les relations sur quelques pages A4 avec MS-Access version 2003, impossible plein de vide et pas tous est imprimé, si on utilise que MS-Access on est condamné à faire des captures d'écran, ciseau, et colle).

CAMIC