Discussion :

[Maxence HUBICHE]

ACCESS 2003

Access 2003 est sorti depuis peu, avec une batterie de nouveautés.

Certaines me semblent utiles, d'autres moins.

Voici l'essentiel de ces nouveautés
- Sauvegarde d'une base de données
- Dépendances
- Propagation des propriétés
- SmartTags dans les champs
- Correction automatique
- Prise en charge duXML
- ...

La lecture de ce document vous en donnera un point de vue exhaustif.

Le sujet de ce débat est la réponse à ces trois interrogations :

Que pensez-vous de ces avancées dans le logiciel ?
Qu'auriez-vous attendu de plus à ce sujet ?
Quelles orientations devrait prendre Access, à votre avis, dans l'avenir ?

C'est avec impatience que nous attendons vos avis éclairés.
Soyez clairs et précis.

Nous nous proposons de remonter la synthèse de vos avis directement à Microsoft.

Alors, maintenant, c'est à vous

[mat.M]

Puisqu'on peut donner son avis : :
( je ne suis spécialiste que d'Access 97 et 2000. Donc il se peut que je commette des erreurs d'appréciations ne connaissant pas les versions ultérieures )

Voici l'essentiel de ces nouveautés
- Sauvegarde d'une base de données

Ok mais qu'en est-il de la gestion des numéros de version ??
Si on sauvegarde à un instant T1 et un autre T2 , est-ce qu'il ya un méchanisme pour gérer cela sans s'y mélanger les pinceaux ?

- Dépendances

TRES bonne chose !!! Mais "dépendances" est-ce contrôles Active X inclus dans formulaires ??

- Propagation des propriétés

Très bien

- SmartTags dans les champs

Bof ...est-ce vraiment utile ?

- Correction automatique

Correction de la syntaxe des chaînes de texte comme dans Word ?
Vraiment utile aussi ???

- Prise en charge duXML

Très bien.

Que pensez-vous de ces avancées dans le logiciel ?

Très bien .


Qu'auriez-vous attendu de plus à ce sujet ?

hé hé : à quand Access multi-utilisateurs ?? ( sempiternelle question ).
Logique commerciale : on démarre des projets avec Access , on se rend compte après que c'est "un peu juste" comme SGBD et on est obligé d'investir dans SQL-SERVER ???
L'éditeur est-il conscient de la concurrence d'autres système de bases de données comme MySQL ? ( ce qui est différent certes )

Quelles orientations devrait prendre Access, à votre avis, dans l'avenir ?

* Gestion multi-utilisateurs ! Architecture client-serveur "light" ( c.ad. plus simple et petite que par exemple SQL-SERVER )

