Discussion :

[Papy Turbo]

J'en profite pour poser une question, concernant peut être la nouveauté Access 2003 : Propagation des propriétés de champ

Lorsqu'on modifie le nom d'un champ, Access 2000 (ou XP ?) le modifie en cascade dans les requêtes... très bien, mais il ne franchit pas la barrière entre le fichier de "base de données" (qui ne contient que les tables) et le fichier "Application" (qui contient tout le reste).

Il arrive très souvent qu'on ait à corriger le nom d'un champ, ou que l'on conseille, dans ce forum, à quelqu'un de renommer un champ baptisé [Nom] !! Et de lui dire de revoir ses tables, toutes les requêtes, contrôles de formulaires et d'états, nom du contrôle dans les évènements et le reste du code... galère instructive, mais galère quand même !

Est-ce qu'Access 2003 va plus loin, à savoir : mettre à jour le nouveau nom d'un champ, non seulement dans le ficher "base de données", mais surtout dans l'application (requêtes, formulaires, états, pages de données...) :

Ne me réponds surtout pas que c'est impossible . Dans la base de données qui contient les tables, il y a une trace de chaque mise à jour de nom, enregistrée dans une table (dont j'ai perdu le nom). Access pourrait, dès qu'il y a des tables attachées dans un fichier "Application", vérifier l'existence de cette table, y touver l'ancien nom et le nouveau, nous demander si il doit faire la mise à jour, et, si oui, continuer cette mise à jour sur les objets de l'application... :o

[ypicot]

d'aller jeter un oeil aux nouveautés de la version 2003, puis d'exprimer ce qu'on en pense (bon ou mauvais)

Nouveauté appréciable mais à mon sens non finie : la propagation des propriétés. Bêtement, je m'attendais à ce que cela propage aussi les modifications de nom de champs.

A noter également : il suffit de renommer une table pour qu'Access perde le fil de ses dépendances (le bon coté des choses, c'est qu'il ne se laisse pas perturber par une recopie de table. En fait, il faudrait la aussi pouvoir choisir : veut-on une dépendance par nom ou par un indentifiant interne ?)

