Comment partager proprement la base frontale ?

Version imprimable

06/09/2018, 10h21
Golard

Comment partager proprement la base frontale ?
Bonjour,

J'aurais besoin d'un conseil.
Le contexte: Je développe une nouvelle base sous Access 2010 et je serai migré dans les mois qui viennent vers Access 2016.
L'application sera multi-utilisateur (environ 4 à 5 utilisateurs maximum en même temps)

J'ai développé ma base en séparant les données (dorsale) de l'interface (frontale).
La structure conseillée que j'ai trouvé dans les tutos consiste à ne mettre que la dorsale en réseau, tandis que la frontale est installée sur chaque poste client.
Cependant, il s'agit de tutos datant en général d'Access 2007 ou avant.
Est-il toujours préconisé de mettre la frontale sur chaque poste client sous Access 2010 ou Access 2016 ?

En complément d'information, il y a dans ma société certaines petites bases Access qui fonctionnent en ayant la frontale sur le réseau.
Si j'essaye de mettre ma nouvelle application avec la frontale sur le réseau de la même façon, j'ai un message d'erreur quand une seconde personne essaye de se connecter:
"La base de donnée a été placée par l'utilisateur <Admin> sur <.........> dans un état l'empêchant d'être ouverte ou verrouillée."
Avez-vous une idée de ce que je dois modifier dans mon code pour permettre que la même frontale soit ouverte par plusieurs utilisateurs ?

En conclusion et pour résumer:
- Dois-je modifier (et comment) la méthode que j'utilise pour ouvrir ma base dorsale ou mes tables ?
- Est-ce inutile de changer quoi que ce soit car il est de toutes façons fortement déconseillé d'ouvrir la même dorsale par plusieurs utilisateurs ?
Merci beaucoup d'avance de vos réponses.
06/09/2018, 13h05
marot_r

Bonjour.

Citation:

Cependant, il s'agit de tutos datant en général d'Access 2007 ou avant.
Est-il toujours préconisé de mettre la frontale sur chaque poste client sous Access 2010 ou Access 2016 ?

C'est recommende car cela ameliore les performances si tu as plus d'une dizaine de personnes, mais ce n'est pas indispensable.
Avec si peu d'utilisateurs tu peux faire un test en mettant la frontale sur le reseau et voir ce que cela donne.

Citation:

"La base de donnée a été placée par l'utilisateur <Admin> sur <.........> dans un état l'empêchant d'être ouverte ou verrouillée."
Avez-vous une idée de ce que je dois modifier dans mon code pour permettre que la même frontale soit ouverte par plusieurs utilisateurs ?

Suprenant car par defaut Access est assez laxiste sur la securite.

Ce message se produit generalement quand quelqu'un change la structure de la BD frontale.
Par exemple, tu es en train de modifier un formulaire ou du code VBA.
Depuis les versions 2000, on ne peut plus modifier un appli et laisser les utilisateurs s'en servir en meme temps.

Est-ce que tu etais en train de modifier ta frontale ?

Sinon cela peut venir d'une ouverture en mode "exclusive" de la BD mais il faut une action deliberee de la part de l'utilisateur donc ca m'etonnerai que ce soit cela.

A+
06/09/2018, 16h42
Golard

Merci marot_r pour ta réponse !

Citation:

Envoyé par marot_r

(...)
C'est recommende car cela ameliore les performances si tu as plus d'une dizaine de personnes, mais ce n'est pas indispensable.
Avec si peu d'utilisateur tu peux faire un test en mettant la frontale sur le reseau et voir ce que cela donne.
(...)

Ok merci pour cette précision. Il n'est donc pas "déconseillé" d'avoir la frontale en réseau, mais je garde à l'esprit que cela amoindri les performances.
D'après mes premiers tests, je vais sans doute devoir déporter la frontale sur les postes utilisateurs, car je trouve déjà la base lente avec un utilisateur unique !!!

Citation:

Envoyé par marot_r

(...)
Suprenant car par defaut Access est assez laxiste sur la securite.
(...)
Est-ce que tu etais en train de modifier ta frontale ?
Sinon cela peut venir d'une ouverture en mode "exclusive" de la BD mais il faut une action deliberee de la part de l'utilisateur donc ca m'etonnerai que ce soit cela.
(...)

Non je n'étais absolument pas en train de modifier la frontale.
J'en déduis que cela vient de syntaxes et/ou méthodes que j'utilise :calim2:

