Discussion :

[laffreuxthomas]

Mais je m'emporte, je m'emporte.

Bon, je résume mon point de vue :

Le positionnement d'Access en temps que plate-forme de développement :
1- Petits projets
2 - orientée non-informaticien

Concernant le point 1
C'est positif que ce logiciel soit sur ce créneau car effectivement il y a un manque. Le problème étant qu'il est impossible de continuer sur cette plate-forme si le projet grossit, ni de récupérer le travail déjà fait. L'idéal serait d'avoir une plate-forme orientée petits projets et gros projets, ou bien de pouvoir migrer les développements.

L'idéal n'existant pas encore, le choix de Access se justifie si l'on est sûr que le projet ne grossira pas.

Concernant le point 2
C'est un gros défaut. Les plate-formes de dev orientées utilisateurs ne devraient pas permettre de faire du code. J'ai cet avis bien ancré pour avoir dû reprendre des bases faites par des utilisateurs. C'est encore plus compliqué que de reprendre des fichiers Excel.

Ce défaut n'est valable que pour les bases faites effectivement par des non-informaticiens. cf échanges musclés avec Le vieux et P'tit Jean.

Bon weekend !

Thomas

[Maxence HUBICHE]

2/ prévu pour être géré par n'importe qui. Un néophyte complet peut faire sa base.

C'est justement ce que je lui reproche à ce logiciel !

Oui... Mais c'est son créneau. Si ca te plait pas, tu es hors sujet !

C'est pareil puor tout ! Si tu développes comme un goret, au bout d'un moment, il faut tout refaire !

Non, tu ne peux pas faire grossir une application créée en Access. Après le plus simple c'est de passer à VB + SQL Server. Pour les données aucun problème, c'est du relationnel on peut migrer. Mais pour les interfaces t'es bloqué. Que tu programmes bien ou non.

Mais ton programme en VB ou en C++, si tu l'as fait comme un goret, c'est le même problème.

Bouge pas, je vais te faire une sécurité Access, moi, et essaie de passer pour voir si tu y arrives !

Bien sûr que c'est mal sécurisé ! Comme pour y accéder il faut un droit de lecture/écriture direct au fichier on peut en apprendre des trucs en l'ouvrant manuellement. et on peut en faire ce qu'on veut ! Pire : n'importe quel utilisateur peut supprimer le fichier lors d'une fausse manip !!!!

Bon... là, il faut que tu apprennes 2 ou 3 trucs sur la sécurité :
1/ tu peux faire une sécurité au niveau utilisateur. Pour l'ouvrir, tu dois avoir 1 login + Password
2/ une sécurité utilisateu correctement configurée t'empèchera même d'essayer de l'ouvrir après l'avoir copié sur un support quelconque (CF la FAQ Access)
3/ tu peux coder la base, donc, même en l'ouvrant avec le notepad, tu ne lis que des hieroglyphes infames, les données ne sont plus accessibles.
4/ Tu peux supprimer n'importe quel fichier effectivement, mais là, tu entres dans la stratégie système. Empèche les droits de suppression sur le dossier ou le fichier et tu es tranquille.

Ben vaut mieux entendre ca que d'être sourd !
Il est vrai que si ton fichier est corrompu, tu vas avoir du mal à récupérer les données. Mais c'est pareil pour tout le monde. ce n'est pas propre à access. Il faut faire des sauvegardes!

Non désolé, la sécurité des données ça fait partie du rôle du SGBD. Ca n'est pas implémenté sous Access. C'est un point valable contre Access.

Un fichier foutu, c'est un fichier foutu !
S'il est illisible ton fichier de base master de SQL Server, tu fais quoi ?
Une restauration de sauvegarde.
C'est la même chose pour Access.

Microsoft t'offre de quoi te faire une base de code aussi en VBA ...

Ouaip, bah pour les compsants ActiveX on repassera. La base de code VBA c'est bien utile pour gérer des traitements métiers mais ça ne fait pas tout.

