Discussion :

[Tofalu]

Bonjour,

Dans l’aide Access, il est écrit :

Office Access 2007 ne fournit pas de sécurité de niveau utilisateur pour les bases de données créées avec les nouveaux formats de fichier (fichiers .accdb et .accde). Toutefois, si vous ouvrez une base de données créée avec une version précédente d'Access dans Office Access 2007 et que la sécurité de niveau utilisateur est appliquée à cette base de données, ces paramètres seront toujours actifs.

En effet, si vous vous penchez d'un peu plus près sur Microsoft Access 2007 vous constaterez que la gestion de la sécurité au niveau des utilisateurs a complètement disparue. Elle laisse place à une sécurité unique par mot de passe et chiffrement au niveau de la base de données.
Cette information alimente les débats dans les communautés anglophones. A l’heure actuelle, la communauté francophone semble endormie. De toute façon il est trop tard pour faire machine arrière mais il est peut être déjà temps de commencer à réfléchir à des solutions de remplacements. Rassurez-vous elles existent même si elles semblent plus complexe et moins abouties. Nous tacherons de les exposer dans un prochain article (notamment le vPPC d’Alan Cossey).

Que pensez-vous de cette nouvelle ? Pose-t-elle un frein au nouveau format de données Access 2007 ?

[DonkeyMaster]

Je n'utilise pas du tout Access, mais de façon générale je serais tenté de faire confiance aux ingénieurs Microsoft.

À une époque où l'on parle plus que jamais de sécurité informatique, cette décision semble aberrante. À moins qu'ils ne soient en train de reconnaître qu'Access n'est pas un produit complexe. Du genre, si tu veux un vrai SGBD, va voir du côté MSSQL.

Finalement, ce n'est peut-être pas si abérrant que ça. Je suppose que la plupart des fichiers Access sont gérés par des une seule personne, ou par très peu de personnes, et de toutes façons ils ne circulent pas.
Ou alors, le support reçoit beaucoup de problèmes qui en rapport avec cette fonctionnalité, et ce n'est pas toujours évident de le concevoir ou de le résoudre.

Je spécule, mais ce sont les premières idées qui me viennent à la tête.

[Tofalu]

Peut-être que de toutes façons personne ne s'en sert

Mmm si le message me parait correct, le titre que tu as choisi me parait complètement faux. Cette gestion utilisateur était un argument de vente il n'y a pas si longtemps.

[Lou Pitchoun]

Finalement, ce n'est peut-être pas si abérrant que ça. Je suppose que la plupart des fichiers Access sont gérés par des une seule personne, ou par très peu de personnes, et de toutes façons ils ne circulent pas.
...
Je spécule, mais ce sont les premières idées qui me viennent à la tête.

Et bien justement si... c'est abérrant.

Si tu fait une recherche dans le forum avec le terme sécurité, tu te rendras compte qu'au vu des résultats beaucoup utilisent la sécurité utilisateurs car Access est utilisé en multi-utilisateur.

J'ai personnellement eu affaire à une entreprise assez renommée dans la menuiserie PCV-ALU-etc et bien j'ai été surpris de voir le commercial utiliser un outil developpé sur access (sécurité-réplicas-etc...).

Pour beaucoup de petites entreprises, Access reste un outil largement utilisé.

[Tofalu]

Ah oui, j'ai oublié de préciser, il en va de même pour la réplication.

Ceci dit, la réplication reste marginale face à la quantité d'utilisateur de la sécurité niveau utilisateur.

Du genre, si tu veux un vrai SGBD, va voir du côté MSSQL.

Sauf que SQL Server n'est pas déployable n'importe où. Le coup est élevé, nécessite une attention plus particulière, etc.

