Discussion :

[Invité]

Bonjour à tous,
j'ai un fichier .mde place sur un serveur auquel on peut accéder depuis de multiples postes.
Récemment le service informatique de la boite a remplace certaines machines où nous sommes en mode "utilisateur" alors qu'auparavant on était en "administrateur".
Depuis ces modifications sur lesdits postes le fichier mde ne s'ouvre plus directement depuis son raccourci bureau, alors que sur les anciens postes (donc ceux non remplacés et qui restent en mode "administrateur" ) ça fonctionne toujours.
Après quelques tests :
Il apparait que sur les nouveaux postes je peux accéder au fichier mde par l'historique Access et que sur ces mêmes postes si le fichier reste un .MDB l'accès via un raccourci fonctionne.
J'en ai conclu que le code compilé du .MDE pose un problème de sécurité...
Pour information, la sécurité macro est au minimum, et la sécurité globale est assurée par F-Secure Internet Security.
Quelqu'un aurait-il une idée à me suggérer ?

PS : je ne sais pas si j'ai choisi le bon forum, mais l'histoire de code compilé a fait que j'ai choisi celui-ci.

[stigma]

Toutes les applis en Access 2003 que j'ai faite pour la boîte sont distribuées en mde (runtime). Access n'est pas installé sur les postes clients.
Il faut que les users soient administrateurs de leur PC. De plus il faut les droits en lecture/Ecriture sur les dossiers où est installé le mde et la base dorsale.

[Invité]

Bonjour stigma et merci pour l'attention portée à mon problème.

les droits en lecture/écriture sur les dossiers où est installé le mde

oui il y a bien les droits en lecture/écriture sur le dossier et sur le mde, mais les postes concernés resteront malheureusement en mode utilisateurs car les service informatique en marre que les gens installent et téléchargent tout et n'importe quoi.... et je les comprends !
Cependant il n'y a pas de frontale ni de dorsale (je sais ça ne fait pas pro) il y a simplement un mde contenant l'ensemble, c'est à dire tables, formulaires, états...
Pourquoi cela fonctionne t'il malgré tout avec un mdb ?

[loufab]

Bonjour,

As-tu vérifié que les nouveaux postes bénéficient de la même version Service Pack Office que les autres ?

Cordialement,

[stigma]

Mettre les données dans un mde, non c'est pas pro du tout. Je te conseille de séparer tes bases.
Dorsales : Tables
Frontale (mde) tout le reste

Je sais bien que mettre les users en admin c'est pas bien mais on a pas trouvé mieux dans ma boîte pour gérer les applis Access.

[Invité]

ouaip ! pas encore pu approfondir cette histoire d'application frontale sous forme de runtime...
Néanmoins, ayant développé en parallèle du service informatique officiel qui nous a littéralement affiché une fin de non recevoir quand on les a sollicités pour développer une application (quel bande de c...), je n'ai aucune possibilité de faire modifier les droits des postes posant problèmes.
La solution qui me reste est de laisser l'application en mdb si je comprends bien ?
Car il y a une évidence qui apparait, c'est que le mde est bloqué, et pas le mdb !
Alors quel peut-être la différence profonde occasionnant ce problème d'ouverture, à part le code qui est compilé ?

[stigma]

