Access 2007 : Microsoft abandonne la gestion de la sécurité utilisateurs

Citation:

---

Envoyé par Maxence HUBICHE

Donc, en fait, la sécurité utilisateur N'A PAS ETE SUPPRIMEE dans Access, mais seulement n'a pas été implémentée dans le nouveau système de Fichier ACCDB.
Enfin, pour le moment.
En effet, un peu plus loin, nous lisons ceci :

Citation:

---

We are investigating better ways of implementing User Level Security in the ACCDB file format in a future release.

---

ce qui laisse présager, au pire, un service pack.
Au mieux, de nouvelles versions encore améliorées.

---

J'espère bien, mais c'est la première fois que je vois un éditeur retirer une fonctionnalité, publier une nouvelle version et promettre "on va vous la remettre plus tard". Hum ! hum !
D'après la radio ce matin, ni Bill ni MS ne sont fauchés. Ils devraient avoir les moyens d'aller au bout ?
Je croirai ce "complément" quand je le verrai, mais, vu la manière dont j'utilise systématiquement la sécurité d'access, pas seulement pour protéger, mais juste pour gérer les rôles de chacun, il est clair que je ferai l'impasse sur toutes les nouveautés du nouveau format, en attendant le service pack.

J'ai d'autant plus de doutes que, si mes oreilles sont bonnes, le présentateur d'Access aux DevDays expliquait, entre autres

Citation:

---

"C'est bien normal qu'il aient supprimé la sécurité, puisqu'elle est déportée dans SharePoint".

---

