Discussion :

[Zeo_BO]

En outre, sous java (je suis pas certain), il est difficile d'avoir une procédure spécifique de gestion d'erreur.
Sous VBA, les procédures ecrites par bidou ou Zemenace, pour peu que le code soit pensé, peuvent être entiérement stockées dans une fonction sub() avec en réception d'argument l'err.number et eventuellement une variable qui recoit un donnée précisant la procédure qui génére l'erreur

Ca évite un try{} catch {} dans chaque procédure.
Et malgré tout les approches ne sont pas si éloignées.
Le "on error resume next" fait "le throws exception"
Le "on error goto" fait le try{} catch {}

C'est en plus propre, puisqu'il n'y a qu'une procédure.

[azu1]

alalalala le probleme c'est que vous vous cantonnez tous derriere vos positions
vous essayez tous de convaincre l'autre sans l'ecouter.....

BREF pour resumer ACCESS est un vrai SGBD et VBA est réellement puissant pour peu quon sache l'utiliser.
et je veux pas etre mechant mais c'est franchement plus simple que le C C++ ou java.....

Mais je serais idiot de dire VBA c'est top et JAVA c'est de la merde....
c'est faux cela depend juste des besoins.
on va pas utiliser une usine a gaz nécesitant des jours de developpement quand cela n'est pas nécessaire.
Par contre juste en passant, dans les salles de marches de BNP et de la Societe generale (pour ne cité que ca) on utilise tous les jours access VBA et meme Excel...
a bon entendeur...

PS: Au fait arreter de vous entretué je pense qu'on a plus 10 ans et que le but est d'avoir une vision objective de la question de départ
en tout cas ce qui me fait sourire c'est que le petit malin qui a poster cette question n'a pas donné de nouvelles.... ni n' a posé d'autre questions

[Maxence HUBICHE]

ce n'est qu'une redite azu1 !
Tout cela a déjà été rabaché par leVieux et moi-même (entre Autres ...)

[Beuss]

Je suis d'accord avec azu1 pour le post initial, de plus pourquoi chercher des arguments pour convaincre quelqu'un d'abandonner access si on ne connait (apparemment) pas le logiciel?

[Promesses]

Bonjour, je suis nouveau, et j'aime bien ce debat et les differents points de vues car je travaille dans une petite SSII dans laquelle je dev la majorité des applis en VBA/ access... et ca marche dans les entreprises (biensur en fonction des besoins)
Toutefois il est vrai que, quand le projet va prendre de l'ampleur, on passe a une intranetisation passant pas l'ASP 'fin bref...

On Error Goto mon_gestionnaire_erreur

C'est désespérant pour mettre au point un module de code !

En VBA (et aussi en VB ancienne mouture ) , on ne peut pas délimiter avec précision le bloc de code susceptible d'engendrer des erreurs .

Par exemple ,quelconque

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
On Error Goto mon_gestionnaire_erreur
Dim quotient as Integer
Dim resultat as Integer
Dim nombre as Integer
Dim rs as Recordset
nombre =10000
quotient=0
resultat=nombre/quotient ' erreur 1 div par zero
 
Set rs=CurrentDB.OpenRecordset("table_clients")
rs.MoveFirst ' erreur 2 : table_clients contient enregistrements ?

Comment délimiter :
* ce qui est susceptible de provoquer une division par zero
*un recordset mal initialisé

Je sais vous allez me donner 1000 réponses m'affirmant que c'est possible, que je suis un incompétent .
Mais il faut avouer que c'est au prix d'un certain "bricolage" !

C'est pourtant si simple de faire de simple tests

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
 
Dim quotient as Integer
Dim resultat as Integer
Dim nombre as Integer
Dim rs as Recordset
nombre =10000
quotient=0
 
if quotient <> 0 then
	resultat=nombre/quotient ' erreur 1 div par zero
else
	resultat = 0
end if
 
Set rs=CurrentDB.OpenRecordset("table_clients")
if rs.recordcount <> 0 then
	rs.MoveFirst ' erreur 2 : table_clients contient enregistrements ?
end if