La plupart de mes requêtes SQL sont codées en VBA.
J'ai notamment eu la mauvaise (?) idée de terminer toutes mes requêtes par "WITH OWNERACCESS OPTION;"
Je suppose que cela pose problème ?

Pouvez-vous m'indiquer quelle autre type d'erreur je dois rechercher pour "libérer" ma base ?
Y-a-t'il des paramétrages à éviter dans la frontale comme dans la dorsale pour permettre le multi utilisateur ?

Merci pour votre aide.
06/09/2018, 18h13
marot_r

Bonjour.

Une chose a eviter dans Access s'est d'ecrire le SQL soi-meme.
Il est grandement preferable de laisser Access s'en occuper.
La syntaxe etant parfois pas mal exotique.

Pour :

Citation:

"WITH OWNERACCESS OPTION;"

Aucune idee de ce que cela peut faire a Access. Je n'ai jamais utilise de une tel clause.

En plus avec les nouvelles versions, on est tous "admin" quand on utilise une BD Access donc cela n'apporte aucune securite/avantage.

Mettre les requettes dans le VBA empeche Access de les optimiser ce qui ne contribue pas forcement a le rendre rapide.

Je n'ai pas d'autres idee sur d'ou pourrait provenir le blocage.

Essaye en mettant une nouvelle BD avec juste une table et un formulaire sur ton reseau et vois si elle bloque aussi ou pas.

A+
06/09/2018, 18h21
marot_r

Il me vient une idee.

Est-ce que ton code VBA modifie/cree physiquement un formulaire/rapport ou autre objet ?

Si tu ne trouves pas mettre ta BD en locale devrait contourner le probleme. Comme ce sera "ta" BD tu peux bien y faire ce que tu veux.
Attention avec des BD un peu partout, n'oublie pas de mettre en place un processus pour les mises a jour.
Ce processus peut-etre manuel par toi du genre "Hello, c'est votre informatition prefere qui vient faire la mise a jour"
Ou tu envoies un courriel avec un lien ou des instructions d'installation.
Ou automatique, le systeme se charge de se mettre a jour. Il y a plusieur version pour cela de la plus simple (mise a jour systematique au demarage) a la plus complexe (verification de version et Mise a jour sous conditions).

A+
06/09/2018, 20h42
tee_grandbois

bonsoir rené,

Citation:

Aucune idee de ce que cela peut faire a Access. Je n'ai jamais utilise de une tel clause.

pour info, dans le tuto du langage SQL du site il y a ceci:
https://access.developpez.com/sql/#L1.2.3
et aussi, plus complet, sur le site de Microsoft:
https://msdn.microsoft.com/fr-fr/lib.../ff196724.aspx
06/09/2018, 21h17
marot_r

Bonjour.

Merci tee_grandbois.

Citation:

Dans un environnement Multi-Utilisateurs où figure un groupe de travail protégé, la déclaration WITH OWNERACCESS OPTION permet dans le cadre d'une requête d'accorder à l'utilisateur qui exécute cette requête les mêmes autorisations qu'au propriétaire de la requête.

Est-ce maintenu pour la retro compatibilite avec Access 2003 et avant ?
Autant que je sache il n'y a plus de groupe de travail protégé ou alors c'est un truc relie directement a la securite de Windows ?
Le plus etrange est que c'est mentionne sur le site de M$ pour Access 2013 | Access 2016.

Tu as des details sur cela ?

A+
06/09/2018, 21h26
Arkham46

Bonjour,

La sécurité au niveau utilisateur fonctionne toujours à condition d'utiliser l'ancien format mdb.

Pour la frontale elle passe en mode exclusif à la moindre modification : cela inclu les modifications des liens des tables qu'on met souvent à l'ouverture.
11/09/2018, 12h08
Golard

1 pièce(s) jointe(s)
Bonjour et merci pour vos réponses,

Concernant "WITH OWNERACCESS OPTION", je l'avais effectivement mis dans le but de faciliter le fonctionnement multi-utilisateur (comme précisé dans le lien MSDN fourni par tee_grandbois).
Je l'ai actuellement mis en commentaire dans toutes mes requêtes VBA, donc il n'y en a plus dans mon appli.
Cependant le problème se pose toutjours.

J'ai donc suivi le conseil de marot_r et j'ai créé une toute petite base avec une table pour test.
Je l'ai simplifiée à l'extrême et j'ai même mis la table initialement dans la dorsale directement dans la frontale et le problème se pose toujours à la seconde ouverture.

