Discussion :

[thovan]

Bonjour,

Pour notre entreprise j'ai développé une application en VB.NET qui se connecte sur une DB Access.
Aucun problème, tout fonctionne bien...

Mais, j'ai un utilisateur qui à ce message lors de la connexion :
Le moteur de la base de donnée Jet ne peut pas ouvrir le fichier "blablabla.mdb". Il est déjà ouvert en mode exclusif par un autre utilisateur, ou vous devez avoir l'autorisation de visualiser ses données.

J'imagine que l'accès est refusé car son PC n'est pas dans le domaine...
Mais curieusement, si je vais manuellement ouvrir la base de donnée avec access, je n'ai aucun refus...

Est-ce un problème de code?
ou de base de donnée ?

J'ai fouillé le net et je tombe chaque fois sur la même solution, via la gestion des accès sur la base, mais rien n'y fait....

Quelqu'un aurait une idée ?

[r.morel]

Il est déjà ouvert en mode exclusif par un autre utilisateur, ou vous devez avoir l'autorisation de visualiser ses données.

Bonjour,
J'ai créé une application qui utilise une petite base de données Access. Ce message apparait par exemple si tu modifie la base dans Access en mode exclusif pour faire par exemple des modifications de structure car cela impose que pendant ses modifications personne ne puisse modifier la base en simultané.
Vérifie que personne ouvre la base en mode exclusif dans Access ou qu'un processus verrouille la base.

[thovan]

Yep,

Merci... mais ce n'est pas le cas...
Les utilisateurs ne font que lire des données.

Seulement à la connexion, je modifie l'une ou l'autre info genre champ boolean "connecté", string heure de connexion, ect ect....
Mais aucune modification de structure.

D'ailleurs pour dépanner, je lui fais tourner l'appli sur un bureau à distance sur un serveur....qui bien sur lui est dans le domaine...
Je suis quasi sur que c'est le domaine le problème.

[Phil Rob]

Bonjour,

Ce n'est peut-être pas le cas, mais il arrive que des applications "Office", dont Access, lorsqu'elles sont manipulées via VB, ne libèrent pas tous les process qu'elles activent, par exemple à cause d'une instance non Dispose(), ou d'un fichier non Close().
Il s'agit d'examiner les process du système pour vérifier s'il ne reste pas un ou plusieurs "Access" actifs alors que l'application est fermée. A noter que dans ce cas, le problème devrait disparaître après un Reboot du système.

Autre point à vérifier, vu que le problème survient sur un PC et pas sur d'autres, voir si l'utilisateur possède les mêmes droits que les autres, notamment pour l'accès en modification au fichier .ldb. Dans ce cas, la suppression du fichier .ldb avant de lancer l'application devrait résoudre le problème (à condition toutefois que le user ait les droits sur le dossier de la .mdb).

J'espère que ceci te donnera de bonnes pistes de recherche ...

[thovan]

Hello,

Merci pour la réponse, qui contient quelques pistes intéressantes.

Ceci dit, les autres utilisateurs n'ont pas de soucis à se connecter alors que la DB est déjà ouverte par quelqu'un d'autre

Mais, ce que tu dis au niveau des droits intéressant... vu que n'étant pas dans le domaine, elle n'hérite pas de droits de l'active directory...
Peut-être qu'en la mettant admin local de sa machine ça marchera... je testerai.

Mais ça n'explique pas pourquoi je peux sans problème parcourir le réseau et ouvrir la DB avec access depuis son poste

[Phil Rob]

Mais ça n'explique pas pourquoi je peux sans problème parcourir le réseau et ouvrir la DB avec access depuis son poste

De son poste, avec son login, ce n'est pas possible ..., ou ton utilisateur "dégage des ondes maléfiques ..." .
Mais de son poste avec ton login, c'est possible si tu possèdes des droits supérieurs aux siens.

[thovan]

non non, c'est bien de son poste avec son utilisateur !!

[Phil Rob]

Alors là, une seule solution : un prêtre exorciste.

Ou bien, suivre pas à pas (en détail, touche après touche, click après click, ...) les manœuvres de l'utilisateur : il y a forcément quelque chose qu'il fait différemment de toi.

[thovan]

C'est jeté direct au login
Je ne sais rien suivre à partir pop le message d'erreur...

Je suis quasi certain que c'est parce qu'elle n'est pas dans le domaine...

Mais, la mettre dans le domaine effacerait tous ses fichiers locaux.... (dixit mon collègue infra) et elle gère les affaires perso du boss........
LOL !

[r.morel]

Quelle est ta méthode de connexion ?

[thovan]

Ultra classique :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
            Dim myconnexion As OleDbConnection = New OleDbConnection
            Dim provider As String
            Dim connstring As String
            provider = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source= "
            connstring = provider & fonctions.GetDBPath()
            myconnexion.ConnectionString = connstring
            myconnexion.Open()

la DB n'est par ailleurs même pas protégée par login/mot de passe !

[ProgElecT]

Salut
connstring = provider & fonctions.GetDBPath() & ";User Id=admin;Password=;" peut être
de plus
myconnexion.CursorLocation = 3 avant myconnexion.Open()

[r.morel]

Pour ma part j'utilise le provider Microsoft.ACE.OLEDB.12.0 car il s'agit d'un fichier Access de version > 2007 (accdb).
N'est ce pas ton cas ?

[thovan]

Pour ma part j'utilise le provider Microsoft.ACE.OLEDB.12.0 car il s'agit d'un fichier Access de version > 2007 (accdb).
N'est ce pas ton cas ?

Non, pour des raisons de je sais plus trop quoi, je pense compatibilité, j'ai pris une version antérieure...

[thovan]

Salut
connstring = provider & fonctions.GetDBPath() & ";User Id=admin;Password=;" peut être
de plus
myconnexion.CursorLocation = 3 avant myconnexion.Open()

ok je vais tester ça.
Juste pour ma culture :
myconnexion.CursorLocation = 3sert à quoi ?

EDIT :
myconnexion.CursorLocation = 3 se souligne en rouge dans visual studio...
CursorLocation n'est pas un membre de OleDbConnection

[ProgElecT]

Arf,

EDIT :
myconnexion.CursorLocation = 3 se souligne en rouge dans visual studio...

en effet, CursorLocation appartient à ADODB.Connection alors que toi tu es en OleDbConnection.
Si tu supprimes cette ligne CursorLocation = adUseClient, par contre le passage de ";User Id=admin;Password=; te donne une erreur, la même que signalé au début de la discussion ?

[thovan]

Bon... ça ne marche pas....

Observation :

Pour l'instal du client, j'utilise click once.
Je déploie donc un exe d'instal dans un répertoire publique sur le réseau.

Une exécution de ce fichier n'est pas autorisée non plus !
Je dois faire une copie en local pour pouvoir installer l'appli....

Chose que je n'ai jamais, en dehors des machines hors du domaine....

[Phil Rob]

Bonjour,

Selon ton dernier message, il faudrait que l'administrateur de cet ordinateur donne les droits d'accès en contrôle total pour permettre l'installation correcte de l'application.
Il est aussi possible que cela fonctionne mieux avec "Exécuter en tant qu'Administrateur".

[thovan]

ça ne change rien du tout...

depuis le réseau : lancer le setup en admin : accès refusé
copie locale : lancer le setup en admin : ok.... connexion à la DB : niet !

[Pol63]

C’est surtout qu’avec les bons outils c’est mieux.
Access n’est pas une base réseau comme sql server (la version express étant gratuite).
Ajouté à cela qu’un dossier partagé est considéré comme une faille de sécurité par certains.