Cela n'engage que moi mais cet outil ,au demeurant très satisfaisant et performant, est un peu trop orienté bureautique et gagnerait à s'étoffer de méchanismes pour gérer plusieurs utilisateurs et plus d'enregistrements .
Une petite société n'a pas les moyens d'investir dans des outils plus "lourds" comme Sybase ou SQL-Server ( ne parlons pas d'Oracle ! ).

*Microsoft ne jure plus que par .NET et C# . Est-ce que VBA sera-t-il toujours intégré avec Access comme language de macros ??
Pourquoi ne pas intégrer C# comme language de macros interne à Access ( et reste de la suite Office ) ?

[Maxence HUBICHE]

merci beucoup pour tes remarques !

Avant tout, Access est nativement multi-utilisateur.
Mais on ne va pas ouvrir ce débat ici, il y a tout un thread (arguments pour et contre access) dans ce même forum qui en parle.

Par ailleurs tes remarques sont très bien fondée.
Je suis en relation avec des membres de l'équipe Microsoft à propos du devenir d'access.
Ce qui est sûr, c'est qu'ils ne veulent pas abandonner Access.
Pour l'instant, on a plus brainstormé qu'autre chose.
Et c'est pour cela que votre participation est plus que bienvenue.
N'hésitez pas à donner des avis pour ET contre.
C'est comme cela qu'on fera (peut-être) avancer le débat

[Etienne Bar]

Personnellement, à part la propogation des propriétés et les dépendances, je ne vois pas grand chose qui me pousse à casser ma tirelire pour faire la mise à jour.

(PS : Je n'ai pas de problèmatique liée à XML pour le moment. Si la question se posait peut être que je reverrais mon opinion)

[Maxence HUBICHE]

C'est vrai.
Les dépendances, sont, à mon avis, l'une des plus grosses évolutions.Et aussi, certainement, la meilleure (même si on peut toujours améliorer )

Mais la propagation des propriétés, c'est pas mal quand même !

Imagines que tu modifies... un masque de saisie, un format serait même plus parlant !
tu passes de francs en Euros
Tu vas le faire dans la table, en prévision des Etats qui pourraient être ajoutés à l'appli, mais tu vas devoir modifier chaque formulaire, et état existant également !
Avec la propagation des propriétés, ce n'est plus la peine.
Tu changes ton format, tu dis que tu veux que les propriétés soient mises à jour partout, et Zou !
C'est pas beau la vie ?

Quant au XML, il a tendance à devenir un standard incontournable sur le stockage des données, et particulièrement pour le web.
Là, tu peux importer les données XML, tu peux aussi, les exporter, mais tu peux aussi les transformer grâce à un fichier xsl !
Tu vois un peu les débouchés pour un dev Web ?

Enfin, moi j'aimerai ajouter que, même si la plupart des mises à jour ne sont pas significatives, ce en quoi je te rejoins , cela montre que, contrairement à ce qu'affirment les mauvaises langues, Microsoft ne souhaite pas abandonner ce produit.
Par contre, pour qu'il continue à évoluer, il faudra envisager son passage à un langage vraiment Objet (.NET pour coller aux objectifs de Microsoft).

[lunatix]

moi, je trouve que ce qui serais bien pour acces, c'est que la base souvre un peu au monde non microsoft. parce que pour l'utiliser a partir de php ou java, c'est un peu galere (et toujours via odbc :-/ ). et c'est dommage ca r c'est une base que j'apprecie pour sa convivialité, mais pas moyen d'exploiter ca ensuite.

[Maxence HUBICHE]

Très bonne remarque.
Elle sera remontée après vérification (car je ne suis pas du tout compétent sur ces produits).

Par exemple :
Comment veux-tu attaquer la base autrement ?
Comment, en php Attaques-tu une base Oracle ? MySQL ? PostGreSQL ? ... (je suis inculte )
Comment en Java attaques-tu ces mêmes bases ?

Ce n'est pas en ODBC ?
N'y a-t-il pas moyen d'utiliser les ADO dans ces langages ?

[mat.M]

Très bonne remarque de Lunatix : ce SGBD devrait s'ouvrir pour par exemple supporter Php et autres...

[lunatix]

cool, j'avais peur de lancer un troll alors que mon point de vue est tres pragmatique
je developpe un peu.

je pense que acces est LA base sans concurent reel sur le marché, pour sa facilité d'utilisation, sa souplesse et son ergonomie ! elle pourrait facilement etre la petite base embarquée de reference (petite pas au sens pejoratif, mais au sens pas base a forte charge / forte taille), mais la fermeture de la base aux langages autres que ceux de microsoft la rend inutilisable pour la plupart des developpeurs.
du coup, on se tourne vers hsql, sqlite qui n'ont pas la meme ergonomie (meme si elles ont d'autres avantages)

pour java il faudrait un driver jdbc correct
pour php, une api ouverte et native.
pas d'odbc qui est quand meme un serieux limitateur de performances.

en fait, le bonheur, ca serait que le moteur (pas l'interface mais juste le moteur) soit multi plate forme. Que l'on ait pas un chemin odbc a parametrer dans windows, mais un moyen simple d'acces (un port d'ecoute et une ip quoi)

soyons honnete, si acces etait un peu plus ouvert, ce serait la base de donnée incontournable pour toutes les applis de taille moyenne.

[Admin]

déjà lunatix, merci de ces commentaires qui sont vraiment très bien.

finalement, ce que tu "repproches" à Access c'est de n'etre qu'un SGBD fichier, et pas client-serveur non ?

[atah]

Moi ausi j'étais un adepte de Acces et de VB depuis l'origine (depuis DAO et mêm ADO). C'est lors du passage d'une appli de DAO à ADO que j'ai décidé de passer à autre chose que Acces et VB (Delphi et Firebird). C'est pourquoi j'ai quelques questions à poser :

- Une base Access grossit-elle tjous autant quand on y accède (nécessiter de faire des compctages très très souvent). Je pense que c'est un problème cricial qu'il faudrait régler ou limiter avant d'ajouter d'autres fonctionnalités si utiles soient-elles.

- Est-ce que lors du balayage des champs d'un Recordset on peut se retrouver avec des champs entre crochet <<Exemple : Select C1 from table, il faudrait faire Recordset.Fields("[C1]") au lieu Recordset.Fields("C1") >>, le pire c'est que c'est aléatoire, peut être j'avais raté quelque chose.

- En ce qui concerne la sécurité, est-il aussi facile de retouver le mot de passe d'une base de données protégée.

[stailer]

Avant d'être développeur Delphi, PHP, un peu Java et 4D depuis peu j'ai fait 2 ans d'Access avec VBA 6.0.
J'ai developpé un projet assez important de gestion de cabinet d'avocat et qui est notamment utilisé en multi-utilisateurs sur 6 postes.

Je pense que je peux parler de ce produit très sympa en connaissance de cause.

Donc déjà les assistants et autres systèmes "automatiques" : très bien pour les débutants, nul pour les autres. Bah oui, je crois que pour faire une application un minimum sérieuse avec Access il faut absolument passer par VBA avec ADO ou DAO.

Ensuite, la gestion multi-utilisateurs justement, la aussi c'est bien mais c'est lent. Je reprocherai, comme les autres un gros manque à ce niveau la.

Concernant les états : rapides, faciles à concevoir, ils sont pas mal mais par contre y a pas mal de bugs à déplorer sur les états graphiques. Et une fois encore je les trouve un peu lent à visualiser lorsqu'il y a de nombreuses données et pages. De plus ces derniers ne proposent toujours pas le format PDF en export.

Un autre problème : le déploiement... Galère lorsque on utilise des composants externes, et souvent des problèmes de version de DLL.
Et surtout surtout surtout : pas possible de faire un .exe !!!
Alors la c'est carrèment dommage.

Enfin pour le web, XML ok ca c'est bien.. Mais on ne peut pas créer des fonctions à l'intérieur d'Access qui seront déclarées en tant que Web Services et accessibles de l'extérieur... Ou l'inverse, se connecter à un web service depuis Access... Même le logiciel 4D propose de faire ça.

Voila en gros mes impressions.

Pour finir : pour moi Access est LE produit pour apprendre la conception de base de données, la programmation et le développement informatique de manière générale.

A noter : une grande facilité de synchronisation entre tous les produits d'Office. Il est très simple de piloter Excel ou Word à partir d'Access... Et ca c'est top pour développer des systèmes de facturation ou autres tableaux. Les utilisateurs peuvent ainsi créer leur propres modèles de documents personnalisés.

A++

[Admin]

- Une base Access grossit-elle tjous autant quand on y accède (nécessiter de faire des compctages très très souvent). Je pense que c'est un problème cricial qu'il faudrait régler ou limiter avant d'ajouter d'autres fonctionnalités si utiles soient-elles.

Ce problème existe également chez de grands éditeurs comme Oracle, c'est simple à justifier, le temps que la machine ne prends pas à desalouer l'espace prit permet un gain en vitesse.

Même si sous Access, le phénomène est plus rapide et plus sensible que sous Oracle.

- Est-ce que lors du balayage des champs d'un Recordset on peut se retrouver avec des champs entre crochet <<Exemple : Select C1 from table, il faudrait faire Recordset.Fields("[C1]") au lieu Recordset.Fields("C1") >>, le pire c'est que c'est aléatoire, peut être j'avais raté quelque chose.

J'ai pas bien compris, mais les recordsets possède de nombreuses syntaxes, la plus lente etant recordset.field("C1"), car Access doit interpréter le champ, personnellement j'utilise toujours recordset![C1]

[Maxence HUBICHE]

Donc déjà les assistants et autres systèmes "automatiques" : très bien pour les débutants, nul pour les autres. Bah oui, je crois que pour faire une application un minimum sérieuse avec Access il faut absolument passer par VBA avec ADO ou DAO.

Tout à fait d'accord avec toi.
D'un autre côté, si Access doit rester accessible aux utilisateurs lambdas, ces assistants leur seront indispensables. Rien ne nous empêche de ne pas les utiliser n'est-ce pas ...

Ensuite, la gestion multi-utilisateurs justement, la aussi c'est bien mais c'est lent. Je reprocherai, comme les autres un gros manque à ce niveau la.

Oui, c'est lent.
Mais c'est un sgbd fichier.
De plus le moteur est optimisé pour la lecture. Ceci explique cela

Concernant les états : rapides, faciles à concevoir, ils sont pas mal mais par contre y a pas mal de bugs à déplorer sur les états graphiques. Et une fois encore je les trouve un peu lent à visualiser lorsqu'il y a de nombreuses données et pages. De plus ces derniers ne proposent toujours pas le format PDF en export.

En fait, l'idéal serait de fournir des états genre Crystal Report non ?

Un autre problème : le déploiement... Galère lorsque on utilise des composants externes, et souvent des problèmes de version de DLL.

Ah ! là on voit que tu n'as pas dû utiliser la solution d'empaquetage
Mais, en lieu et place de cette solution d'empaquetage, un truc du genre InstallShield Express ... là, ca serait un peu plus 'pro' das son aspect, aussi bien que dans sa conception et sa personnalisation.

Et surtout surtout surtout : pas possible de faire un .exe !!!
Alors la c'est carrèment dommage.

Complètement d'accord avec toi.
D'ailleurs, c'est l'un des points qui a été souligné lors du récent entretien avec Microsoft à ce sujet.

Enfin pour le web, XML ok ca c'est bien.. Mais on ne peut pas créer des fonctions à l'intérieur d'Access qui seront déclarées en tant que Web Services et accessibles de l'extérieur... Ou l'inverse, se connecter à un web service depuis Access... Même le logiciel 4D propose de faire ça.

Sur ce point-là, je ne partage pas complètement ton avis.
Le service Web se devrait d'être extérieur à la base Access.
Rien ne t'empeche de faire un service Web en relation avec une base Access.
Maintenant, qu'Access puisse accéder à des Services Web ... Oui, pourquoi pas ! Ca pourrait être sympa effectivement.


Moi, mes impressions, c'est qu'il faudrait un Access à 2 vitesses.
Une première version qui n'évoluerait plus, ou que très peu, et qui continuerait d'être intégrée dans le pack Office.
Une deuxième version, dans un nouveau package (par exemple 'Front Office Developper Edition') Qui contiendrait de VRAIS outils de développement en assiciation à une base de données, dimensionné pour des développements de taille raisonnable. Une interface VS.NET simplifiée, permettant de faire, comme avec WEBMatrix de l'ASP.NET, des WEB Service, mais aussi du client riche avec du VB.NET ou du C#, la liaison avec la base étant assurée par ADO.NET. Les 2 bases livrées (ACCESS et MSDE) permettant de prévoir toutes sortes de développements. Et divers outils comme le Crystal Report pour les états et InstalShield Express pour l'installation, entre autres.

Cela donnerait aux développeurs un véritable outils de développement qui se dissocierait un peu du Pack Office actuel
La secrétaire pourrait toujours faire son carnet d'adresses et ses étiquettes avec Access, mais les services informatiques n'auraient plus l'impression de faire face à un outils qui soit 'de la daube' ou 'bureautique'.

Mais cela n'est que mon avis.

[atah]

Goshiz a écrit:

Ce problème existe également chez de grands éditeurs comme Oracle, c'est simple à justifier, le temps que la machine ne prends pas à desalouer l'espace prit permet un gain en vitesse.

Même si sous Access, le phénomène est plus rapide et plus sensible que sous Oracle.

Votre dernière phrase dit tout.C'est plutôt très très sensible sur Access . Car j'en ai partiqué de base de données depuis, des plus grosses aux plus petites, et sur access c'est une catastrophe.

Goshiz a écrit:

J'ai pas bien compris, mais les recordsets possède de nombreuses syntaxes, la plus lente etant recordset.field("C1"), car Access doit interpréter le champ, personnellement j'utilise toujours recordset![C1]

Je m'explique :
Vous fabriquer votre recordset avec la syntaxe SELECT C1 FROM MATABLE1. Vous faites tout ce qu'il faut et vouz voulez accédez aux champs. Dans certains cas le moteur JET vous retourne un code erreur champ introuvable avec la syntaxe recordset.field("C1") tout simplement parce qu'il attend la syntaxe recordset.field("[C1]") .

[Maxence HUBICHE]

Vous fabriquer votre recordset avec la syntaxe SELECT C1 FROM MATABLE1. Vous faites tout ce qu'il faut et vouz voulez accédez aux champs. Dans certains cas le moteur JET vous retourne un code erreur champ introuvable avec la syntaxe recordset.field("C1") tout simplement parce qu'il attend la syntaxe recordset.field("[C1]") .

Depuis le temps que je travaille quasi Exclusivement sur Access, je n'ai JAMAIS rencontré ce cas-là...
les [] sont utilisés dans le SQL
Ils ne sont nécessaires QUE dans le cas de noms composés, contenant des caractères non conformes à la norme SQL (comme les espaces) - je ne fais pas entrer en considération les paramètres, et noms d'objets divers et variés non normatifs.

[MC2]

Salut,
en parlant de noms, ce pourrait-il qu'un jour, Access devienne plus normé, je pense :
aux contraintes de noms : supprimer la possibilité de mettre des espaces, des accents, pire, des apostrophes,
au langage SQL (ce qui le rendrait plus ouvert aux autres langages),
au VBA : c'est bien la propagation des propriétés mais c'est un tout petit pas vers le langage objet, allons-y carrément et passons à VB.NET,
supprimer les Macros, immaintenables (comment met-on des commentaires ?)

Sinon, autres questions :
avoir des liaisons dynamiques vers d'autres tables, c'est très bien, mais quand il s'agit de les faire bouger sans que l'utilisateur s'en apercoive, alors là au secours,
étendre les "Mises en forme conditionnelles", en nombre : plus de 3 éléments dans la collection, mais aussi en accès : rendre objet cette mise en forme conditionnelle pour qu'elle s'adapte à n'importe quel contrôle ajouté dans Access,
remplacer les contrôles Access par des contrôles VB, ou "mieux" VB.NET,
comme les autres intervenants, pouvoir "dater" une sauvegarde ET pouvoir gérer les fichiers MDB dans SourceSafe,
sécuriser le compactage : si l'option "compactage en fermant" est cochée et qu'on accède à cette base située sur un autre pc sur lequel on n'a pas le droit d'écriture eh bien CRACK la base.

Par contre, moi qui fait de la maintenance applicative, je vois enfin un plus avec un schéma des dépendances.
A+

[jjd]

Bonsoir à tous,

Je suis d'acord avec pas mal de choses qui ont été dites sur ce fil.
En plus le verrouillage au niveau tupple et non par page de 2k serait un plus car expliquer à l'utilisateur que son enregistrement est verrouillé car le voisin en modifie un proche sur le disque est dur!! Je développe en Access 97, je pense qu'il en est toujours de même sur les versions plus récentes ?

[Kenny-Dev]

Bonjour,

Je trouve que ces modifications sont très bien, surtout les dépendances et la prise en charge du xml, mais ce que je reproche le plus à Access, c'est sont interface graphique, qui est quasi impossible à modifier sans perdre des heures à écrire des lignes pour obtenir un formulaire ou une zone de texte avec des coins arrondis par exemple.
Lorsqu'on propose un produit dévellopé à un client, il est tout aussi important d'avoir un "look" différents des autres, et cela est actuellement difficile à obtenir. Par exemple, intégrer une image (photo) en fond d'espace de travail ou bien le fond de l'application transparente, etc... pouvoir faire des boutons rond ou triangulaire, bref un aspect plus convivial et plus esthétique serait un plus, un peu comme certaines page web. De même, pouvoir personaliser les boite de message serait un plus, cad editer le texte des boutons, leur forme et couleur.

Vous me direz que cela va encore alourdir, certes c'est probable, mais au fur et à mesure que l'on améliore les capacités d'access, il en est de même.

Une chose aussi, serait intérressante, serait la possibilité d'ajouter une fonctionnalité permettant de gérer les api windows, comme une bibliothèque, associée à une aide afin de savoir quelle api fait quoi et l'associée à un objet. Je pense notement à la recherche de fichier, ou le parcours réseau.

Enfin, en mode création de requête, il serait interresant de pouvoir faire des liaison de table conditionnelle, je m'explique : Je crée un état pour afficher les coordonnées d'un client qui est en retard de paiement, ou impayé, pour cela j'ai plusieurs tables, dont une table réglements, qui reprend toutes les infos nécessaires, le n°Client, le N° Facture, le montant du reglement, etc... et dans la requête de mon état, j'utilise ce montant règlement, par une requête liée (somme de montant règlement), mais si le client n'a jamais fait de règlement, je me retrouve avec une liaison nulle qui me retourne aucun enregistrement. Si je pouvais luis dire que dans ce cas ma somme de règlement = 0, ce serait un plus, et m'éviterait un état où tous les champs sont en #Erreur.
Actuellement il faut ruser pour contourner le problème, et cela prend du temps à l'exécution.

Voilà, ma petite participation en temps que devellopeur "amateur".

[atah]

Kenny-Dev a écrit

Enfin, en mode création de requête, il serait interresant de pouvoir faire des liaison
de table conditionnelle, je m'explique : Je crée un état pour afficher les coordonnées
d'un client qui est en retard de paiement, ou impayé, pour cela j'ai plusieurs tables,
dont une table réglements, qui reprend toutes les infos nécessaires, le n°Client,
le N° Facture, le montant du reglement, etc... et dans la requête de mon état,
j'utilise ce montant règlement, par une requête liée (somme de montant règlement),
mais si le client n'a jamais fait de règlement, je me retrouve avec une liaison nulle
qui me retourne aucun enregistrement. Si je pouvais luis dire que dans ce cas ma somme
de règlement = 0, ce serait un plus, et m'éviterait un état où tous les champs
sont en #Erreur.

Si j'ai bien compris votre problème, je crois qu'Acces le fait depuis belle lurette à
l'aide d'une jointure externe combinée avec les fonction IIF et ISNULL.