Je vous la met cette petite base accdb en pièce jointe afin que vous puissiez la tester vous-même (elle fonctionne sans dorsale) et me dire ce qui cloche.

Son fonctionnement est le suivant:
1. Lancement de la fonction MyMain via la macro AutoExec
2. Vidage de l'unique table tbl_Anomalie
3. Affichage d'un formulaire avec comme sous-formulaire le contenu de la table (extrait par requête)
Dans la vraie version, la table des anomalies est renseignée à nouveau après vidage ainsi qu'après chaque modification de l'utilisateur, mais cela n'est pas nécessaire pour provoquer l'erreur.
On voit bien que le simple fait d'afficher le contenu de la table empêche le second utilisateur de la modifier...
J'espère que vous trouverez une erreur évidente que décidément je ne vois pas.

Merci d'avance :)

PS: la base est au format Access 2010.
11/09/2018, 12h30
marot_r
Bonjour.

Pour des raisons de securite, je ne peux pas installer ton appli de test.

Qu'est-ce que tu utilises pour la suppression des donnees : delete * from taTable ou une suppression de la table elle-meme. ?

Si c'est la suppression de la table, cela pourrait expliquer pourquoi 2 utilisateurs ne peuvent pas se connecter.

Quand a la BD de test, je la voyais encore plus simple : une table, un formulaire sur cette table. Pas de code, pas d'autoexec, vraiment le minimum.

A la limite, juste une table toute seule.

Verifie dans les options de ta BD (je l'ai qu'en Anglais pour 2016 mais ca doit etre semblable en 2010).
- Menu fichiers
- Options
- Client Setting
- Advanced (grosso modo au mileu de l'ascenceur vertical)
- Default open mode : Shared
- Default Record Locking : Record lock
A+

2 pièce(s) jointe(s)

Bonjour marot_r,

Non je ne supprime pas la table, mais les enregistrements via "DELETE * FROM tbl_Anomalie"

Pour précision, voici l'intégralité de mon module VBA:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Option Compare Database Public Function MyMain() As Boolean MyMain = False MsgBox "Application test pour l'utilisation de la frontale en multi-utilisateur..." Call tbl_Anomalie_EMPTY Call DoCmd.OpenForm("frm_AccueilTest", acNormal) MyMain = True End Function
Code:

1 2 3 4 5 6 7 8 9 10 11 12 Private Function tbl_Anomalie_EMPTY() As Boolean '// OBJET: Vidage TOTAL de la table tbl_Anomalie '// RETOUR: tbl_Anomalie_EMPTY = True si le vidage s'est bien déroulé '// NOTE: Autre solution = Call CurrentDb.Execute("DELETE * FROM tbl_Anomalie;") Dim strSQL As String strSQL = "DELETE * FROM tbl_Anomalie" 'strSQL = strSQL & " WITH OWNERACCESS OPTION" strSQL = strSQL & ";" 'Exécution de la requête tbl_Anomalie_EMPTY = DB_sql_Execute(strSQL) End Function
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 Public Function DB_sql_Execute(ByVal strSQL As String) As Boolean '// OBJECT: Exécution de la requête avec détection et précision des erreurs rencontrées (grace à dbFailOnError) '// MSGBOX: Le message d'erreur précise la description de l'erreur ainsi que la commande SQL concernée '// NOTES: La syntaxe simple "CurrentDb.Execute strSQL" ne provoque pas de message d'erreur quand l'exécution est impossible '// SORTIE: DB_sql_Execute = True si pas d'erreur Dim errLoop As Error 'Par défaut pas d'erreur DB_sql_Execute = True On Error GoTo Err_Execute CurrentDb.Execute strSQL, dbFailOnError On Error GoTo 0 Exit Function Err_Execute: ' Notify user of any errors that result from executing the query. If DBEngine.Errors.Count > 0 Then For Each errLoop In DBEngine.Errors MsgBox "Error number: " & errLoop.Number & vbCr & errLoop.Description & vbCr & vbCr & strSQL Next errLoop End If 'On retournera False puisqu'il y a eu une erreur DB_sql_Execute = False Resume Next End Function
J'ai contrôlé les Options (image jointe): je suis bien en ouverture par défaut = "Mode partagé", et pour le verrouillage par défaut, je suis encore moins restrictif que tu le proposes puisque je suis positionné sur = "Aucun". Par contre, je ne comprends pas la signification de la case à cocher "Ouvrir avec enregistrements verrouillés"...

J'ai refait un test en décochant la case à cocher, c'est à dire Mode d'ouverture par défaut = "Mode partagé" + verrouillage par défaut = "Aucun" + case à cocher décochée: même problème
J'ai aussi essayé le paramétrage que tu conseilles, c'est à dire Mode d'ouverture par défaut = "Mode partagé" + verrouillage par défaut = " Enregistrements modifiés" + case à cocher décochée: toujours même problème

Sur mon poste Admin, le libellé de l'erreur est (image jointe): 3086, Impossible de supprimer dans les tables spécifiées.
Sur un poste client le libellé de l'erreur est: 3262, Impossible de verrouiller la table "tbl_Anomalie", car elle est actuellement utilisée par l'utilisateur "Admin" sur l'ordinateur "*****".

Que penser de ce dernier message ? Pourquoi la seconde appli ne peut pas verrouiller la table le temps de la suppression alors que la première ne fait qu'afficher le contenu dans un formulaire ?

11/09/2018, 17h00
marot_r

Desole pas d'idee.

Essaye avec une BD avec juste une simple table et rien d'autre.
Voit si tu peux y acceder de 2 postes.

Si cela marche, sorts de l'autre poste, ajoute un formulaire de consultation. (Avec l'assistant, pas la peine de te casser la tete).
Voit si tu peux y acceder de 2 postes.