Pourquoi ? Tu ne peux pas implémenter de composants ActiveX dans ton Access ?

[Etienne Bar]

2/ prévu pour être géré par n'importe qui. Un néophyte complet peut faire sa base.

C'est justement ce que je lui reproche à ce logiciel !

Donc un utilisateur/néophyte n'a pas le droit de développer. T'as raison, si les utilisateurs développent, on est bon pour l'ANPE ;-)

Enfin, Thomas, arrêtes un peu de délirer. Si un outil peut être aussi utilisé par un non pro et un pro, alors il est forcément non pro ! Pas d'accord.

Si on pousse à l'extrême ton raisonnement, on va tous développer en C++. Au moins, là, on est sur un outil de pro, de vrai, de burné !

Oui, Access peut être utilisée par un non informaticien qui utilisera beaucoup les assistants, les macros, tous les trucs simples. Ca lui servira à affiner son besoin et à demander l'aide d'un pro pour faire quelque chose de plus complet.

Combien de projets auoujrd'hui démarrent car un utilisateur arrive aux limites de ses bidouilles et qu'il y a un besoin de professionnalisme pour passer à la vitesse supérieure ? Et là, que tu développes avec Access, VB, Delphi, Java, XYZ+++, c'est une question de contexte, de budget, d'environnement, ça n'a guère d'importance puisqu'il faudra tout refaire !

Dans mes interventions ds les PME, il est plus facile de démarrer un projet quand l'utilisateur a commencé quelque chose. Et quand il voit ce que je fais par rapport à ce qu'il a fait, il voit tout de suite la différence !

Comme le dit notre gourou Access ;-) "ZeMenace", il faut prendre Access pour ce qu'il sait bien faire. Et je juger dans ce contexte...

[SQLpro]

ZeMenace, nous raconte :

Points positifs d'access :
1/ Un seul Fichier : Facile à transporter. Facile à repérer, ...

Comme la plupart des GGBDR C/S

2/ prévu pour être géré par n'importe qui. Un néophyte complet peut faire sa base.

Comme certains SGBDR : FoxPro, Approach, Paradox, dBase, BTrieve, MySQL

3/ De nombreux assistants pour l'aider

Comme de nombreux autres produits ! Paradox, dBase, MySQL, MS SQL Server

4/ 2 moyens de programmer (macros et VBA)

Oui mais cele est une hérésie on ne mélange pas les applications et les données !

5/ VBA = Base du langage VB. Implémentation des classes et génération d'objets à partir de ces classes.

Abandonné par Microsoft...

6/ Capacité d'utiliser des fonction personnelles (VBA) dans les requêtes

Parce que les fonctions de base de la norme SQL n'y sont pas et que les fonctions dans Access ne sont pas normalisée

7/ RAD

Là tu parle de developpement cela n'a rien à voir avec un SGBDR !

8/ Pas d'obligation d'avoir access sur un poste pour utiliser une base Access (Run-Time/Exe/Intranet/Internet/...)

et si toute une enfilade de joli fichier et un run time MS !

[/quote] Tout ca pour montrer que c'est trop facile de crier sur un produit sur Access : il est sur un créneau sans opposant réel, c'est à dire le SGBDR pour petits projets avec peu d'utilisateurs.
[quote]

Non, pas le seul : FoxPro, Approach, Paradox, dBase, BTrieve...

Et l'un des plus mauvais, parce qu'au dela de 300 Mo de données et 3 utilisateurs les performances sont lamentables alors qu'avec paradox par exemple on arrive sans peine à 25 utilisateurs et plusieurs Go de données...

[Etienne Bar]

Non, pas le seul : FoxPro, Approach, Paradox, dBase, BTrieve...

T'as oublié FileMaker.