c'est pas du bricolage, c'est de la propreté de code, parce que je pense que la gestion d'erreur doit se faire quand des tests ne peuvent plus etre faits...

Tiens ! Une autre erreur qu'on commet facilement :

Code :

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

1
2
 
Dim d1, d2 As Double

Ou est l'erreur ? d1 est un variant , d2 est effectivement un "double"

Bah c'est pas propre en VBA
suffit juste de faire

Code :

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

1
2
 
Dim d1 as double, d2 As Double

C'est pas si compliqué, fin c'que j'en dis moi....
En tout cas, je développe beaucoup en VBA/Access et je peux dire que ca marche bien dans les entreprises

[hkhan13]

hum pas mal qd meme les arguments des uns et des autres

dire qu'Access est utilisable que dans le milieu des "PME", j'ai du mal a le concevoir ca... en effet Access est present dans de nombreux milieux (SNCF, banque marché financier (back office qd meme :p), etc... etc...) c'est pas une histoire de taille d'entreprise mais de taille de projets....

(ps : financierement une PME est capable de mettre en place un projet sur n'importe quelle plate forme)


le langage de programmation, bin que tu utilises VBA, c ou Java, si tu ecris mal ton code le resultat sera le meme....
j'ai recupere plusieurs applications sous Access, certaines mal concues et d'autres (une en particularite) tres tres bien faites... c pas le langage qui fait la difference dans un programme mais le developpeur...


la gestion des erreurs : je la trouve pas mal au niveau d'access, perso je capte mes erreurs a travers un "on error goto erreur" et Erreur me renvoie a une fonction qui globalise toutes les erreurs et affiche soit un message perso soit un message Access


le gros avantage d'access est sa rapidite de developpement, ses multiples possibilites et le cout
ses defauts : bin que pour les petits projets dans lesquels la securite est pas primordiale (la securite Access existe mais ca vaut pas un vrai SGBD), pas de triggers (et ca ca m'embete)....

enfin bref, je suis pas fana d'access a 100%, mais je decouvre a travers mes differents projets dessus des choses interessante et sympa a mettre en place

[azu1]

hkhan13 j'aime bien ta façon de penser....
et je suis tout a fait d'accord avec toi.

[BisonDiligent]

Comme beaucoup d'amateurs ayant un bagage disons "semi professionnel" en informatique, j'utilise Access sporadiquement depuis des années.

J'ai réalisé quelques applications bien crasses, à usage professionnel, qui ont un premier mérite, celui de fonctionner.

Ces applications ont un second mérite : elles définissent très clairement mes besoins et ceux de mes collègues.

Si l'implémentation est loin d'être parfaite, l'analyse elle, est bel et bien terminée, et elle a été réalisée par l'utilisateur. (Recueil des besoins, analyse de l'information à traiter, conception et implémentation des fonctionnalités, critique même des défauts d'implémentation...)

Je comprends que celà horripille les "vrais professionnels", qui sont mis hors coup, et qui se prennent pour des martyrs lorsque l'on fait appel à eux pour mettre de l'ordre dans une bdd bidouillée et passer éventuellement en système client-serveur.

Je ne crois pas, pour ma part qu' Access aboutisse à une impasse.
D'abord, les données restent les données, les relations idem, et tout celà se transfère aisément, en cas de besoin, vers des systèmes plus sophistiqués si le besoin s'en fait réellement sentir. Un projet Access 2000 est conçu pour passer facilement en SQL Server.

En fait, le boulot d'un vrai professionnel n'est pas de se donner d'emblée le confort d'une solution sophistiquée, chère, et dont la maîtrise est réservée à des spécialistes (ce qui leur confère prestige, pouvoir et rénumération), mais bien de trouver la solution la mieux adaptée aux besoins et aux désidérata des commanditaires.

Je sors d'une formation ASP (pas encore .net) et je me suis posé la question suivante :

Quand Access, utilisé en réseau, commence à engorger celui-ci, pourquoi ne pas faire un grand pas en avant, et passer à un intranet? Si on place IIS et Access sur la même machine avec beaucoup de ram, ne peut-on pas de cette manière faire travailler asp + ADO + Access strictement en local? Le réseau ne véhiculerait plus alors que des pages HTML, les recordset, à peine ouverts seraient déjà refermés, limitant ainsi grandement le temps de verrouillage des enregistrements.

Ceci n'est évidemment qu'une idée, que je vais creuser dans les mois qui viennent. A vue de nez, c'est une solution qui devrait convenir pour au moins certaines applications. Elle n'est même pas incompatible avec l'usage d'access, en réseau, directement. (Comme celà, le patron, ou sa secrétaire peut toujours créer une requête d'analyse croisée et la mettre en oeuvre à la va vite, si le besoin s'en fait sentir...)

Si, dans certains cas de figure, cette solution intermédiaire pouvait réduire de moitié le traffic réseau et le temps de verrouillage des enregistrements, ce serait une solution élégante, offrant par ailleurs les avantages du système trois tiers.

Mais je pense qu'il existe aussi d'autres possibilités pour augmenter les possibilités d'utilisation d'Access en réseau, à tester au cas par cas.

- utilisation de formulaires de saisie indépendants, pour limiter le temps de verrouillage des enregistrement . Bien sur, il faut mettre du VBA derrière (et pas toujours élémentaire) simplement pour enregistrer un formulaire, ce qui n'est pas nécessaire en utilisation "classique" d'access - mais, en utilisation classique, on est en fait en transaction verrouillée pour les données du formulaire, et ce depuis l'instant où l'on a commencé à remplir un formulaire, même si on est interrompu par le téléphone (en monoposte, celà n'a aucune conséquence ...)

- windows terminal server? Avec des interfaces déportées sur le serveur (pourquoi pas une interface par utilisateur?)

- une combinaison des solutions précédentes?

J'aimerais que des professionnels me disent : j'y ai pensé, j'ai testé, celà donne tel ou tel résultat, avec telle ou telle contrainte (des contraintes, j'en voit déjà quelques-unes ...)

Comme je suis une vieille caboche, je vérifierai de toute façon par moi-même.

Merci à tous ceux qui animent le débat!

[ericdes]

J'ai realise 2 projets avec MS-Access, certains se sont passes mieux que d'autres :

(1) Projet 1 - VB5 / Access 2000 / DAO, le .mdb est sur le server et l'application est sur plusieurs ordinateurs, mais principalement utilisee par un seul utilisateur. Depuis 4 ans que l'application tourne, je n'ai rencontre aucun problemes. Taille du .mdb : 15 Mo.

(2) Projet 2 - Delphi 6 / Access 2000 / ADO. L'application est maitenant utilisee par une dizaine d'utilisateurs. Je ne cesse d'avoir des problemes, en particuliers lors des 'post', j'ai des erreurs qui ne raise rien sous Delphi, j'en suis arrive a suppose qu'elles viennent d'Access. En particulier, des enregistrements ne se font pas, des enregistrements avec une cle vide (non authorisee) apparaissent. Cela apparait pratiquement 2 fois par semaine et nous devons 'reparer' la base de donnes (heureusement, c'est automatique et il n'y a pas de donnees perdues). Taille du .mdb : 30 Mo.

(3) Nouveau projet, avec Delphi 7 et quelle base de donnees? En fait je voudrais creer un logiciel de type Ciel, et je viens de lire dans cette discussion qu'il utilise Access pour stocker les donnees. J'ai un peu peur de me trouver coince comme c'est la cas avec le projet 2, cependant l'installation transparente du serveur de base de donnees grace a Jet est un plus, et je me dis qu'Access est quand meme bien pratique. Ou existe-t'il d'autres solutions faciles a mettre en oeuvre ?

[Alberto]

Bonjour,

J'ai suivi ce débat avec attention. Etant jeune développeur et n'ayant que peu d'expérience je ne me suis donc pas permis de critiquer (positivement ou négativement) quelque avis que se soit...

Je tiens tout de même à accentuer une phrase dite par hkhan13 :

c pas le langage qui fait la difference dans un programme mais le developpeur...

Selon moi c'est un point très important que certains d'entre vous avez oublié dans bon nombre de vos messages.

Pour revenir à la question de départ, je trouve dommage que la personne ayant posé le problème ne soit plus intervenue pour nous donner plus de détails concernant le projet à affectuer.

Car si Access est déjà à disposition et que c'est un projet de petite taille (entendez par la simple dans son niveau graphique et au niveau du stockage) et bien je trouve qu'il faut le faire en access. Pas besoin de faire le truc super fou en dieu sait quelle language. Si on dispose d'outils utilisables pour le besoin en question, alors pourquoi aller en chercher d'autres ?

Enfin si l'initiateur du sujet pouvait repasser afin d'approfondir la chose, je pense que ca serrait très bien

Bonne journée à tous

PS : J'ai 25 ans et je pense que la plupart d'entre vous êtes plus agés que moi... Mais en regardant certaines réactions on croirait que vous avez 10 ans ! Arrettez de vous entretuer bon sang !!!

[hkhan13]

1) les limites d'access en terme de volumetrie ?
2) les limites d'access en terme de nombre d'utilisateur ?
3) Mr DRH toi qui a de l'experience, en moyenne quel est le budget a mettre en place pour une application viable sous Access (grossomerdo) ?
4) Quand on veut migrer de Access vers un autre SGBD est ce simple, quels sont les problemes rencontres en general (je sais cf FAQ Access) ?
...