Si cela marche, selectionne a la main toutes les donnees et demande une suppression.

Si cela marche, remet des donnees et ajoute du code pour la suppression, sans l'excuter.
Voit si tu peux y acceder de 2 postes.

Demande l'execution du code.
Voit si tu peux y acceder d'un 3ieme poste 2.

Cela va peut-etre nous donner une piste.

A+
12/09/2018, 17h43
Golard

Bonjour marot_r,

Merci de ton suivi.

J'avais déjà fait une partie de ces tests hier: les 2 bases acceptaient bien de s'ouvrir en affichant le contenu de la table.
C'est seulement lorsque j'ai ajouté le vidage de la table que l'erreur de partage apparaissait.

Cependant, voici les résultats du test que tu me proposes:

Citation:

Essaye avec une BD avec juste une simple table et rien d'autre.
Voit si tu peux y acceder de 2 postes.

Je créé uniquement la table "tbl_Anomalie".
Je renomme ma base accdb en accdr.
==> Ok ça fonctionne

Citation:

Si cela marche, sorts de l'autre poste, ajoute un formulaire de consultation. (Avec l'assistant, pas la peine de te casser la tete).
Voit si tu peux y acceder de 2 postes.

Je créé un formulaire sur la table avec l'assistant (disposition = colonne simple).
Je choisis ce formulaire comme formulaire de démarrage pour la base active.
Je renomme ma base accdb en accdr.
==> Ok ça fonctionne

Citation:

Si cela marche, selectionne a la main toutes les donnees et demande une suppression.

Pour ce test, je ne renomme pas en accdr afin de pouvoir accéder à la table manuellement.
(remarque: aujourd'hui je ne dispose que d'un unique poste. Donc pour pouvoir ouvrir 2 occurrences accdb sur un même poste j'utilise un bout de code VBA dans une autre base qui me permet d'ouvrir 2 occurrences différente du même fichier)
Je sélectionne toutes les données sur la deuxième occurrence et je supprime.
==> Ok ça fonctionne

Citation:

Si cela marche, remet des donnees et ajoute du code pour la suppression, sans l'excuter.
Voit si tu peux y acceder de 2 postes.

J'ajoute un module à la base.
J' ajoute les 2 fonctions tbl_Anomalie_EMPTY() et DB_sql_Execute() dont le code est précisé dans le fil de discussion.
Je renomme ma base accdb en accdr.
==> Ok ça fonctionne

Citation:

Demande l'execution du code.
Voit si tu peux y acceder d'un 3ieme poste 2.

Je réouvre les 2 occurrences en accdb et je demande l'exécution du code sur le deuxième occurrence.
J'ouvre une 3ème occurrence.
==> Ok ça fonctionne

:cfou: ???
J'ai ensuite refait tous les tests en choisissant un formulaire avec disposition = feuille de données (car c'est ce que j'utilise dans mon appli)
==> ça fonctionne toujours
J'ai ensuite placé ce formulaire dans un formulaire de navigation (car c'est ce que j'utilise dans mon appli)
==> ça fonctionne toujours