(ces deux points auraient été très pratiques pour redresser un peu une base que l'on reprend et qui ne respecte aucune règle de nomage)

réussir à exprimer les éléments qu'on souhaiterait voir apparaitre dans les futures versions.

Comme Papy Turbo, avoir une trace imprimée des dépendances pourrait être très utile (depuis le temps, je me suis fait un truc rapide en python, mais j'espère bien que MS fera mieux et plus esthétique)

J'apprécierai également d'avoir un générateur de d'expression à la Excel, parce que celui d'Access a tendance à me filer des boutons (mais c'est perso) : un double-clic mal placé et on a une floppée de [censure] qui viennent poluer notre belle expression.
(concernant le générateur d'expression, je ne sais plus si dans la version 2003 on a possibilité d'accéder à l'aide d'une fonction, ou si on a -comme dans 2000- une "aide" sur le générateur lui-même)

Mais en fait LE point que j'aimerai voir apparaitre est une base mixte MDB-ADP :
le vrai client-serveur avec procédure stockées et déclencheurs de ADP
la souplesse des tables et requêtes locales de MDB

Exemples d'utilisation :
** les données dynamiques (client, stock, ...) sont sur le serveur
les tables statiques (liste des codes postaux avec bureau distributeur, catalogue, ...) sont en local
=> plus de pb de charge réseau pour alimenter une liste déroulante ou autre

** pour des raisons stratégiques, je n'ai pas le droit de créer une table sur le serveur => je créé une table tampon en local, dans laquelle je prépare tranquillement les données qui vont alimenter mon état, sans aller f*utre la m*rde sur le serveur.

** J'ai besoin de laisser les utilisateurs créer eux-même leurs requête : ils interrogent les bases du serveur (en lecture seule, oeuf corse) dans un environement sympa que sont les requêtes MDB qu'ils connaissent.

C'est tout pour aujourd'hui

Yvan

[jab]

Je n'ai pas encore eu beaucoup de temps por tester la version 2003 mais une chose est sur, la compatibilité ascendante n'est pas assurée. J'ai une application avec une librairie mde ou est stocké la majorité des fonction de l'application car par un système de création, j'ai des centaines de bases différentes mais qui utilisent toutes la même application via une seul mde donc quand je modifie la mde mes databases sont automatiquents adaptées. Seul une petite partie du code n'est pas modifiable ainsi car il se trouve dans les databases de données.
Le problème c'est qu'entre access97 et access2003, le comportement a changé. Je m'explique, avant si vous appeliez une fonction dans la db de donnée et que celle-ci se trouvait dans la librairie, la fonction recherchait par défaut les forms et autres dans la libraires et il fallait programmer pour définir le chemin vers les données. Ce qui fut fait. Aujourd'hui c'est juste l'inverse
Je pense que c'est bien plus logique mais cela ne marrange pas vraiment.

[Maxence HUBICHE]

Le problème c'est qu'entre access97 et access2003, le comportement a changé. Je m'explique, avant si vous appeliez une fonction dans la db de donnée et que celle-ci se trouvait dans la librairie, la fonction recherchait par défaut les forms et autres dans la libraires et il fallait programmer pour définir le chemin vers les données. Ce qui fut fait. Aujourd'hui c'est juste l'inverse
Je pense que c'est bien plus logique mais cela ne marrange pas vraiment.

euh ... tu n'as jamais utilisé CodeDB ??? et CurrentDB ???

[jab]

J'utilise CurrentDb dans ce programme mais pas CodeDb. Actuellement, je suis sur un autre projet mais dès que je reprend celui la, je vous tiens au courant du problème exacte qui affecte le programme. Le fait reste néanmoins que la portabilité ascendante n'est pas assurée. Mais c'est malheureusement souvant le cas

[Maxence HUBICHE]

si tu utilisais CodeDB et CurrentDB, le problème que tu décris n'existerait pas.
En 2003, tu travaille aussi naturellement sur une base au format 2000 que XP.
Alors question compatibilité, .... moi je trouve qu'il y a un effort énorme.
Il suffit de regarder ce qui s'est passé jusqu'à présent. Depuis 2000... 0 problème, si les bases sont correctement développées

[Arkal]

Je suis d'accord avec plusieurs idées de modifications à apporter, par contre, il y en a une qui je crois n'a pas été mentionné, la coloration syntaxique quand on edit une requete en mode SQL parce que lorsqu'on a de très grande requete, c'est horrible, illisible....

[Papy Turbo]

Une autre 'nouveauté' qui me tracasse depuis longtemps, et que j'aimerais bien voir un jour dans Access :
- Chaque contrôle dispose bien d'un évènement MouseMove qui permet de détecter que la souris passe au dessus, + indique sa position exacte...
- Par contre, c'est une galère sans nom de détecter la sortie de la souris (évènement MouseOut() ?) : si tu as, pendant l'évènement MouseMove, changé quoi que ce soit (pointeur de la souris au dessus de ton split-bar, par exemple, ou couleur du contrôle), comment tu fais pour remettre la propriété 'standard', lorsque la souris va faire un tour ailleurs ???

Il m'arrive de m'en tirer en remettant un appel de fonction dans chacun des évènements MouseMove
- du formulaire lui-même (pas très utile),
- de chaque section,
- de chaque autre contrôle.
C'est une vraie galère, et ça ne marche même pas,
1- si la souris se barre à 200 à l'heure, style Speedy Gonzales : les évènements Mousemove des contrôles survolés trop vite ne se déclenchent jamais.
2- si elle sort en passant par dessus un des ascenseurs (vertical ou horizontal) : il n'y a aucun moyen de détecter les 'Ascenseur_MouseOver()'.

Je me suis aussi demandé si une propriété 'MousePreview' du formulaire, de même style que la propriété KeyPreview (Aperçu des touches) ne résoudrait pas ce problème (et quelques autres...) : si on a, à tout instant, la position de la souris dans le formulaire + la posiiton de chaque section (on a ça ) et celle de chaque contrôle (on a aussi ), ça permettrait beaucoup...

J'aimerais aussi, sur le même sujet :
- une propriété 'MousePointer' comme il y en a dans les contrôles des Windows Forms,
- savoir si la compatibilité de ces objets Windows Forms a fait des progrès : il m'est arrivé d'inclure une étiquette (label) 'Windows forms' dans un formulaire Access, juste pour profiter de sa propriété MousePointer. Au 3ème plantage irrécupérable de ce formulaire, j'ai laissé tomber... Dommage.

Également, un ou des évènements concernant Access lui même en tant qu'application (comme on peut le faire avec Excel ) et notamment un évènement Application_Quit(Cancel As Integer) : combien sommes-nous à se créer un formulaire caché dont la fermeture veut dire que l'utilisateur a fermé son appli ... ? On pourrait faire beaucoup + simple.

[FRED.G]

Papy Turbo +1 (surtout pour la gestion des événements souris, le pire étant pour moi l'effet Speedy Gonzales... )

[Maxence HUBICHE]

recu par mail :

J'ai quelques remarques concernant votre article concernant les nouveautés d'Access 2003

- Un fameux bug qui date d'Access 2000 n'a toujours pas été réglé
Access perd fréquemment les marges dans les états et les remet à 1 pouce
sur les 4 bords (il faudrait peut être prévenir Microsoft qu'en France nous travaillons en cm)
- Amélioration du tri dans l'assistant recherche
je pense que c'est une très bonne amélioration
l'assistant permet à des novices (je fais entre autres des formations Access)
de créer en quelques secondes une recherche dans un formulaire et jusqu'à présent
il était toujours nécessaire de retourner modifier la requête juste pour rajouter le tri
Par contre, cet assistant a un bug toujours non réglé, à la fin il demande la légende à afficher
et il change aussi le nom du champ
- La propagation des modifications d'un champ d'une table dans les formulaires et états
cette fonction est intéressante mais en fait elle ne sert à rien car la plupart des bases
sont développées en 2 parties : 1 base avec les tables,
et une autre avec des liaisons de tables et le reste (requêtes, formulaires, états, ...)
- Options de correction automatique
fonction très intéressante mais dangeureuse dans certains cas, 1 exemple concret qui nous est arrivé
1 application qui fonctionne en Access 97 depuis plusieurs années
gestion de personnel à des emplacements (dont 1 emplacement nommé "Chateau" sans accent)
Installation de Word XP ou 2003 sur le poste qui active la correction automatique de tout Office (toutes versions confondues)
Si l'on veut extraire les personnes affectées au Château, il n'y en a pas, et il est très difficile de retapper Chateau sans l'accent
Donc la fonction est très intéressante si la base n'est pas créée avant
- Point de vue sécurité
Intéressant également, mais Office 2003 a fait planter pas mal de programmes qui faisait du publipostage, des exports par OLE, ...
en considérant tout programme non signé comme potentiellement un virus
La fonction est intéressante, mais il est à regretter que cet ajout ait été fait unilatéralement et que l'assistance Microsoft sur ce point
considère cela comme normal, et qu'il compte cette intervention dans le contrat (ils nous ont quand même annoncé
qu'il s'agissait d'un bug)
D'autre part, au niveau de la sécurité d'Access, les bases ne sont malheureusement pas sûr, car il existe de nombreux outils
de décryptage des mots de passe...

Conclusion : il y a en effet nombres d'améliorations au niveau d'Access, mais celles attendues depuis fort longtemps sont toujours
en attente

Frédéric PANNETIER
Responsable bureau d'études

Allez allez !
Encore quelques jours pour vous défouler ...
Ensuite, je fais un paquet cadeau et ... comme je serai chez MS les 2&3 nov prochain, on va pouvoir faire passer le relai

[Tofalu]

A noter aussi que la version 2003 corrige l'essentiel des bug relatifs à la mise en forme conditionnelle.

En tout cas, j'aime bien cette version

[mvg]

le vrai problème ,d'access est sa fragilité dans un environnement réseau.
Je suis convaincu que microsoft a les clès pour améliorer cela mais il est évident que rendre access performant dans un environnement multi-utilisateurs est du cannibalisme (SQL SERVER).avec ube interface en delphi et ADO j'ai poussé des appli à plus de 25 utilisateurs sans problèmes dans un environnement d'os homogène (win98)(plus de 50.000 enregistrements).Les problèmes viennent maintenant essentiellement de l'hétérogénéité des OS et surtout de win 2000 et de l'opportunistic locking.C'est un problème bien connu de MS mais qui ne fait rien pour le résoudre.

[DMboup]

Je n'est personnellement pas encore tester le v 2003 mais l'intérêt d'un tel débat doit permettre d'orienter MS vers une nouvelle version pour les développeur.

L'idée de Access à 2 vitesse n'est pas mal et si les remarque et suggessions exprimées ici sont recensées et transmises à MS, nous sauront les vrais ambitions de MS pour Access.

J'ai enfin une remarque qui n'a peut être pas sa place ici. j'utilise très souvent les fonctions FORMAT(), DLOOKUP, IIF, et Date().

En déployement chez le client je suis obligé de changer quelques fichiers ocx et dll sourtout IMGADMIN.ocx, XMSCONF.ocx et MSIAV.ocx.

Sous Win 98 et XP j'ai moins de problème mais avec Win 2000 aucune des fonctions citées en dessus ne marche.

[dadas]

Mais je tenais à remercier toutes les personnes qui nous on aidait en cours quand on galèrait avec access.

Non sérieusement je crois que c'etait notre prof qui etait naz

[naphta]

J’ai testé 2003. J’ai cherché les nouveautés, dans access, puis j’ai fini par les trouver ici (sur internet)
Les activex n’ont pas bougés depuis 97 et ça me fait, non c’est dommage, mais bon je le trouve l’ergonomie générale plus jolie.
Si je me trompe sur les activex .. qu’une personne me rencarde sur des choses nouvelles autour des activex de production (grid, flex, listview).

Pour le reste des réactions hors sujet, Access reste un rad, une lime une lime un marteau un marteau à chaque outil son utilisation.

[snoopy69]

Bonjour à tous ...

Je n'ai pas vraiment lu ce qu'il se disait dans les postes précédents mais j'aimerais donner mon avis sur Access.

J'ai utiliser Access pour de petit projet tel que :

Gestion de bibliothèque,
Gestion de cd,
Gestion de dvd,
Gestion d'une école secondaire de 150 élèves,
Gestion de machine ( projet pour une entreprise )
Gestion de ressources ( ordinateur, imprimante, etc ... )

J'aimerais dire que Acces s'adapte très bien pour les petits projets que j'ai cité ci-dessus. Pour les personnes qui débutent dans ce logiciel, cela n'est pas vraiment compliqué, il faut néanmoins s'appliquer dans ce que l'on fait.

J'aimerais juste dire que Access est très pratique d'un point de vue graphique ... si je dis cela c'est pour le projet que j'ai fait pour une entreprise qui était de gérer les machines en y incorporant une insertion des données automatiques à partir de fichier *.dnc qui correspond à des fichiers *.txt ( d'ailleurs merci à toutes les personnes qui m'ont épaulé pour ce projet ).

Pour moi Acces n'est pas le meilleur moyen de gèrer une base de données mais pour les petits projets c'est le logiciel parfait qui est incorporé dans la suite Office ...

Voila vous avez mon avis personnel sur Access ...

Je vous dit à bientôt et merci pour permettre de donner son avis sur un thème général.

[Gaby presta]

j'admire les ajouts de Access 2003, seulement je deplore l'absence de Triggers. quand pensez-vous ajouter cet outil puissant, ou alors allez-vous nous laisser conclure qu'Access n'est pas un SGBD comme la majorité le prétend déjà?

[osia1]

Je te confirme que access n'est pas un SGBD comme les autres étant donné que c'est un SGBC client alors que la plupart des SGBD (postgreSQL, easyphp, oracle ... pour ne citer qu'eux) sont des SGBD Client/Serveur.
De plus niveau sécurité access 2003 est une vrai passoire... les mot de passe d'accès ne sont pas crypté, on ne peux pas limiter l'accès, c'est à dire tout le monde peut modifier la base par elle même, de plus les types de qu'utilise access ne sont pas conforme au SQL. En gros access 2003 pratique pour une toute petite entreprise n'ayant pas de données trop sensible sinon s'orienter vers autre chose....