Les produits que tu nous cites sont il perennes ? La plupart sont en fin de vie. On va pas développer sous Dbase en 2003, saperlipopette ! Fais un sondage : qui connait aujourd'hui l'éditeur de Paradox ?

Oui mais cele est une hérésie on ne mélange pas les applications et les données !

Et quand tu écris une procédure stockée, c'est pas de l'applicatif ?

Et l'un des plus mauvais, parce qu'au dela de 300 Mo de données et 3 utilisateurs les performances sont lamentables alors qu'avec paradox par exemple on arrive sans peine à 25 utilisateurs et plusieurs Go de données...

Parce qu'il n'est pas fait pour ça, point final ! Et je continue à dire que tu ne veux voir que la Base de Données là où il y a un SGBD ET un outil RAD en un seul produit.

Et avec 300 Mo de données ET + de 3 utilisateurs, t'utilises pas Access. Comme tu ne vas pas prendre Oracle et Java pour gérer 1000 adresses de prospects.

[Maxence HUBICHE]

et paf !

[bebeours]

Je vais essayer d'apporter mon avis dans ce débat fort intéressant.

Déjà je ne comprends pas pourquoi vous comparez Access à Oracle ou SQL-Server. Access n'est pas un SGBD, et Microsoft n'a jamais présenté cet outil comme un SGBD. C'est SQL-Server le SBGD de Microsoft.

Un SGBD doit assurer les fonctions suivantes :
- indépendance physique
- indépendance logique
- manipulations des données par des non informaticiens
- efficacité des accès aux données
- administration centralisée des données
- non redondance des données
- cohérence des données
- partageabilité des données
- sécurité des données
- résistance aux pannes (très important)

Access n'assure que très peu de ces fonctions car ce n'est pas un SGBD.

Access répond à un besoin chez les particuliers ou les très petites entreprises pour stocker des données sous forme de fichiers. Et c'est tout ce qui faut lui demander car il reste très limité.

[Maxence HUBICHE]

Access n'est pas un SGBD

Ben c'est quoi alors ?
Il me semblait qu'il s'agissait d'un soft gérant des bases de données.
Moi, je fais : Fichier/Nouvelle Base de données. Et c'est Access qui gère ça, en pilotant le moteur JET, moteur de base de données.
Si donc Access gère les bases de données... c'est un Système de Gestion de Bases de Données.
Et comme dans ces bases il y a relations/Intégrité référentielle/..., on peut même parler de SGBDR

[bebeours]

On est seulement pas d'accord sur la définition d'un SGBD, c'est tout. Moi je me base sur la définition de Gardarin qui est quand même la référence en la matière.

Si pour toi un SGBD c'est un système qui stocke des données seulement et bien Access est un SGBD.

[Maxence HUBICHE]

SGBD : Système de Gestion de Base de Données. C'est un outil informatique qui permet d'insérer, de modifier et de rechercher efficacement des données spécifiques dans une grande masse d'informations partagées entre tous les utilisateurs. Il comprend un ensemble de données liées (la BDD), et un ensemble de programmes permettant de manipuler et d'accéder à ces données. Il doit aussi assurer le contrôle, la sécurité et la confidentialité des données.

Définition d'un dictionnaire informatique

[bebeours]