Si ce ne sont pas les mots exacts, c'est ce que j'ai compris.
Ça, pour moi, c'est un argument commercial, uniquement en faveur de Sharepoint. Et, en faisant ça, ils coupent une patte à Access, ce qui, de leur part, n'est certainement pas involontaire. (et pis, ça fait mal !)
Je viens d'exposer mon point de vue dans l'autre débat, à côté : Formation : Access, SGBD, Langage...
Je peux me tromper (j'espère), mais mes contacts avec les experts de Microsoft en entreprise m'ont convaincu que MS ne veut pas développer Access entant qu'outil professionnel de développement.
Ou alors, maintenant, et c'est nouveau, qu'ils veulent s'en servir pour faire décoller les ventes de SharePoint.
Sharepoint répond à certains besoins, mais ne couvre pas ceux des applis Access légères, rapides, dénuées de serveur.
Donc, c'est très clair : en attendant une nouvelle mouture avec sécurité au moins équivalente de l'ancienne, je resterai avec Access 2000/2002/2003 (Y a t-il d'autres nouveautés dans 2007, qui vaillent le déplacement et qui fonctionnent avec des fichers .mdb ?)
De toute façon, ce n'est jamais moi qui choisit la version : c'est le client. Disons que je ne prodiguerai aucun encouragement.

SUJET N° 1

L'orateur, lors des TechDays a plutôt dit que

"la sécurité, dans le cadre d'un développement en groupe de travail, avec SharePoint en serveur, n'avait plus d'intérêt, puisque c'est le serveur qui s'occupait de la sécurité"

au passage, il en est de même si on fait un ADP.

L'orateur n'allait pas dire que la sécurité était supprimé lors des TechDays, alors qu'il attendait la réponse des US

la réponse, c'est :

- MDB est toujours supporté, et dans les deux sens (ouverture et création) dans 2007, avec toutes ses fonctionnalités habituelles, réplication et sécurité y compris ! Donc, pas de changement
- ACCDB est un nouveau format qui inclu de nombreuses fonctionnalités nouvelles. Si l'on n'a pas besoin de ces nouvelles fonctionnalités (champs multi-valeurs, par exemple), on peut très bien faire du MDB. Sinon, on peut faire du ACCDB. Mais dans le ACCDB, la sécurité n'a pas encore été implémentée. Normal en fait, puisque toute ces nouveautés sont issues de SharePoint.

L'orateur a fait sa présentation en 2 phases.
Soit on fait des bases standalone, et là, la sécurité, on s'en fout un peu : c'est pour soi, perso.
Soit on travaile en groupe de travail, et là, Sharepoint est tout indiqué.

Comme le sujet ne concernait que les nouvautés, il n'a pas abordé l'existant (MDB), mais uniquement l'ACCDB dans ses propos.

Voilà ;

SUJET N°2

Citation:

---

Envoyé par Papy Turbo

Je peux me tromper (j'espère), mais mes contacts avec les experts de Microsoft en entreprise m'ont convaincu que MS ne veut pas développer Access entant qu'outil professionnel de développement.

---

Je pense que le principe est que les développeurs devraient se ruer sur DotNet, du point de vues de MS (Ca, c'est clairement leur point de vues). Mais qu'ils sont dans l'incapacité de se débarasser d'un outil de dev tel qu'Access, au même tutre que le "développement" sous Excel les fait suer. tu remarqueras par exemple, que tu as un xlsx pour les classeurs, mais un xlsm pour les classeurs avec macros. ca me rappelle vaguement les xlw et xlm d'antan (xl4 / xl3)
Il est à noter cependant que l'ensemble des novuelles fonctionnalités à été implémenté ans le langage VBA inhérent à chaque soft. Donc, de là à dire qu'ils n'en ont rien à faire, il y a un certain pas à faire. Si effectivement, ils n'en avaient rien à afire, ils arrêteraient de le soutenir, et de le faire évoluer. il n'en est rien, au contraire.
De plus, son intégration dans l'ensemble du SYSTEM OFFICE (Office System 2007) montre une claire orientation pour un usage plus général de ce produit.
voilà ce que j'en pense...


ps : l'orateur ... c'était pas moi des fois ??? :koi:

JOKE

Citation:

---

Envoyé par Papy turbo

je resterai avec Access 2000/2002/2003

---

Ah ?
Ca y est ? Tu as laissé tomber Access 2.0 ?
:lol: :lol: :lol:

Pendant l'utilisation d'Access 2007, j'ai remarqué quelques petites particularités.

En mode création de table, pour basculer entre les noms de champs et leurs propriétés, il suffisait d'utiliser la touche F6, deux pressions permettaient de revenir dans la fénêtre des champs.

Aujourd'hui, une pression bascule dans la sous fenêtre propriété, et la seconde pression bascule sur le volet de recherche ? :?

Sur les versions précédentes une pression sur la touche F4 déroulait les combos, c'est plus le cas, pour les dérouler, c'est Alt Bas.

De petites habitudes à changer.

Citation:

---

MDB est toujours supporté, et dans les deux sens (ouverture et création) dans 2007, avec toutes ses fonctionnalités habituelles, réplication et sécurité y compris ! Donc, pas de changement

---

J'ajouterais que mdb vs accdb n'influe que sur les fonctionnalités du moteur de base de données (Pièces-jointes, historique des mémo, multivalués, etc)

Par contre les fonctionnalités nouvelles de l'interface sont utilisable dans les fichiers mdb créés avec Access 2007.

Dans un mdb, il est tout à fait possible d'utiliser l'édition de texte enrichi dans une zone de texte, le contrôle calendrier, le ruban, formulaire double, etc ainsi que toutes les fonctionnalités de l'environnement de développement (volet de champs, templates, etc)

Au niveau de VBA les membres sont toujours ceux d'Access 12 quelque soit le format de fichier utilisé, vous pouvez donc aussi utiliser les variables temporaires, etc.

Citation:

---

je resterai avec Access 2000/2002/2003

---

Selon moi c'est une erreur. Rester en MDB oui, mais avec Access 2007 pour réaliser des applis plus conviviale, plus ergonomique et plus rapidement

Citation:

---

Envoyé par Tofalu

Selon moi c'est une erreur. Rester en MDB oui, mais avec Access 2007 pour réaliser des applis plus conviviale, plus ergonomique et plus rapidement

---

Et là, y a rien à dire, Access 2007 est très convivial pour l'utilisateur.
Les options disponible pour agrémenter les formulaires sont très nombreuses.

Citation:

---

Envoyé par Maxence HUBICHE

- MDB est toujours supporté, et dans les deux sens (ouverture et création) dans 2007, avec toutes ses fonctionnalités habituelles, réplication et sécurité y compris ! Donc, pas de changement

---

Oui, tu l'as dit, tout le monde a bien compris, je pense.
Mais il reste quand même 2 questions :
1- la compatibilité ascendante est-elle la même qu'entre Access 2000/2002/2003 ?
L'objectif de MS était de dire : la même application peut tourner sans aucune mise à jour ni modification, sous les 3 systèmes.
Même s'il y a de nombreuses incompatibilités (bugs) à ce niveau là entre 2000 et 2003, qu'on peut parfois corriger, il reste qu'on peut lancer une application Access 2000 sur un parc hétérogène Axs 2000/2002/2003.
Ici, qu'est-ce qu'il va falloir, au minimum, reprogrammer (quitte à mettre une constante de compilation pour ne garder qu'une seule appli sous 2 ou 3 versions) ?
Vous me corrigerez, et vous me compléterez s'il y a lieu. Pour l'instant je relève au moins :
- nécessité de remplacer tous menus et barres d'outils, et le code lié, par un ruban et sa (nouvelle) programmation.
Autre chose ?

La 2ème question est répondue par Tofalu, en grande partie. C'était l'essentiel de mon propos. Il s'agit de déterminer si on a intérêt à investir dans x licences Office (Access) 2007, pour ceux qui veulent conserver le format .mdb encore un bon moment, au moins en attendant le patch "sécurité", si il arrive.
Question :
2-Qu'est-ce qui nous incite à acheter la licence 2007, si on reste avec des mdb ?
- J'avais noté le ruban, qui n'est pas désagréable, par rapport aux menus.

Citation:

---

Envoyé par Tofalu

Dans un mdb, il est tout à fait possible d'utiliser l'édition de texte enrichi dans une zone de texte, le contrôle calendrier, le ruban, formulaire double, etc ainsi que toutes les fonctionnalités de l'environnement de développement (volet de champs, templates, etc)

---

Note : le calendrier est peut être mieux. Mais pas nouveau. Et on en a plein ici, pour Access 2000...
Autre chose ?

Citation:

---

Envoyé par Maxence HUBICHE

Ca y est ? Tu as laissé tomber Access 2.0 ?
:lol: :lol: :lol:

---

Je peux te prêter mes disquettes d'Access 1, quand tu veux (je dois même avoir un backup, bien sûr), dès que tu auras obtenu de MS une licence d'utilisation, et que tu auras réinstallé Win 3.0.:mouarf:

Citation:

---

Envoyé par Papy Turbo

Je peux te prêter mes disquettes d'Access 1, quand tu veux (je dois même avoir un backup, bien sûr), dès que tu auras obtenu de MS une licence d'utilisation, et que tu auras réinstallé Win 3.0.

---

C'est donc vrai t'es un papy. ;)
Je savais que MS continuait à supporter la version 2, on peut encore trouver un convertisseur.

Citation:

---

Autre chose ?

---

A priori tout ceci :

II-A. Le développeur
II-B. L'utilisateur
II-B-1. Les nouveautés
II-B-1-a. Le contrôle calendrier
II-B-1-b. Optimisation du mode feuille de données
II-B-1-c. Edition de texte enrichi
II-B-1-d. Les filtres de formulaires
II-B-1-e. Images dans les formulaires continus
II-B-1-f. Les variables temporaires
II-C. La programmation du ruban

mais aussi :

IV-B. Le pdf

;)

Citation:

---

Envoyé par Papy Turbo

La 2ème question est répondue par Tofalu, en grande partie. C'était l'essentiel de mon propos. Il s'agit de déterminer si on a intérêt à investir dans x licences Office (Access) 2007, pour ceux qui veulent conserver le format .mdb encore un bon moment, au moins en attendant le patch "sécurité", si il arrive.

---

Pour faire des classeurs de base Excel, je peux toujours le faire en XL5, ca fonctionne parfaitement.
si c'est,pour faire du mdb, je peux le faire en 97 ou en 2000, ca marche parfaitement

le vrai problème est : est-ce que je veux avoir un outils plus souple, m'assurant une productivité accrue ?

Si la réponse est oui, ou si la réponse est non....

Je viens de tester sous SharePoint en migrant ma base access 2007.
Un petit hic je perds l' intégrité référentiel de l'ensemble des tables, c'est carrément gênant.
Je renonce à utiliser SharePoint pour le moment.:cry:

L'un de vous a-t-il développer un programme pour la gestion multi-utilisateur avec access 2007 ?
Je voudrai utiliser la fonction les pièces jointes.
Merci.

Citation:

---

Envoyé par Maxence HUBICHE

Bon, après avoir soumis la question à MS, voici la réponse :

User Level Security is available in the MDB file format in Access 2007. Access 2007 can be used to design MDB files just like Access 2003 can. It is just that you can’t use it with the User Level Security feature if you create a database in the new ACCDB file format.
Level Security is not supported with the ACCDB file format. [...]
We did not remove User Level Security. Everything that you could do in Access 2003 you can still do in Access 2007. It is only the ACCDB file format that doesn’t support User Level Security. There are only a small number of features that require the ACCDB file format. If you don’t need any of those features, you can continue to use the MDB format without any issues.

Donc, en fait, la sécurité utilisateur N'A PAS ETE SUPPRIMEE dans Access, mais seulement n'a pas été implémentée dans le nouveau système de Fichier ACCDB.
Enfin, pour le moment.
En effet, un peu plus loin, nous lisons ceci :

We are investigating better ways of implementing User Level Security in the ACCDB file format in a future release.

ce qui laisse présager, au pire, un service pack.
Au mieux, de nouvelles versions encore améliorées.

---

Je viens d'installer Office 2007 SP2.

A part que je peux maintenant ouvrir des documents Open office dont je n'ai rien à f%*¤#, il semblerait que la gestion de la sécurité utilisateurs n'ait toujours pas été prise en compte dans ce nouveau service Pack:piou:.

Bonsoir,

Là je file un point de vue très personnel.
On se pose la question mais pourquoi microsoft a viré la sécu ? Ont-ils oublié dans leur développement cette partie ?

A mon avis ils se sont posé la question cela vaut le coup d'avoir de la sécurité sur des documents Office en dehors de celle du réseau ?
E puis si nos clients sont des paranoïaques ils cassent leur tirelire pour un SQL serveur, il y a même une version gratuite.

Access c'est pour de petits développements jetables destinés aux PME de bases et si un commercial s'en va avec le fichier clients ce n'est pas réellement catastrophique.

A+

Bonsoir,

Citation:

---

Envoyé par naphta

...
Access c'est pour de petits développements jetables destinés aux PME de bases...
A+

---

Je pense que l'on dérive vers du hors sujet là.... mais je ne résiste pas à commenter ce point... il est évident que la cible des développements sous Access n'est pas celle de SQL Server, mais la réalité du marché démontre qu'il est loin d'être utilisé uniquement dans des contextes d'applications jetables et ne concerner que des PME... Pour ce qui me concerne, l'essentiel de mes clients sont des grandes entreprises et certaines applications ont plus de 10 ans d'existence.

Bien d'acccord avec toi : les développeurs sont les mieux placés pour savoir tout ce qu'on peut faire avec VBA.

Mais je retiens quand même la question posée par Naphta, que je ne trouve pas hors sujet dans ce débat :

Citation:

---

Envoyé par naphta

On se pose la question mais pourquoi microsoft a viré la sécu ? Ont-ils oublié dans leur développement cette partie ?

---

Sans vouloir jouer les devins, il semble évident que l'intérêt commercial de Microsoft est de ne pousser que VS + SQL Server pour les développements en entreprise.

Je pense cela parce que je n'ai jamais vu de support technique, ni obtenu de réponse aux questions avancées, pour le développement VBA (Pour les produits Office, Oui, bien sûr, mais VBA ?!?), à part les fichiers d'aide et MSDN. C'est bien là qu'intervient DVP, en bouchant un trou, ce qui convient à tout le monde.
Même en entreprise, en faisant appel directement aux experts (rémunérés) de chez MS, la réponse à toute question VBA a toujours été : passez à SQL Server.

Egalement, parce que le "déplacement" de la sécurité des bases access vers Sharepoint (si j'ai bien compris la réponse MS fournie par Maxence), confirme cette tendance : là aussi, détourner (autant que possible) les utilisateurs avancés d'Office vers d'autres produits plus lourds, alors que bon nombre d'entre nous n'auront jamais besoin de Sharepoint.

Cela justifie pour moi l'utilisation exclusive du format .mdb, pour l'instant en tout cas.

Bonjour,


Bon c'est vrai c'est un peu dur de dire c'est pour des applis jetables mais je viens du système et on toujours eu besoin d'access pour les déploiements massifs de becannes, à la fin du projet on bazardait parfois 3 semaines de dev access ! et autour de moi on parlait toujours d'applis jetables conçues vite avec un RAD quelconque, c'est comme ça que j'ai mis les mains dans access qui a bien des qualités et en fait le rad le plus rapide du monde.


Je viens d'installer et commencer à chatouiller vs 2008 ...
l'orientation est double et confirme parfaitement les dires de PapyTurbo, RAD avec SQL dans un environnement dotnet contrôlant la sécurité.

L'alternative à la sécurité gérée par access que j'intègre est basée sur les comptes utilisateurs. Je sais c'est limite mais ça suffit largement dans les environnements pour lesquels je bosse.
Donc je ne regrette pas que Microsoft laisse tomber la sécu.

a+

Je comprends bien que tu ne regrettes pas, si, comme tu le dis, tu ne t'es servi d'Access que pour des "jetables". Ce n'est pas le lieu ici pour le débat sur ce qu'on peut faire avec Access, mais tu es conscient que tu utilises 10% à peine du domaine que couvrent les applications Access. (Voir mout1234, + haut, débat "Pour ou contre Access"...)

Je n'ai pas été clair :
1- Sécurité dans l'application :
En tant que développeur d'applications Access destinées à durer entre +- 5 et 15 ans, dans des PME, des Administrations, des grands groupes, voire en front end sur des ERPs, avec de 1 à + de 2000 utilisateurs, je regrette la perte de la sécurité dans le nouveau format d'Access 2007 comme étant la perte d'un outil de programmation.
Grâce à cet outil, je peux, comme n'importe quel administrateur Windows,
- créer des groupes (développeurs, utilisateurs standard, administrateur des données... tout comme Administrator, Standard User, Power User sous Windows)
- octroyer des droits à chaque groupe : quel formulaire peut être utilisé par qui ? qui a accès au mode Design ? ...
- je peux, si nécessaire, placer des individus dans ces groupes et affiner leurs droits. Et je le fais, même si ça ne correspond qu'à des exceptions bien précises.

Bien sûr, je ne demande pas à cet outil l'authentification et la sécurité d'un ERP, mais il me convient parfaitement pour l'usage de mes clients : empêcher toute fausse maneuvre, de la part d'un utilisateur quelconque.
Exemple courant : chez le client, un "maître de l'ouvrage" est mon interlocuteur. Il a tous les mots de passe, tous les accès s'il le veut, y compris dans le groupe Développeurs.
Ce M.de l'O. travaille quand même
- avec un accès standard, quand il est utilisateur, sur ses données,
- avec les accès "administrateur des données" (ne pas confondre avec le groupe Administrateurs), pour ses opérations techniques (synchro, mises à jour...)
- avec les accès "développeur", à ses risques et périls, s'il veut mettre son nez dans VBA et autres modes Design. (Dans ce cas, toute garantie saute :mrgreen:)

Bref, n'importe quel hacker primaire trouvera peut être de quoi faire sauter ma "protection". Quel problème ? Il bousille les formulaires ? On a une copie propre de l'application en archives.


2- Le fond de la sécurité concerne l'accès sécurisé aux tables de données.
Drôle de paradoxe, la sécurité Access dont nous parlons ne fait (presque) rien pour cela : si on bloque l'accès à une table (locale ou attachée), les utilisateurs ne peuvent plus y accéder !!! Donc, on ne bloque jamais les tables en lecture, ni en écriture s'ils ont le droit de saisir/modifier. Donc, même la structure est lisible. Et, si elle n'est pas modifiable, on ne peut plus "détacher/rattacher" les tables attachées. :marteau:

Pour sécuriser "au mieux" les données sensibles (selon les techniques disponibles en 2009), il y a d'autres outils, à commencer par une base Client/Serveur solide.

Ce qui, bien sûr, n'empêche nullement de conserver des accès bien, voire très bien sécurisés (aucun n'est parfait), sur des fichiers *.mdb.
Nous aurons toujours besoin de petites bases "fichier", ne serait ce que pour des itinérants qui "emportent" leurs catalogues de vente, avec tarifs confidentiels...
À condition de bien prendre le problème dans son ensemble :

Dans Access,
- blocage de l'interface de la BDD comme de l'application
- personne ne peut ouvrir la BDD sans un fichier *.mdw qui n'est jamais publié, et surtout, jamais copié sur aucun des portables itinérants, (Donc, là aussi, j'ai besoin de la sécurité dans Access, rien que pour ça.)
- on laisse les utilisateurs de l'application démarer avec ou sans mot de passe, selon la décision du client. Mais tout accès autre que "simple utilisateur", à l'application, sa fenêtre Base de données, le code... nécessitent également un autre fichier *.mdw non public,
- authentification de l'utilisateur Windows (le mot de passe est peut être mieux sécurisé que celui d'access ?)
etc.
On est bien d'accord : tout ça peut être "hacké", mais c'est juste une très bonne première barrière, pour les besoins courants.

Il faut ajouter, selon les cas,

Sur Windows :
- protection des dossiers, des fichiers concernés, (Voir forum Windows)

Sur la machine :
- accès sécurisé par empreinte digitale, rétinienne ou autre gadget de science fiction qui commencent à se répandre...
- s'il le faut, pour prévenir tout vol de portable : "Ce disque dur s'auto-détruira dans les 5 secondes..."
Etc. etc. etc.

En conséquence de quoi, je souhaite vivement que Microsoft révise sa position et fasse vivre pleinement les bases Access (y a à faire pour améliorer), sans perdre aucune fonctionnalité, ni sur les fichiers *.mdb (Sur l'air de "Non, je ne pourrai jamais vivre sans Jet...") comme sur les nouveaux formats, avec leurs nouvelles fonctionalités très appréciables, mais pas dispo en mdb. :calim2: