Discussion :

[cbleas]

Bonjour je souhaiterais limiter en VBA le nombre d'utilisateurs qui pourront ouvrir la base en simultané. Pouvez vous m'indiquer si c'est possible et comment le réaliser?

merci

[argyronet]

Bonjour,

Une solution consisterait à stocker le login de l'utilsateur en cours dans une table. Ensuite à chaque ouverture de la base, une procédure irait compter le nombre de logins déjà rentrés. Si le RecordCount dépasse la valeur souhaitée alors tu affiches un message interdisant momentanéement l'accès et tu quittes.
Enfin, un utilisateur qui quitte l'application voit alors son login effacé de cette table.

Bien entendu, cette solution oblige un temps soit peu une connexion de quelques secondes (lecture du message), là, c'est pas possible d'y parer sauf avec un programme annexe (VB6) qui vérifirait alors avant de lancer l'application.

Argy

[cbleas]

cette solution très simple me parait plus qu'intéressante pour moi car elle pourra etre mise en oeuvre aussi bien sur access que sur sql server.
Merci

[tAKAmAkA]

La solution est simple, en effet. Pour continuer une discussion que je n'ai pas initiée mais qui peut être passionnante je vous livre mes réflexions et interrogations:
Il faut créer une table tblUserConnect avec par exemple UserId (numauto) et UserConnect (texte,20) une table tblNbConnect avec NbConnectId (octet) qui contient le nb d'utilisateurs autorisés.
Si l'appli ne travaille que sur une base Data on peut les y inclure.

Si la solution est "multibase" il faudrait alors créer une nouvelle base pour ces deux tables.

Le code a inclure dans le formulaire de démarrage:
A l'ouverture:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Private Sub Form_Open(Cancel As Integer)
Dim SQLins As String
'Insertion du loggin dans la table de contôle d'accès tblUserConnect :
SQLins = "INSERT INTO tblUserConnect(User) VALUES ('" & Application.CurrentUser & "');"
    Debug.Print "SQL :" & SQLins
    DoCmd.RunSQL SQLins
'Comptage du nombre d'accès et comparaison avec nombre défini dans tblNbConnect :
Debug.Print "Dcount :" & DCount("UserId", "tblUserConnect")
Debug.Print "DLook :" & DLookup("NbConnectId", "tblNbConnect")
If DCount("UserId", "tblUserConnect") > DLookup("NbConnectId", "tblNbConnect") Then
    MsgBox "depassement"
    DoCmd.OpenForm "frmDepassement"
End If
 
End Sub

A la fermeture:

Code :

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

1
2
3
4
5
6
7
8
9
Private Sub cmdQuitter_Click()
Dim SQLdel As String
'Effacement du user dans tblUserConnect :
SQLdel = "DELETE FROM tblUserConnect WHERE [User] = '" & Application.CurrentUser & "';"
 
    DoCmd.RunSQL SQLdel
 
    Debug.Print "SQL :" & SQLdel
        Application.Quit

Ce formulaire doit rester ouvert pendant l'utilisation de l'appli.
Le formulaire signalant le dépassement comporte un bouton qui ferme l'application.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
Private Sub cmdDepassement_Click()
On Error GoTo Err_cmdDepassement_Click
     'DoCmd.Close 'debug
    Application.Quit
 
Exit_cmdDepassement_Click:
    Exit Sub
Err_cmdDepassement_Click:
    MsgBox Err.Description
    Resume Exit_cmdDepassement_Click
 
End Sub

Ce formulaire est en modal independant, bouton "Fermer" désactivé, bref prendre toutes les précaution pour obliger l'utilisateur à quitter l'appli.

Ca, ça marche et du coup je ne comprends pas argy:

Bien entendu, cette solution oblige un temps soit peu une connexion de quelques secondes (lecture du message), là, c'est pas possible d'y parer sauf avec un programme annexe (VB6) qui vérifirait alors avant de lancer l'application.

.

Ensuite (cogitation non testées, votre avis est le bien venu)
1-il faut sécuriser les deux tables pour éviter que l'utilisateur modifie le nombre d'accès autorisé ou efface des User.
Lecture seule sur tblNbConnect, Insertion et effacement sur tblUserConnect.
2-Bien sûr il ne faut pas que l'utilisateur puisse agir sur tblUserConnect sans passer par l'appli, c'est à dire en ouvrant le fichier Data en utilisant le fichier de sécurité. Comment faire?
3-Que se passe-t-il en cas de plantage? L'utilisateur n'étant pas effacé on perd 1 accès.
4-Comment faire pour que, dans le cas d'une installation par le client, l'utilisateur rentre le nombre d'accès autorisé, et pas un nombre plus important? (J'essaie de faire des appli standard sans personnalisation dans le code).
5-Il faut coupler le User Appli avec le User Windows dans la table tblUserConnect, car si le même utilisateur ouvre des sessions sur plusieurs postes, le fait de quitter l'appli sur un seul poste efface tout les User qui portent le même nom.

En fait, pas si simple...
A votre avis?

[marot_r]

3-Que se passe-t-il en cas de plantage? L'utilisateur n'étant pas effacé on perd 1 accès.

Clairement cela prend un code d'utilisateur (ex : SuperUser) dont la connexion n'est pas limité et qui peut supprimer les utilisateurs de cette table.

Pour éviter que les utilisateurs soient enlevés de la table après leur connexion et ainsi permettre une sur-utilisation, il conviendrait de vérifier à chaque ouverture d'écran par exemple si son nom est dans la liste.

A+

[tAKAmAkA]

Marot r, je ne saisi pas le rapport avec le point 3

Clairement cela prend un code d'utilisateur (ex : SuperUser) dont la connexion n'est pas limité et qui peut supprimer les utilisateurs de cette table.

peux-tu éclaircir s'il te plait?

Sinon,

Pour éviter que les utilisateurs soient enlevés de la table après leur connexion et ainsi permettre une sur-utilisation, il conviendrait de vérifier à chaque ouverture d'écran par exemple si son nom est dans la liste.

peut être une garantie supplémentaire par rapport à un contrôle via mdw (que je m'apprête à tester).

[marot_r]

Marot r, je ne saisi pas le rapport avec le point 3 peux-tu éclaircir s'il te plait?

Si tu plantes trop souvent tu pourrais avoir x utilisateurs fantomes connectés à ta base et si x correspond à ton nombre max d'utilisateurs tu ne peux plus te connecter du tout.

Donc cela te prends un utilisateur qui peut TOUJOURS se connecter quel que soit le nombre d'utilisateurs connectés pour faire le ménage dans tes utilisateurs.

A+

[Domi2]

Bonsoir,

Si je peux me permettre...

Pourquoi ne pas lire simplement le nombre de connections dans le .ldb ?

Domi2

[tAKAmAkA]

Exact, c'est dans la FAQ.
Je n'ai pas encore testé. Je le fais dès que j'en ai fini avec la solution par les tables.

[tAKAmAkA]

J'ai laissé tomber le principe d'écrire les connexions dans une table, trop compliqué, trop d'aléas et sécurité trop lourde à gérer.
La lecture du fichier ldb est beaucoup plus simple.
Mais quel ldb choisir?
Il y en a trois dans le cas d'une application fractionnée et sécurisée.
Celui de la frontale, celui de la dorsale et celui du fichier de sécurité.
-Celui de la frontale n'a pas d'interêt car il est sur le poste de l'utilisateur et, à priori, les autres utilisateurs sont sur d'autres postes.
-Celui de la dorsale est interressant car il est sur le serveur. Il n'est créé qui lors de l'accès à une table liée. ?? J'ai des tables liées dans deux bases différentes, ma dorsale "normale" et le base qui contient le nombre d'accès autorisés. Seule la dorsale crée son fichier de sécurité. Je ne saisi pas pourquoi.
-Celui du fichier de sécurité me semble interressant: il est systématiquement créé, il regroupe tous les utilisateurs même si ceux-ci sont connectés sur des dorsales différentes.

Dans le cas d'un fonctionnement avec plusieurs dorsales la base spécifique qui contient le nombre d'accès autorisé me paraît incontournable. Qu'en pensez_vous?

Le code de la fonction WHO_IS (FAQ) peut être adapté pour ramener le nombre de connexions comme ceci:

Code :

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

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
Public Function WHO_IS() As String
 ' -- retourne une liste séparée par des points virgules indiquant
 ' -- le nombre de connexion en cours
 ' -- le nom de l'ordinateur
 ' -- l'utilisateur connecté à la base.
 
On Error GoTo Err_WHO_IS
Dim Mon_LDB As Integer, i As Integer
Dim Mon_Chemin As String
Dim Mon_Log As String, Ma_Connexion As String
Dim Nom_PC As String, Nom_Utilisateur As String
Dim utilisateur As Un_Connecté
Dim cptUser As Byte
cptUser = 0
Mon_Chemin = "H:\Serveur\ProspectsSecu.ldb"
 ' --Aller chercher le LDB
Debug.Print "mon chemin :" & Mon_Chemin
Mon_LDB = FreeFile
 ' --Ouvrir le LDB
Open Mon_Chemin For Binary Access Read Shared As Mon_LDB
 ' -- Lire le LDB
Do While Not EOF(Mon_LDB)
   ' -- Chaque enregistrement lu est placé dans la variable utilisateur pour y être traité.
   Get Mon_LDB, , utilisateur
   With utilisateur
      i = 1
      Nom_PC = ""
   ' -- nom du PC
  While .PC(i) <> 0
         Nom_PC = Nom_PC & Chr(.PC(i))
         i = i + 1
    Wend
      i = 1
      Nom_Utilisateur = ""
   ' -- nom de l'utilisateur
  While .User(i) <> 0
         Nom_Utilisateur = Nom_Utilisateur & Chr(.User(i))
         i = i + 1
    Wend
   End With
   Mon_Log = Nom_PC & " | " & Nom_Utilisateur
   If InStr(Ma_Connexion, Mon_Log) = 0 Then
      Ma_Connexion = Ma_Connexion & Mon_Log & ";"
      cptUser = cptUser + 1
   End If
Loop
Close Mon_LDB
' --WHO_IS contient la liste des utilisateurs, on fait précéder du compteur
WHO_IS = cptUser & ";" & Ma_Connexion
Exit_WHO_IS:
   Exit Function
Err_WHO_IS:
      MsgBox Err.Number & vbCrLf & Err.Description, vbInformation, "Erreur"
      Close Mon_LDB
      Resume Exit_WHO_IS
End Function

.