Discussion :

[informer]

Bonjour à tous,

J'ai une architecture Front End (FE) Back End (BE)

A l'ouverture du FE, un formulaire invite l'utilisateur à saisir son profil et son mot de passe. Jusqu'à là , rien de plus classique !

Par contre je n'ai pas les idées claires sur comment contextualiser les données c'est à dire n'afficher que les données propres à l'utilisateur?

Merci par avance pour toute suggestion !

[marot_r]

Bonjour.

Qu'est-ce qui distingue tes données d'un utilisateur à l'autre ?
Est-ce que par exemple tu as le code l'utilsateur dans un des champs ?
Est-ce que cela marche par "secteurs" ?
Est-ce que certains formulaires sont restreints à certaines personnes ?

Bref donne quelques détails sur ton mode de discrimination pour décider qui à accès à quoi.

A+

[informer]

Bonjour marot_r,

Dans certaines tables, il y a l'identifiant Ressource. Et j'ai notamment :

• tblAction (idAction, libAction, idRessource)
• tblRessource(idRessource, profil, psw)

L'invite de connexion FE va vérifier que le profil et le psw saisis existent. Si oui alors chargement du formulaire n'affichant que les enregistrements pour idRessource sachant que c'est en FE/BE !

Faut-il déclarer une variable globale glIdRessource qui va soit servir dans la propriété Filter ou modifier le recordsource en dynamique?

[marot_r]

Bonjour.

Faut-il déclarer une variable globale glIdRessource qui va soit servir dans la propriété Filter ou modifier le recordsource en dynamique?

Tu peux faire cela.

Pour le stockage, regarde la collection TempsVars qui sont des supers variables globales (non typées) qui résistent aux "Pannes". Tant que ton appli est ouverte la variable conserve sa valeur, contrairement aux variables globales qui sont parfois réinitialisées après une erreur ou un arrêt non prévu du code.

Ici un truc sur le sujet
https://www.microsoft.com/en-us/micr...2007-and-2010/

C'est disponible à partir de A2007 il me semble.

En plus tu peux les utiliser directement partout aussi bien dans du code que dans une requête, après à toi de décider quelle est la meilleur façon de l'utiliser. Si par exemple jamais personne ne peut voir plus que ces données, un test dans une requête est trés bien.
Si tu as des super-utiisateurs qui peuvent voir les données de tous le monde alors il faudra être plus subtil : filtre dynamique, table de correspondance ? Ça dépend du contexte et de la facilité à faire la chose.

A+

[marot_r]

En complément je viens d'avoir un cas semblable, on se base sur le code de connexion de Windows pour décider si la personne voit ou ne voit pas certaines données.

Dans mes requêtes j'ai un test du type

Code :

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

IdUser like LireCritereUser

Avec public function LireCritereUser() as string qui vas lire le code de Windows et une table des usagers où j'ai un champ "EstReviseur".
Si une personne "EstReviseur" alors le résultat de LireCritereRoleUser est "*", ce qui fait qu'elle a accès à tout, sinon c'est le code lu et alors elle n'a accès qu'a ses propres données.

A+

[informer]

Merci maro_r

Super info que j'implémente de suite dans mon code!

Bon maintenant vais voir si passe par form.filter ou form.recordset !

As-tu une préférence, un retour sur la performance de l'une ou l'autre solution?

A+

[marot_r]

Bonjour.

Non je n'ai jamais rien lu là dessus ni fait de validation de performance.

Ce que j'ai vu c'est que .Filter est généralement utilisé et relativement simple à mettre en oeuvre.
Tu changes le filtre et Access s'occupe du reste : récupération des données et mise à jour de l'affichage.

Et si tu fais ce que j'ai dit dans mon dernier poste, tu peux le faire au niveau des requêtes qui allimentent tes formulaires comme cela c'est "automatique". Tu as toujours les données pour la personne concernée sans te casser la tête.

A+

[informer]

Merci marot_r pour ton aide.

J'ai décidé d'utiliser filter mais cela a généré un problème exposé dans le post ICI
Si tu pouvais y jeter un oeil, ton expertise en plus de celle d'hyperion13, est la bienvenue
A+