System.mdw fait de la résistance

[Nydyla]

Bonjour à tous,

Je suis technicienne informatique et je n'ai jamais touché à tout ce qui est access

Aujourd'hui j'ai un soucis sur une application access.

L'application est sur la racine d'un serveur, les utilisateurs se connectent en TSE pour avoir accès au divers logiciels etc etc.

Surprise: quand une personne ouvre machin.mdb ça marche mais quand une deuxième personne veut l'ouvrir ...elle l'obtient ce message:

c:/windows/system32/system.mdw;' fichier en cours d'utilisation


ps: avant ça marchait correctement

Donc je fais appel à vos lumières car cela n'ai vraiment pas mon domaine...

(faudrait peut être que je m'y mette)

[LedZeppII]

Bonjour,

Chaque fois qu'on ouvre un fichier Access (.mdb .mde) on ouvre en parallèle sans le savoir un fichier dit "groupe de travail" ayant l'extention mdw.
Access crée également un fichier pour gérer le partage (extention ldb).

Si j'ouvre machin.mdb, Access crée machin.ldb si il ne le trouve pas, et le détruit plus tard lorsque plus personne n'utilise machin.mdb
Il se passe la même chose avec system.mdw -> system.ldb

Plusieurs utilisateurs posent des vérrous sur les fichier ldb.
Le message d'erreur laisserait supposer que le premier utilisateur pose un verrou sans partage (?).

Sur un réseau classique chaque utilisateur utilise son propre system.mdw (celui de sa station de travail). Le problème de vérrous multiples ne se pose pas.

Est-ce que tous tes utilisateurs partagent le même system.mdw ?
Si oui, ont-ils tous les mêmes droits dans le dossier c:/windows/system32

Difficile d'être plus précis. En principe, même en connaissant Access, on ne se préoccupe de la manière dont system.mdw est utilisé ou de la manière dont Access pose ses verrous.

A+

[Nydyla]

Bonjour LedZeppII,


Mes utilisateurs distant pointent tous sur le même.
J'ai deux groupes d'utilisateurs avec les mêmes droits: modification, lecture et exécution, affichage,écriture

Ceux sont tous les utilisateurs qui laissent un verrou sans partager

[LedZeppII]

Bonjour,

Ceci ressemble fortement à ton problème :
ACC97 : message d'erreur lorsque vous essayez de démarrer Access 97 dans Terminal Server

A+

[birding11]

Bonjour,
Un an et demi après ce post, je rencontre la même difficulté. Les utilisateurs se connectent via Citrix à une application Access. Eux ne rencontrent aucune difficulté à ouvrir l'application, et ce n'est qu'en Administrateur que le message d'erreur apparaît. J'ai donc fait des recherches, suis tombée sur votre discussion, suis allée sur le site support de Microsoft, mais leur proposition de résolution est, pour moi, complètement incompréhensible...

Je cite :
Pour résoudre ce problème, exécutez le script de compatibilité Office 97 Office97.cmd, qui doit déjà être chargée sur un serveur Terminal Server et assurez-vous qu'utilisateurs disposent d'autorisations appropriées :

1. Sur l'ordinateur qui exécute Terminal Server, démarrez l'invite de commande MS-DOS et tapez la commande suivante pour mettre Terminal Server en mode Installer : modifier utilisateur /install

2. Utiliser l'outil recherche des fichiers pour localiser le fichier Office97.cmd .
3. Dans le volet Résultats de la recherche, double-cliquez sur le fichier Office97.cmd pour exécuter le script de compatibilité.
4. À l'invite de commande MS-DOS, tapez la commande suivante pour revenir des services Terminal Server en mode exécution : changer d'utilisateur/exécution

5. Assurez-vous que les utilisateurs disposent des autorisations suffisantes (Read/Execute) créer fichiers .ldb pour le fichier de groupe groupe de travail (*.mdw) qui utilise Access.
6. Wrkgadm.exe permet de vérifier que le fichier .mdw correct est sélectionné.

Source : http://support.microsoft.com/kb/301966

Quelqu'un pourrait-il me traduire ?

D'autre part, cette résolution concerne apparemment les connexions TSE. Mais qu'en est-il pour les connexions Citrix ? J'aurai quand même bien testé cela...

[birding11]

Bon, finalement, pour moi, tout s'est arrangé...
Et assez simplement.
Il suffisait de rajouter dans la sécurité du fichier : l'administrateur du domaine.

Pour l'instant, ça fonctionne...

A savoir, c'est sûrement une résolution très spécifique à la configuration réseau de l'Ets...