Donc Access n'est pas un SGBD :
- il ne permet pas de rechercher efficacement des données dans une grande masse d'informations (indexation des données assez lamentable)
- il ne permet pas de partager ces informations entre plusieurs utilisateurs (pas de gestion des transactions, d'accès multi-utilisateurs, etc ...)
- il ne permet pas la sécurité des données (résistance aux pannes, journalisation, gestion pointue des droits ...)

cqfd.

A noter que cette définition d'un SGBD est très incomplète.

Bien évidemment Access convient à un certain profil d'utilisateurs qui n'a pas besoin de faire une utilisation avancée des BD.

[Maxence HUBICHE]

- il ne permet pas de rechercher efficacement des données dans une grande masse d'informations (indexation des données assez lamentable)
- il ne permet pas de partager ces informations entre plusieurs utilisateurs (pas de gestion des transactions, d'accès multi-utilisateurs, etc ...)
- il ne permet pas la sécurité des données (résistance aux pannes, journalisation, gestion pointue des droits ...)

Bon même si tu n'es pas loin, revois ta copie sur Access, parce que tu as des progrès à faire au niveau connaissance...

"rechercher efficacement " et "grande masse d'informations"
Par rapport à quoi tu te bases ?
Tu peux faire des recherches efficaces dans 100000 lignes ! Compares avec Excel et tu verras que c'est efficace !
Fais une recherches sur un champ indexé et sur un champ non indexé et tu verras la différence !
Maintenant, si tu compares avec SQL Serveur 2000 ou Oracle 8, oui, le volume de données est négligeable. Mais à ce moment, SQL Serveur 6 n'était pas un SGBD à côté d'Oracle ! c'est pareil !

ne permet pas de partager ces informations entre plusieurs utilisateurs
Alors là tu es complètement dans le ridicule ! Access est nativement en accès multi-utilisateur. Il faut que tu demandes spécifiquement pour avoir un accès exclusif à ses bases ! Les requêtes sont transactionnelles d'office, et le moteur Jet supporte pleinement la notion de transaction. il faudrait arréter de raconter n'importe quoi !

il ne permet pas la sécurité des données ...gestion pointue des droits
Tolérance aux pannes minimes effectivement. Mais tu peux réparer une base de données Access quand même. Journalisation : Aucune. Et MySQL ? PostGreSQL ? Paradox ? non plus. Ce ne sont donc pas des SGBD. Ridicule !
Pour ce qui est de la gestion des droits... va te rhabiller ! C'est du mensonge. Je t'empèche de rentrer dans une base de données quand je veux !
Ou encore, je vais te permettre d'entrer sans pouvoir utiliser quoi que ce soit, ou seulement une ou quelques tables, ou aucune table, mais des requêtes sur ces tables, ou ..... et je peux même t'empécher de créer des tables quand tu es dedans. Alors ne viens pas raconter une telle ineptie s'il te plait !

comme je disais, revois ta copie.

et puisque tu aimes les citations d'autres intervenants, je te citerai SQLPro, qui est lui aussi éditeur et une réfrence dans le dommaine des SGBDR :
http://www.developpez.net/forums/vie...=258731#258731

Bonne lecture !

[bebeours]

Je rappelle que developpez.com est une "association d'entraide" et que le forum est un forum de discussion. Donc ce n'est pas la peine de m'enfoncer ni d'être agressif dans tes propos (je te sens à la limite des insultes).

Concernant SQLPro, je suis d'accord avec lui : Access est le plus mauvais des SGBD (et je n'ai rien contre Microsoft, j'utilise SQL-Server). Alors pourquoi utilises-tu Access alors qu'il y a mieux à moins cher ?

Je ne prétends pas avoir raison ... je le redis : je ne prétends pas avoir raison. Je défends mon point de vue. C'est tout. J'essaie d'apporter des arguments. J'ai utilisé Access pendant des années, je suis passé à un SGBD (PostGreSQL et Oracle) et personnellement (je répète personnellement c'est à dire qu'il ne faut pas que tout le monde se mette à PostGreSQL ou Oracle) je reviendrai pas à Access.

Et heureusement que tous les développeurs n'utilisent pas le même SGBD car sinon ce serait très ennuyeux. Et heureusement que tous les développeurs ne sont pas d'accord entre eux car sinon ça avancerait pas (si tu n'acceptes pas que d'autres n'est pas le même avis que toi c'est assez grave). Et heureusement que je n'ai pas la science infuse.

Alors comme il n'existe pas de définition universelle d'un SGBD, je veux bien considérer Access comme un SGBD.

[Maxence HUBICHE]

A la limite des insultes !!!
Jamais !
Mais j'ai du mal quand on raconte n'importe quoi en en faisant des affirmations.
Oui, il y a mieux qu'access.
Oui, il y a moins bien aussi.
Oui, il y a moins cher qu'Access.
Oui, il y a plus cher aussi.
Access est un super produit quand on cherche à l'utiliser pour ce en quoi il a été prévu.
Il gère des bases de données relationnelles de manière suffisamment solide pour des projets de petite taille, pour de petits groupes d'utilisateurs, avec toute la sécurité voulue. C'es, en plus un logiciel RAD, qui permet de monter rapidement une application fiable.

J'utilise aussi SQL Serveur et MySQL(depuis peu)
Je ne vois pas l'intérêt d'utiliser SQL Server sur des projet de 10000 lignes !
Je développes 'tout en un' avec Access, c que je ne peux pas faire avec MySQL. Et MySQL est largement plus limité qu'Access au niveau de son SQL. Mais c'est vrai qu'il est gratuit.

Je ne suis pas contre le fait qu'on défende son point de vue.
Je n'ai jamais rien dis dans cette enfilade quand des vérités négatives ont été prononcées à l'encontre d'Access. Mais crier Haro! contre un logiciel performant 'parce qu'on a dit que...' ou 'parce qu'il me semble que...', ça, oui, ça m'irrite.
Avant de faire des affirmations, je vérifie ce que je dis.
C'est tout.
Excuses moi si je t'ai blessé. Là n'était pas mon intention. Mais tu as fais une telle enfilade de bétises, de mensonges sur ce produit, que j'ai vraiment été énervé.
C'est l'attitude qui m'énerve (affirmer des abhérrations comme étant des vérités). Pas la personne, ni la volonté de penser différemment de moi. Chacun est libre de penser ce qu'il veut. Mais pas d'induire en erreur. surtout sur un forum d'entraide justement.

[Etienne Bar]

On se calme, on se calme... On est pas en train de parler politique !

Je pense connaitre bien Access (une vingtaine d'applis développées en pur Access depuis 1995) et la plupart des critiques qui lui ont été adressées dans ce post sont soit inexactes, soit mensongères, soit non fondées car on ne compare pas les mêmes choses.

Je vais me répéter : je suis en train de passer à Delphi-Interbase (pour des raisons de volumes de données et de nombre d'utilisateurs) et c'est vrai que c'est complétement bluffant en terme de puissance mais aussi de complexité. Mais s'il faut tenir compte du temps d'adaptation et d'apprentissage, je constate aussi qu'il me faut beaucoup plus de temps pour gérer ds mon code ce qu'access fait tout seul et automatiquement de façon fiable.

Dans les limites de volumes raisonnables, je ne vois pas aujourd'hui de produit permettant de développer une appli avec de bonnes fonctionnalités aussi rapidement. Et ne venez pas me parler de produits aujourd'hui morts ou moribonds. Access à + de 10 ans et je ne pense pas qu'on arrétera de développer avec demain !

ZeMenace, ô mon maître, tu n'es point seul face à l'adversité !

[laffreuxthomas]

En fait il y a deux débats :

* Access pour du stockage de données
* Access comme plate-forme de développement

Les interventions récentes ne m'ont pas fait bouger d'avis depuis mon dernier messages. Donc pas de réponses. Par contre j'ai des questions :

Stockage

Juste deux petites choses, car peut-être ne suis-je pas à jour et en fait ça m'intéresse :

Les requêtes sont transactionnelles d'office, et le moteur Jet supporte pleinement la notion de transaction.

Est-il possible de faire un ensemble de traitements au sein d'une transaction ? Ou bien c'est juste un équivalent auto-commit ?

Ou encore, je vais te permettre d'entrer sans pouvoir utiliser quoi que ce soit, ou seulement une ou quelques tables, ou aucune table, mais des requêtes sur ces tables, ou ..... et je peux même t'empécher de créer des tables quand tu es dedans. Alors ne viens pas raconter une telle ineptie s'il te plait !

Normallement la sécurité est gérée par des administrateurs, ces derniers ne savent pas tjr programmer. Tu me diras, pour des petits projets dans des petites boîtes il n'y a pas d'administrateurs. Quand même, est-il possible de gérer la sécurité autrement que pas programmation ? (création de comptes utilisateurs, affectation des droits, etc..)

Développements

Microsoft t'offre de quoi te faire une base de code aussi en VBA ...

Ouaip, bah pour les compsants ActiveX on repassera. La base de code VBA c'est bien utile pour gérer des traitements métiers mais ça ne fait pas tout.

Pourquoi ? Tu ne peux pas implémenter de composants ActiveX dans ton Access ?

Est-il possible de créer un composant ActiveX dans Access ? Si oui, quel est la procédure à suivre ?


Et un dernier détail, c'est pas une question c'est un conseil :

Oui mais cele est une hérésie on ne mélange pas les applications et les données !

Et quand tu écris une procédure stockée, c'est pas de l'applicatif ?

Je ne sais pas ce que vous appelez applicatif, mais si c'est pour du métier je ne suis pas d'ac. Dans les procédures stockées et triggers il ne faut pas mettre du traitement métier ! C'est fait pour faire des requêtes en plusieurs étapes, pour contrôler plus finement les droits, pour optimiser certains temps de réponse, etc.. Pour palier aux limitations du SQL en définitive. Surtout ne mettez jamais rien de compliqué là-dedans ! Ce sont des langages de programmation très limités, on est dans le procédural jusqu'au cou.

Mais je sais c'est hors-sujet ;o)

Bonne soirée !

Thomas

[Maxence HUBICHE]

Transaction.
Les requêtes
Fais une requete de suppression basée sur une table 'parent' liée à une table 'enfant' avec intégrité référentielle appliquée.
Supprime toute les donnée (exemple 2000).
Il va te dire : Vous allez supprimer 2000 lignes êtes-vous sûr ? =>Oui
Message : Impossible de supprimer 1993 enregistrements. Continuer ?
Si oui = > Commit
Si Non = > RollBack

Le Code
BeginTrans
Commit
RollBack

Sécurité niveau utilisateur
Regardes dans la FAQ Access. le sujet a été abordé clairement.
Pas de programmation du tout.
Il faut avoir les droits d'Administrateur pour gérer les droits.
Mais dans le cadre d'une base de données, c'est le DBA qui gère ces droits. Pas l'administrateur système.

Activex
Créer un Composant ActiveX... non
Utiliser des ActiveX créés par ailleurs... oui. C'est d'ailleurs quelque chose de courant que la dll Activex dans le VB qu'on réutilise comme composant COM dans Access. Ou un controle ActiveX. je viens de réaliser un mini editeur Web pour remplir des champs avec du HTML par exemple.
Créer des compléments à Access... oui

Ce sont des langages de programmation très limités, on est dans le procédural jusqu'au cou
on ne partage pas le même point de vue sur cette assertion.

[laffreuxthomas]

ok merci pour ces infos

Je parlais de l'administrateur base de données et non de l'administrateur système bien sûr ;o)
Oui c'est vrai que les dba savent programmer des proc stockées.

a+

[Maxence HUBICHE]

pour la sécurité sur access : interface graphique. Donc, même pas de procédures stockées.

[mvg]

sorry
Ce n'est pas gout du jour de dire du bien des produits MS mais il faut rendre à césar ce qui lui appartient.
Access utilisé dans le créneau où il 'est inséré( sgdb fichier dans une suite bureautique) est un très bon produit qui , en dehors de filemaker , lui aussi en perte de vitesse comme paradox) n'a d'ailleurs plus de concurrent sérieux.Ce n'est pas un hazard.