!!! Avant de pousser encore la modification de la base (à l'origine, ma feuille de données est un sous-formulaire d'un formulaire constitutif du formulaire de navigation), je vais attendre d'avoir à nouveau accès à différents poste.
En effet, comme je l'ai précisé plus haut, je ne dispose aujourd'hui que d'un unique poste. Donc toutes les occurrences s'ouvrent sous mon compte et cela fausse peut-être complètement le test...

Je pourrais redonner des précisions en réel multi poste demain ou vendredi :)

Merci encore pour ton aide
12/09/2018, 20h22
marot_r

Bonjour.

Citation:

Je renomme ma base accdb en accdr.

Le probleme vient peut-etre de la.
Cela met la BD en mode "runtime" et en mode runtime certaines fonctionnalites ne sont plus disponibles.
Ou pas disponible exactement de la meme facon.
Personnellement je ne vois pas d'interet a utiliser un tel mode car les accdr sont simplement des accdb qui ne dissent pas leur nom.

Fait un essais en gardant ta BD d'origine en accdb.

A+
12/09/2018, 20h24
marot_r

En passant Access n'a pas, autant que je sache, de "memoire" d'utilisateur donc si tu ouvres 2 fois la meme appli, pour Access tu es 2 personnes differentes.

Tes tests devraient donc etre representatifs.

A+
13/09/2018, 19h28
Golard

Bonjour marot_r,

Alors voici de nouvelles infos !
Tout d'abord, laisser la base en accdb ne change rien (j'avais déjà essayé tu penses bien!).
Au départ je partais même d'une base compilée pour optimiser les performances, mais j'ai abandonné pour l'instant car la base compilée ne l'est que pour du 32bits ou 64bits, pas les 2 en même temps (or en ce moment on a les 2 types de postes sur mon site).

Citation:

Cela met la BD en mode "runtime" et en mode runtime certaines fonctionnalites ne sont plus disponibles.
Ou pas disponible exactement de la meme facon.

Je t'explique pourquoi je préfère mettre la base en accdr. La principale raison est que certains utilisateurs ne sont pas forcément "des as de la gâchette" et je préfère masquer les menus inutiles et surtout la liste des éléments (la touche F11 est sans effet sur une accdr). Ainsi, je suis sur que les utilisateurs se limitent à l'utilisation de l'interface. Une autre raison est que la plupart des utilisateurs dans mon entreprise ne disposeront que du runtime... Du coup mettre la base en "mode runtime" n'a rien de génant. Qu'en penses-tu, dis moi si je fais fausse route !

J'ai procédé aujourd'hui à un test avec 2 postes et cela ne change effectivement rien.

Citation:

Access n'a pas, autant que je sache, de "memoire" d'utilisateur donc si tu ouvres 2 fois la meme appli, pour Access tu es 2 personnes differentes.

Tu as à priori raison. Je pensais qu'Access pouvait "me reconnaitre" car il inscrit le même identifiant plusieurs fois dans le fichier .laccdb

CONCLUSION:
En conclusion, je n'ai plus qu'à trouver ce qu'il y a de différent entre mes 2 bases de test puisque la première (issue de copiés/collés export/import de ma vraie base) ne fonctionne pas et que la seconde (construite de toute pièce sur tes conseils) fonctionne.
J'espère avoir le temps de trouver ça demain. Il y a notamment une différence notable que je viens de remarquer: la base qui ne fonctionne pas utilise le résultat d'une requête pour afficher la liste, tandis que la liste de la seconde a été créée par l'assistant...

Merci de ton aide :)
18/09/2018, 10h30
Golard

La liste liée Sharepoint verrouille toute la base access !!!

Bonjour,

Voici de quoi relancer la discussion car j'ai trouvé ce qui cloche... mais pas comment solutionner le problème !

Le diagnostic a été long car plusieurs problèmes se superposaient, comme certaines propriétés de verrouillage paramétrées en dur dans les formulaires.
Une fois ces paramétrages corrigés, la base de test fonctionnait enfin et j'ai continuer de la faire ressembler de plus en plus à ma vraie base jusqu'à trouver une autre source du problème:

Ma base possède une table liée avec Sharepoint (on parle alors de liste liée).
Le problème est que le simple fait d'ouvrir la base avec une table liée Sharepoint VERROUILLE l'ensemble de la base !!!

Je ne trouve pas comment empêcher ce verrouillage :calim2:
Avez-vous une idée ?