1) ca depends de ce que tu fais de tes donnees, je pense que sur une table avec un certain nombre de champs "standard" :p tu peux aller jusqu'a 30000 lignes, apres tout depends du nombre de personne accedant aux donnees en meme temps (important ca) mais aussi du reseau en place et des machines (proc+memoire)


2) sur une application full access 4-5 utilisateurs lancant des operations en meme temps c la limite (je parle d'operation et non de lecture)


3) impossible de repondre a cette question, c'est la 4eme application que je developpe sur access et chaque fois son cout est tres tres variable... ca depends du temps de developpement et nombre de personne dessus, mais ca peut monter haut (dans le monde du service compte 450 euros /jour/personne)...donc un projet etalonne sur qlq annees....


4) je l'ai fait pour passer de full access a sql server et full access a oracle sur des projets de taille moyenne.... dans l'absolu c rapide a mettre en place et tres facile si on connait les sgbd. pour l'application sur sql, qlq semaines (mais pas tout a ete passe et ct mon 1er projet :p), sur oracle : 3 mois complets (securite, requetes, proc stock etc...). pas de gros pb insolubles a rencontrer....

[Etienne Bar]

1) les limites d'access en terme de volumetrie ?

J'ai un client qui a une table de + de 600000 enregistrements (8 rubriques) sur un réseau. Et ça répond trés bien (sauf si tu ouvres direct la table et que tu vas sur le dernier enregistrement, là évidemment c'est un peu long...).