L'avantage de séparer les tables de données (dorsales), c'est que tu peux à loisir modifier la base frontale sans toucher aux données. Si tu laisse un mdb, ça veut dire que Access est installé sur les postes clients (prix d'une licence à chaque fois) et que n'importe qui peut modifier le code du mdb. Pas bon du tout

[nico84]

Bonjour,

As-tu essayé de renommer le mde en mdb pour voir si ça passe ? Ainsi les utilisateurs n'auront pas accès au code

Attention par contre de ne pas t'embrouiller les pinceaux et de faire un AUTRE mdb avec un AUTRE NOM sinon TOUT LE CODE SERA PERDU

[Invité]

bonjour nico84,
tu veux dire laisser mon fichier tel quel et changer l'extension .mdb en .mde ?

[loufab]

Bonjour,

As-tu essayé de renommer le mde en mdb pour voir si ça passe ? Ainsi les utilisateurs n'auront pas accès au code

::

Attention par contre de ne pas t'embrouiller les pinceaux et de faire un AUTRE mdb avec un AUTRE NOM sinon TOUT LE CODE SERA PERDU

::

[nico84]

Non c'est le contraire :
- copier le .mdb actuel sous un autre nom pour le sauvegarder !!!
- renommer le .mde en .mdb pour le diffuser aux utilisateurs

[loufab]

(quel bande de c...)

Très bon résumé.

[loufab]

Non c'est le contraire :

- renommer le .mde en .mdb pour le diffuser aux utilisateurs

Je ne vois pas trop l'intérêt de cette manipulation... à part s'y mélanger les pinceaux.

C'est peut être "juste" un problème d'extension verrouillée dans la nouvelle stratégie de sécurité mise en place par la sus-dite

(la bande de c...)

[nico84]

Je ne vois pas trop l'intérêt de cette manipulation

Aucun intérêt sauf dans le cadre d'une stratégie de contournement...

[Invité]

pour Nico, effectivement j'ai essayé sur portable sur lequel je developpe et je confirme que le fichier.mde dont je change l'extension en .mdb s'ouvre et fonctionne normalement ; donc je testerai l'opération demain sur le serveur.

pour Loufab ( que je remercie également pour son avis) quand tu dis

C'est peut être "juste" un problème d'extension verrouillée dans la nouvelle stratégie de sécurité mise en place par la sus-dite (bande de c...)

Tu veux dire que 'ils" peuvent bloquer une application.mde ? au niveau de l'antivirus F-Secure ?
Ok, mais dans ce cas pourquoi puis-je ouvrir l'application incriminée à partir de l'historique Acces ? c'est là que je ne pige plus... c'est contradictoire !
Ou alors serait-ce une lacune de Windows ?

[loufab]

OK pour le contournement, mais cela ne doit pas être une solution, juste permettre de mettre en lumière le problème.

On peut bloquer l'exécution de certains fichiers déterminé par leur extension. Cela ce fait généralement dans la stratégie de sécurité de Windows (les fameux Policies voir le sujet sur le Net).

Pour l'AV, n'utilisant pas ce genre de produit je ne me pronocerais pas.

Pour l'historique, il s'agit en toute logique du fait que ACCESS est déjà ouvert donc il échape au Policies qui gère un ensemble Application / Fichier. (c'est une hypothèse)

[nico84]

Pour une application peu stratégique une autre solution peut être de mettre en service le .mdb mais en mode "exploitation" (qui masque l'accès aux menus de programmation, aux formulaires et au code VBA) avec un bouton "redémarrage en mode conception" qui n'est visible que si l'utilisateur a les droits "admin". C'est la solution que j'utilisait avant de connaitre la compilation et c'est assez simple à mettre en oeuvre

[Invité]

oui Nico effectivement c'est ce que je faisais auparavant. Gestion des options de démarrage et un formulaire me permettant de déplomber l'application.
Évidemment le système compilé m'a tout de suite intéressé par la sécurité qu'il apporte, sans toutefois être un vrai empaquetage runtime.
Par contre j'ai remarqué que le fait de modifier l'extension ne modifie pas la structure du mde, les forms et modules sont inaccessibles en création. J'ai donc là peut-être la solution de contournement puisque je n'ai pas possibilité de négocier avec le service compétent.

[stigma]

A savoir :
Une fois un empaquetage fait sur une machine, il est inutile d'en faire un autre en cas de déploiement d'une autre application.
Personnelement j'ai un empaquetage "bidon" qui installe une mini appli et que je lance sur chaque nouveau PC. Ensuite je peux faire des raccourcis sur les mde de mon choix et suivant les besoins de l'utilisateur.
Par contre, a chaque nouvelle session de créee sur le PC, il est nécessaire de lancer le NoWarningsAccess.reg qui empeche l'affichage des alertes au lancement du mde.

[nico84]

Heureusement que le simple fait de changer l'extension ne donne pas accès au code sinon bonjour la sécurité !!!

Le fait de renommer un .mde en .mdb est une ruse employée par un ami qui travaille dans un grand groupe pour tromper l'ennemi - qui est partout