Si Access a ateint la niche dans lequel il est depuis maintenant 10 ans (grâce à la démocratisation d'Access 97), c'est à cause de sa polyvalence au sein des petits SI. Et toute appli néessite une sécurité utilisateur ne serait ce que pour différencier l'utilisateur du développeur.

La solution d'Alan Cossey est certes pratique : elle protège essentiellement l'accès aux tables par les utilisateurs non autorisés mais elle ne permet pas de restreindre l'accès aux autres objets facilement. Sans compter que cette méthode est jeune, que le produit Access 2007 n'est pas encore diffusé. Si ça se trouve, elle est très facile à outre passser.

La solution viable reste d'utiliser les anciens formats de fichiers mdb. Mais dans ce cas, adieu les nouveautés : pas de champs multivalués, pas de pièces jointes, pas d'historisation mémo.

À moins qu'ils ne soient en train de reconnaître qu'Access n'est pas un produit complexe

Si la suite Office reste largement utilisée par rapport à OpenOffice, c'est justement grâce à Access et Outlook

[mout1234]

Je suis trés surpris par cette nouvelle !



Je suppose que la motivation première est de limiter le périmètre d'exploitation d'Access ... en imaginant transposer plus de projets vers SQL Server et .Net...
ou peut-être est-ce simplement leur souhait de voir disparaitre ce système qui reste déconnecté du monde de la sécurité Microsoft (Active Directory ...)

Je serai probablement amené à regarder de plus prés des solutions concurrentes dans certains cas...!
Même s'il est vrai que je n'ai pas systématiquement utilisé ce système, préférant une simple identification codée par mes soins lorsque l'objectif - ce qui a été souvent le cas - n'est pas un problème de sécurité à proprement parlé mais plus simplement de délimiter un périmètre fonctionnel adapté à chaque besoin...

[mout1234]

Si Access a ateint la niche dans lequel il est depuis maintenant 10 ans (grâce à la démocratisation d'Access 97), c'est à cause de sa polyvalence au sein des petits

Il est clair pour moi que si Access ne répond plus à mes besoins, dans bon nombre de cas, je chercherai probablement une solution type Windev plutot que SQL Server qui est certes à mes yeux un trés bon SGBD mais qui est beaucoup moins adapté qu'Access pour les développements de petites ou moyenne dimension...

[DonkeyMaster]

Et bien justement si... c'est aberrant.

Si tu fait une recherche dans le forum avec le terme sécurité, tu te rendras compte qu'au vu des résultats beaucoup utilisent la sécurité utilisateurs car Access est utilisé en multi-utilisateur.

J'ai personnellement eu affaire à une entreprise assez renommée dans la menuiserie PCV-ALU-etc et bien j'ai été surpris de voir le commercial utiliser un outil développé sur access (sécurité-réplicas-etc...).

Pour beaucoup de petites entreprises, Access reste un outil largement utilisé.

Soit. Mais dans ce cas, qu'est-ce qui peut bien motiver cette décision ? À vrai dire je ne comprends pas plus que vous.

Interlude :


En effet, il y a beaucoup de monde qui se plaint, et prévoit de rester sous 2003.
On ne pourrait pas, par exemple, lier le fichier Access à une base de données MySql, qui elle gèrerait tous ces droits? Hmm, non, insuffisant et complexe.
Les développeurs sont parfaitement capables d'écrire leurs propres classes de gestion de sécurité utilisateurs (ULS). Ce qui consommera du temps. Et puis, réinventer la roue, ce n'est jamais une bonne idée, diront tous les profs d'algorithmique après vous avoir fait écrire tous les algorithmes possibles avec des listes chaînées. Bref. Les développeurs Access seraient parfaitement capables de migrer vers MS SQL, mais n'ont pas le temps et l'argent. S'ils en avaient, ils seraient déjà sous Visual Studio, WinDev ou que sais-je encore.

Et puis, il y a aussi les gens qui l'utilisent sans être de grands programmeurs, et qui ne sauront pas attaquer une telle tâche, comme par exemple l'intelligente secrétaire d'une petite entreprise de 3 salariés qui n'a pas vraiment eu besoin d'engager une SSII parce-qu'elle a trouvé sur le net ce dont elle avait besoin et a bidouillé le reste.

Finalement, je suis d'accord avec vous, Microsoft n'a pas l'air d'avoir assuré sur ce coup-là.

Je n'ai pas trouvé (j'ai cherché seulement une demi-heure, cependant) quelqu'un qui défende ce choix. Les "MVP" disent ce qui se passe, ce qui change, mais ils ne disent pas le pourquoi de ce choix. Je chercherais davantage plus tard.

[hors sujet]
Je crois avoir tout compris. En fait, le service de support a convaincu les architectes que cette fonctionnalité était bidon et inutile, alors du coup eux ils auront moins d'appels à cause de cette fonctionnalité qui leur posait trop de problèmes. Et tout le monde les a crus.

Ou alors, ils avaient pas le temps, ils ont sacrifié trop de personnel pour Vista, et du coup n'ont pas eu assez de monde pour bien faire ça à temps pour la sortie d'Office 2007.


[/hors sujet]

[Tofalu]

Les "MVP" disent ce qui se passe

Parce que les MVp ne comprennent pas peut être pas comment la sécurité mdw a été pendant longtemps reputé comme LA sécurité à utiliser et mainetant MS dit : le mdw, c'était bidon.

Les développeurs sont parfaitement capables d'écrire leurs propres classes de gestion de sécurité utilisateurs (ULS).

Mmm, pas si simple quand on voit l'architecture de vPPC, c'est un peu tordu quand même.

développeurs Access seraient parfaitement capables de migrer vers MS SQL

Les développeurs oui, mais la question est : "et les clients ?"

Finalement, je suis d'accord avec vous, Microsoft n'a pas l'air d'avoir assuré sur ce coup-là.

On s'y fera... mais là où le bat blesse : si on nous à très vite informé des nouvelles fonctionnalités, je n'avais jusque là pas entendu parler de ça pendant le programme béta... soit 1 an quand même !

A mon avis, il s'agit clairement d'une volonté de faire de sql server et sharepoint le coeur du SI des sociétés. Ces sociétés suivront-elles ? je ne pense pas.

[Maxence HUBICHE]

Avant tout, je trouve aussi ce choix aberrant.

Cependant, cela s'inscrit, à mon avis, évidemment dans le cadre d'une stratégie de 'professionnalisation' de ce logiciel.
La relative fragilité -niveau stabilité - des BDD Access
La relative fragilité de la sécurité par mdw (cf. les crackers sur le net)
...
A certainement encouragé l'équipe Access dans ses modifications, afin de porter les utilisateurs vers Access, tout en encourageant fortement les développeurs à migrer sur une plateforme DotNet + SQLServer

De plus, toute l'architecture des SI d'information prévue par MS est centrée autour de SPS+SQLServer sur le framewwork DotNET.

Ces points m'encouragent à penser que la tendance n'est pas à l'amélioration du produit au niveau de ses performances, mais plutôt au niveau de son intégration dans cette architecture, ainsi que vers une orientation franchement 'USER' d'Access - d'où, par exemple, les champs multivalués, qui sont une ineptie totale sur le plan de la modélisation, mais tellement pratiques pour des utilisateurs lambda.

J'ajoute que, même si les fonctionnalités n'apparaissent plus dans les modèles, pas plus les classes dans le modèle DAO nouvelle génération, les classes sont visible en affichant les membres masqués du modèle.


Le pire, c'est qu'ils réagissent vraiment au format de BDD !
Voici ce que donne l'interface, suivant le format de fichier ouvert :

[Tofalu]

La relative fragilité -niveau stabilité - des BDD Access
La relative fragilité de la sécurité par mdw (cf. les crackers sur le net)

Mmmm...

Comme j'ai pu le lire ailleurs sur le net, la décision de supprimer les mdw serait motivées par ces deux hypothèses :

1. Fragilité de la sécurité niveau utilisateur
2. Migration DotNet/SQL server

J'ai du mal à croire à la première. Si le modéle actuel est fragile, pourquoi ne pas l'améliorer ? Le supprimer, c'est admettre qu'il était plus que fragile mais carrément nul, non ? Pour ma part je ne le juge pas fragile bien au contraire étant donné le domaine d'application d'Access. Access n'a jamais été destiné à un SI critique. Dés lors que le mdw soit "fragile" ne me pose pas de problème. Il me permet de sécuriser ma base en intranet à 99 %. Le 1 % restant, à la limite, je m'en moque puisque c'est le mieux que je pouvais faire.

De mon point de vue, il ne reste plus que la deuxième hypothèse. Mais n'est ce pas dangereux quand on sait à quel point la fonctionnalité était utilisé ? L'abandonner c'est forcer le choix du développeur.

Ces points m'encouragent à penser que la tendance n'est pas à l'amélioration du produit au niveau de ses performances, mais plutôt au niveau de son intégration dans cette architecture, ainsi que vers une orientation franchement 'USER' d'Access - d'où, par exemple, les champs multivalués, qui sont une ineptie totale sur le plan de la modélisation, mais tellement pratiques pour des utilisateurs lambda.

Oui, et je regrette ces nouveautés trop "newbie". A la limite, je serais partant pour rester en format de base de données 2003 (mais avec Access 2007). Malheureusement dans ce cas, je ne profiterais pas des champs pièces-jointes

J'ajoute que, même si les fonctionnalités n'apparaissent plus dans les modèles, pas plus les classes dans le modèle DAO nouvelle génération, les classes sont visible en affichant les membres masqués du modèle.

Oui mais surement pour la compatibilité non ?

Autre choses, sous Access 2007 (avec SQL 92), les requêtes CREATE GROUP, USER, GRANT, etc. fonctionnent (enfin plutot ne lève pas d'erreur, car il y a aucun résultat )

[jfc]

En vrac, mon avis

Le fichier MDW est très pratique, facile à mettre en oeuvre par le développeur.

Par contre, dans en entreprise, cela veut dire plusieurs types d'administrateurs d'utilisateurs.

Celui qui gère ADS et qui n'a pas besoin d'être défini dans le fichier MDW
et un administrateur de base qui lui doit être défini dans le fichier MDW.

Ce n'est pas le rôle du développeur d'administrer les utilisateurs.

En bref, si le fichier MDW semble et est au départ, la solution, à terme (pour le vivre dans l'entreprise ou je bosse), cela devient la galère pour la gestion des utilisateurs, surtout lorsque l'on va déléguer cette gestion à des postes
créés à cet effet.

Ne connaissant pas Access 2007 et au vu des réactions, je doute que Microsoft ait implémenté dans cette version une interface avec ADS.
Ce serait pourtant le pied.

[pseudocode]

Ah enfin un mouvement dans la bonne direction.

Ms-Access n'est pas un SGBD et encore moins multi-utilisateur.

Ceux qui comme moi ont testé l'integration Ms-Access et IIS se souviennent sans doute des messages "Erreur générale", "2 process ont tentés d'ecrire en meme temps", etc.

En ajoutant des fonctions comme la réplication et les droits d'acces au niveau utilisateur, Microsoft entretenait la confusion entre Ms-Access et Sql-Server. Pour moi, Ms-Access c'est un systeme de stockage, mono-utilisateur qui permet de rechercher ces données avec un langage pseudo SQL.

J'engage tous ceux qui cherchent une petite BdD multi-utilisateur a se tourner vers SQL-Server Express.

Pensée du jour: Access est à SQL-Server, ce que WordPad est a Word.

[Tofalu]

Ms-Access n'est pas un SGBD et encore moins multi-utilisateur.

Ah les arguments

Ceux qui comme moi ont testé l'integration Ms-Access et IIS

Access est un produit complet et tout le monde t'affirmera qu'il n'est pas fait pour du web. Le SGBD Access est destiné surtout à être utilisé avec Access.

c'est un systeme de stockage, mono-utilisateur qui permet de rechercher ces données avec un langage pseudo SQL.

C'est une vision simpliste d'un dixième des fonctionnalités du produits. C'est comme ceux qui affirme qu'on retrouve autant de fonctionnalités dans Office que dans OpenOffice sous prétexte qu'ils n'en utilisent qu'1 dixième.

Enlevez vos oeillères et ne portez un jugement que sur un produit que vous connaissez uniquement.

Access est à SQL-Server, ce que WordPad est a Word.

A la différence prés que Word intègre toutes les fonctionnalités de WordPad. Il n'en ai pas de même pour Access et MS Server

[pseudocode]

Access est un produit complet et tout le monde t'affirmera qu'il n'est pas fait pour du web. Le SGBD Access est destiné surtout à être utilisé avec Access.

Comme quoi ce n'est pas un SGBD autonome, mais un produit qui integre une simili bdd afin de pouvoir offrir des fonctions de persistance. D'ailleur essaye de te connecter a distance au "SGBD" Access sans avoir accès au fichiers de stockage.

C'est une vision simpliste d'un dixième des fonctionnalités du produits. C'est comme ceux qui affirme qu'on retrouve autant de fonctionnalités dans Office que dans OpenOffice sous prétexte qu'ils n'en utilisent qu'1 dixième.

Enlevez vos oeillères et ne portez un jugement que sur un produit que vous connaissez uniquement.

J'ai lu toutes les docs MSDN concernant Access, MDAC (ADO, OLEDB) et Jet-Engine. D'ailleur ca n'etonne personne que la Jet-Engine gere les formats Access, Excel, CSV,... mais PAS SQL-Server ?

A moins bien sur, que Access n'incorpore PAS de moteur de base de donnée, et que ce soit la Jet-Engine qui soit le vrai moteur... Mais alors, c'est quoi Access ? Une interface pour creer des tables/requetes ? Un afficheur de formulaires utilisant ADO ? Un IDE pour VBA ? Un melange des 3 ?

[jfc]

Jet moteur de la BD Access ?

Absolument, Access pour accéder aux données s'appuie sur Jet.

Expérience faite :

Access 2.0 en français sur un poste (ça date), messages d'erreurs lors de duplication de données, suppressions, suppressions en cascades, etc... en français

Installation d'une application allemande autre que Access qui remplace le moteur Jet par l'allemand.

Désormais les messages d'erreurs sont en allemand, pour tout ce qui concerne la manipulation des données.

[Tofalu]

Bien entendu que le moteur de base de données est JET (enfin, ACE sous 2007).

Crois tu réellement qu'il faille disposer de Microsoft Access pour pouvoir utiliser une base de données Access ?

Access est un produit permettant de créer un fichier de données compris par la moteur JET et de créer aussi une interface Windows (avec tout ce que cela implique)

D'ailleur essaye de te connecter a distance au "SGBD" Access sans avoir accès au fichiers de stockage.

Là, tu parles d'un serveur. La notion de SGBD ne s'applique pas exclusivement aux SGBD client / server.

J'ai lu toutes les docs MSDN concernant Access, MDAC (ADO, OLEDB) et Jet-Engine. D'ailleur ca n'etonne personne que la Jet-Engine gere les formats Access, Excel, CSV,... mais PAS SQL-Server ?

Quel intéret de passer par un moteur de base de données JET pour interroger un autre moteur de base de données SQL Server. Imagine un développeur Java proposer son produit au client qui interroge une base Oracle mais nécessiterait une licence SQL Server pour se connecter à Oracle

[pseudocode]

Access est un produit permettant de créer un fichier de données compris par la moteur JET et de créer aussi une interface Windows (avec tout ce que cela implique)

Voila. C'etait ce que je voulais te faire dire.

Et c'est pour ca que j'affirme: "ACCESS N'EST PAS UN SGBD"

C'est "un produit permettant de créer un fichier de données compris par la moteur JET et de créer aussi une interface Windows", comme tu dis.

A la rigueur, la Jet-Engine peut-etre considerée comme un SGBD, mais bon c'est plus un moteur SQL qui accède a des fichiers xls, txt, csv et mdb. En particulier la gestion multi-utilisateur et sécurité n'est pas terrible dans la Jet-Engine. C'est pour ca que je trouve normal que Ms le supprime.

[Tofalu]

mmm,

SGBD ne signifie pas moteur de base de données mais Système de Gestion de Base de Données. Il y a certes le moteur mais aussi toute l'infratstructure logicielle permettant d'accéder, manipuler et créer des données.

En particulier la gestion multi-utilisateur et sécurité n'est pas terrible dans la Jet-Engine. C'est pour ca que je trouve normal que Ms le supprime.

Tu n'as pas bien lu en fait. Elle n'a pas été supprimée mais abandonnée au profit d'un SI où Sharepoint est le coeur. Pour ma part, je trouvais la gestion des utilisateurs tout à fait correcte.

[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.