2) les limites d'access en terme de nombre d'utilisateur ?

Je trouve que jusqu'à 10 utilisateurs simultanés, ca passe bien...

3) Mr DRH toi qui a de l'experience,

en moyenne quel est le budget a mettre en place pour une application viable sous Access (grossomodo) ?

de 2 jours à plusieurs années de développement

Sérieusement, j'ai plein de projets que j'ai réalisé en moins de 15 jours :

Exemple concret récent :
- 35 tables (la plupart très petites en nombre de rubriques)
- 105 requêtes
- 10 formulaires
- 3 Etats
- Un millier de lignes de VBA (complexes : il s'agit d'optimiser un linéaire) réécrites plusieurs fois car le client a revu plusieurs fois sa demande + réutilisation de qqes milliers d'autres (pas besoin de faire de l'objet pour réutiliser du code et/ou faire du générique)

=> Cahier des charges, analyse, réalisation, deboguage, doc (minimaliste), installation réalisée par le client = 13 jours de développement

Ca répond à ta question ?

Pour le cout tu multiplies par un coût de journée d'un développeur expérimenté (ne compte pas sur moi pour transmettre mes prix de journée sur un forum public ou alors tu demandes aux SSII de commencer) et tu as ta réponse...

4) Quand on veut migrer de Access vers un autre SGBD est ce simple, quels sont les problemes rencontres en general (je sais cf FAQ Access) ?

Oui surtout si tu utilises les fonctions de retro-conception des outils de modélisation de BdD comme Case Studio qui te permettent de concertir une structure d'une base de données à une autre. Ensuite tu lies les tables de ton SGBD par ODBC à Access, quelques requêtes ajout et le tour est joué...

desole mais la vous y avez droit, ce post est : ...

Comme à peu près toutes les enfilades où on parle de sujets un tant soit peu polémiques. Maintenant je trouve qu'il y a des arguments intéressants même s'il y a beaucoup de tri à faire. Je ne le ferais pas car je ne suis pas un censeur. Mais je respecte ton opinion...

PS : Conformément à ta demande ton message a été effacé après lecture ;-)

[Yann]

Soyons clairs:
1) Access n'est pas un SGBD: il peut donc servir à papa pour classer ses vynils, mais pas pour des applis pro !
2) Access il est à un tournant depuis la version 2000: l'introduction des "projets de données" qui permettent de lier des formulaires Acess à des données SQL Server est un aveu d'impuissance en soi !
3) comme produit commercial, Access vivra sans doute encore pas mal de temps, mais le Jet, le "moteur" d'Access ne fait plus l'objet de développement au dire de Micro$oft même: il est en fin de vie. Jet est abandonné au profit de SQL Server (sans doute en version MSDE)
4) je me suis trop pris la tronche et ai été suffisament indigné par les inepties d'Access pour donner franchement mon avis sans qu'un modérateur ne vienne (à juste titre) châtier mon langage ... Exemple d'imneptie: autoriser des valeurs par défaut sur des cllefs etrangères (eh oui, c'est possible !); les tables liées avec des chemins locaux (genre z:\MonServeur\MaBase.MDB) et non UNC; la librairie ADOX; etc.

Donc pour faire court: qu'on arrête de faire croire aux développeurs débutant qu'ils pourront coder des trucs sérieux avec Access et Jet! Et si Access se résume à des faire des fenêtres pour les lier à MSDE, je ne vois pas l'intérêt.
Pour moi, c'est mort.

[Maxence HUBICHE]

Yann =>
Ton avis vaut ce qu'il vaut.
Il n'est pas équilibré, comme pour beaucoup. Mais ce n'est pas grave. Ca arrive à tout le monde d'être extrémiste. Quand il s'agit de religion on crie haro ! Pour certain, l'informatique semble être une religion...

Tu ferais bien d'aller jeter un oeil ici :
http://www.developpez.net/forums/viewtopic.php?t=34298
Tu verrais qu'on ne juge pas la qualité d'un développement au produit, mais au développeur.

Quant à dire qu'Access n'est pas un Système de Gestion de Base de Données ... je me demande bien ce que c'est alors ... un système d'exploitation ? un tableur ? un traitement de texte ?
Vraiment, tu devrais retourner lire l'article mentionné au-dessus.

Enfin, si tu as quelque chose à dire aux développeur Access, le mieux c'est de le faire dans le cadre de l'eur enquête.
La dernière phrase de ton post précédent a été retirée.
Je pense que tu comprendras pourquoi.

[Yann]

Certes, je reconnais avoir forcé le trait et certes, les développeurs font ce qu'on leur demande de développer et je comprends que la dernière phrase de mon post, ne respectant pas les règles du forum, aie été retirée: je me suis un peu emporté .Veuillez m'en excuser. Mais après l'avoir beaucoup utilisé, j'en ai vraiment soupé d'Access !
Et je maintiens: Access n'est pas un Système de Gestion de Base de Données. Où est le serveur ? Où sont les triggers ? Où est la sécurité ? Une base Access est un simple fichier. Le SQL d'Access vous parait-il conforme aux normes ? etc.
Et je pense que ce post a sa place ici: je ne suis pas "contre" Access : il existe et est partout. Etre "pour" ou "contre" n'est pas de sens.
Ce que je dis, c'est: si MS abandonne Jet, tant mieux, mais pourquoi ne pas abandonné le produit en lui-même ? Parce qu'il est partout ? Mieux vaut développer pour MS SQL Server qui, lui, est un excellent SGBD.

[Etienne Bar]

Zemenace et moi-même sommes des développeurs indépendants (+ de 10 ans d'expérience pour tous les 2) qui ont developpé pas mal d'outils pour des boites de taille diverse avec un excellent taux de satisfaction de la part de nos utilisateurs.

Que sommes nous ?

1) Des escrocs ?
2) Des mystificateurs ?
3) Des inconscients ?
4) Des irresponsables ?

Il est de ton droit le plus strict de ne pas aimer Access. Mais ce genre de propos :

Donc pour faire court: qu'on arrête de faire croire aux développeurs débutant qu'ils pourront coder des trucs sérieux avec Access et Jet! Et si Access se résume à des faire des fenêtres pour les lier à MSDE, je ne vois pas l'intérêt.

fait que tu te poses en juge suprême des bons et mauvais produits de développement. Et il m'est très difficile de l'accepter...

[Yann]

J'ai développé avec et pour Access chez un petit éditeur logiciel qui voulait s'attaquer aux grands comptes en investissant peu et en faisant développer vite. Il a forcémennt pensé à Access. Les clients, avant d'acheter, étaient ravis: pas besoin d'acheter de serveur, des licences clients, etc. Pour la maintenance, facile: j'ouvre mes tables, je tappe dedans et je la renvoie par mail.
C'était un App distribuée qui montait vite et très fort en charge... trop vite et trop fort pour Access. Le client a vite déchanté. L'éditeur a réclamé une version SQL Server et une Oracle. C'est plus lourd, moins souple, beaucoup plus cher, etc. Mais ces SGBD sont taillés pour de grosses applis pro: pas Access. Access convient à des app moins lourdes: la grosse artillerie ne convient pas toujours; il faut savoir dimensionner.

Tu as sans doute aussi une grosse expérience sur Access et tu as sans aucun doute réussi à satisfaire tes clients avec Access: OK. Moi aussi j'ai bossé avec Access et sais pertinament qu'on ne juge pas un dév. aux outils qu'il n'a pas forcément choisi. Dans les projets sur lesquels j'ai bossé, le choix d'Access était ridicule, mais il m'était imposé.
Alors s'il t'est difficile d'accepter mon avis, c'est dommage, parce qu'à moins que tu argumentes dans le sens inverse, je garderai cet avis.
Et c'est d'autant plus dommage pour un Modé. de penser que l'on se pose

en juge suprême des bons et mauvais produits de développement

dès quon émet un avis, même très marqué, sur un produit: on pourrait le penser, mais le dire dans un forum ? Il y a pourtant un thread "pour ou contre Access", non ? Et tu modères la zone "Access", non ? Te prends-tu pour autant pour un "juge suprême" ?

Et quant à savoir :

Que sommes nous ?

1) Des escrocs ?
2) Des mystificateurs ?
3) Des inconscients ?
4) Des irresponsables ?

Je pense que tu sais ce que tu fais, puisque

Zemenace et moi-même sommes des développeurs indépendants (+ de 10 ans d'expérience pour tous les 2)

Tu n'entres donc pas dans le cas des

développeurs débutants

à qui ont ont présente Access sur le même plan qu'Oracle, ce qui relève au mieux de l'inconscience, au pire de l'escroquerie.

Alors des améliorations à apporter à Access: tu as peut-être en à soumettre à MS, j'en aurais aussi. Mais je garderai sans doute mon avis, à moins que MS ne change suffisament Access pour qu'il soit à la hauteur des présentations qu'ils en font. Quand on prétend jouer dans la cours des SGBD, donc des Oracle et SQL Server, il faut accepter d'être évalué à l'aulne des SGBD. Alors je suis désolé de t'avoir froissé, mais la comparaison ne tient pas.

[Etienne Bar]

Je suis totalement d'accord avec toi quand tu dis qu'Access ne joue pas dans le même cour que les serveurs SQL.

ont présente Access sur le même plan qu'Oracle, ce qui relève au mieux de l'inconscience, au pire de l'escroquerie.

100 % d'accord. Je ne fais pas de comparaison sur ce plan.

Ceci dit, si tu avais regardé mes interventions dans l'enfilade pour ou contre Access, tu aurais vu que je ne me permets pas de juger Access en tant que SGBD (derrière un autre outil de dev.) ce pourquoi il n'est pas un bon produit - je suis le premier à le dire - mais en tant qu'outil complet de développement. Parlons de la même chose, s'il te plait.

Et c'est toi qui te poses en juge, pas moi.
C'est toi qui pose des jugements extrêmement négatifs. Toi, tu en aurais le droit et moi non ?

Alors oui, ça m'énerve. Je suis modo, certes, mais je suis aussi professionnel et voir tirer à boulets rouges sur mon fond de commerce, ça me donne envie de réagir.

Tu peux chercher dans tous les forums, je ne me permets pas un jugement négatif et définitif sur aucun produit. A la limite, je vais dire "Je n'aime pas X" mais cela ne signifie pas pour autant que je le déconseillerai. (sauf les m****s infames et notoires mais en général ils ne survivent pas longtemps).

Maintenant quand tu argumentes et que tu décris le contexte ds lequel tu as utilisé Access, on comprend. Mais j'aurais nettement préféré que tu le fasses dès le début avant de sortir l'artillerie lourde.

Je n'essairai pas de te faire changer d'avis.

Oui, Access est une mauvaise solution pour certains besoins, je suis le premier à le dire.

Maintenant, j'attends tes propositions pour trouver un outil perenne pour de petits projets pour des petits groupes de travail avec des petits budgets.

[Yann]

que ça t'énerve quand je "tire à boulets rouges sur ton fonds de commerce", je comprends: ça m'énerve aussi quand on me le fait. Je ne veux froisser personne: je te présente donc mes excuses tout en maintenant mes points de vue. Points de vue que toi comme moi sommes libres d'exprimer, tant qu'ils ne sont pas "diffamatoires".

C'est pour cette raison que j'aurais effectivement dû exposé le contexte dans lequel j'ai développé avec Access dès le début: je reconnais que mon premier post manquait d'arguments.

Pour ce qui est de mes

propositions pour trouver un outil perenne pour de petits projets pour des petits groupes de travail avec des petits budgets.

, là, je suis forcément coincé: Access est omniprésent sur ce créneau-ci.
Mais j'ai peut-être une altenative à proposer, qui est imparable sur le plan financier: MSDE. Certes, il n'y a pas de langage de haut niveau intégré pour développer une App comme avec Access, mais là tu as un SGBD puissant pour rien.

Mais on ne va pas épiloguer sur le forum. Puisque nous habitons tous deux Rennes ou sa banlieue, nous pourrions continuer cette discussion calmement devant une bière, rue de la Soif (j'attends ta réponse par msg privé).

[Maxence HUBICHE]

J'ai développé avec et pour Access chez un petit éditeur logiciel qui voulait s'attaquer aux grands comptes en investissant peu et en faisant développer vite. Il a forcémennt pensé à Access. Les clients, avant d'acheter, étaient ravis: pas besoin d'acheter de serveur, des licences clients, etc. Pour la maintenance, facile: j'ouvre mes tables, je tappe dedans et je la renvoie par mail.
C'était un App distribuée qui montait vite et très fort en charge... trop vite et trop fort pour Access. Le client a vite déchanté. L'éditeur a réclamé une version SQL Server et une Oracle.

Ah oui, là effectivement, ca peut mettre les nerfs !
Maintenant, on en revient à ce que je disais : 'il ne faut pas juger une application au soft utilisé, mais au développeur' :
-Si tu n'as pas prévu la montée en charge, tu es en faute. Tu aurais dû.
-Si tu l'avais prévu, tu aurais dû prévenir le client. si tu ne l'a pas fait, tu es en faute.
-Si tu l'as prévu ET que tu as prévenu le client mais qu'il t'a imposé le soft, et bien tu as fait au mieux avec ce qui t'était imposé, et là, le produit n'est pas à remettre en cause.

Cordialement