Demande de conseil - Profil d'utilisateurs [Résolu]

[Zoupla]

Bonjour !

Juste un petit post ( qui pourrait peut-être profiter à d'autres ).

Mes utilisateurs sont stockés dans une table T_Users.
Actuellement, pour voir apparaître le nom de l'utilisateur, j'utilise des variables publiques déclarées dans un module et changées via formulaire de connexion.

Serait-il plus judicieux de créer une table temporaire "T_Temp_ProfilUser", créée par le formulaire de démarrage et contenant les données de l'utilisateur en cours. Je reprendrais les données via un dlookup, et effacerais la table lors de la déconnexion (ou la fermeture, avec mon formulaire caché ).
Je n'aurai en principe pas de problème pour créer tout cela.

Cette seconde solution vous paraît-elle la meilleure ?

[DamKre]

Je suppose que cette table serait créée à partir de ta table T_Users

Je ne sais pas ce que d'autres en pensent, mais voici un élément de réponse...

J'utilise actuellement la solution avec variables publiques. Seulement, dès qu'une erreur survient dans mes procédures, il arrive parfois que les variables publiques redeviennent nulles. Au lieu d'avoir "User_Id" ayant la valeur "Jean", la valeur devient "" ( = vide ), ce qui est ennuyeux lorsque j'ai besoin de ces valeurs par la suite. D'où "re-bug".

Merci de ton idée, je me pencherais alors là-dessus ( sur la seconde ).

Mais cela n'est que mon avis...

[Zoupla]

Envoyé par damkre

Je suppose que cette table serait créée à partir de ta table T_Users

Oui, j'aurais dû le préciser ...

D'autres avis, peut-être ?

[vodiem]

salut à tous,

Zoupla, ton soucis est de savoir si les paramètres de l'utilisateur en cours doit être mis en variable globale ou mis dans une table en somme et savoir s'il y a d'autre facon de faire?

damkre, souligne effectivement un pb sur les variables globales lors d'un pb d'exécution, mais que je considère comme un faux pb; on ne "livre" pas une appli dans ces conditions.
l'utilisation des variables globales permet un codage plus simple (si tu as du code).

le choix de l'emplacement mémoire t'incombe. les tables sont une valeur sur mais pense qu'il y a aussi l'ini, le registre, ...

je pense que tu pourrais créer une table/variable typée/... "parametres de session" où tu aurais l'index de l'utilisateur et d'autres paramètres utiles de session (répertoire courant, choix imprimante, langue, monnaie... ou autres variables propre à la session)
de ces références tu peux retrouver les données dans ta base au besoin.
c'est plus lourd mais plus structuré, cela dépend de tes besoins.

bonne continuation

[Zoupla]

Envoyé par vodiem

damkre, souligne effectivement un pb sur les variables globales lors d'un pb d'exécution, mais que je considère comme un faux pb; on ne "livre" pas une appli dans ces conditions.
l'utilisation des variables globales permet un codage plus simple (si tu as du code).

=> tu pourrais développer ?

Envoyé par vodiem

le choix de l'emplacement mémoire t'incombe. les tables sont une valeur sur mais pense qu'il y a aussi l'ini, le registre, ...

je pense que tu pourrais créer une table/variable typée/... "parametres de session" où tu aurais l'index de l'utilisateur et d'autres paramètres utiles de session (répertoire courant, choix imprimante, langue, monnaie... ou autres variables propre à la session)
de ces références tu peux retrouver les données dans ta base au besoin.
c'est plus lourd mais plus structuré, cela dépend de tes besoins.

=> là, je ne suis plus trop. Je ne suis pas un débutant d'access, je maîtrise les bases, mais je ne comprends pas

Merci de vos réponses, déjà !

[vodiem]

pour ce qui est de l'emploi des variables globales:
c'est beaucoup plus simple d'utiliser dans un code le nom d'une variable qu'une fonction pour récupérer une valeur, c'est plus lisible aussi et simple en maintenance. (bien que certains le proscrivent)
le pb lors de la conception de la base c'est qu'il arrive qu'il y ait des erreurs d'exécution de code comme souligne damkre et tu constate que les variables peuvent être réinitialisé. donc si tu donne une application qui n'est pas stable (qui peut provoquer une erreur non géré) il risque d'avoir des pb... mais dans ce cas là tu n'est pas sensé la leur donner... non plus.
et si c'est le cas, tu es vite informé de la boulette et tu fais ce qu'il faut pour que cela ne se reproduise plus.

pour ce qui est de ton soucis conceptuel:
pour te dire cela autrement, tu charges actuellement les paramètres de ton user d'une table vers des variables globales et tu voudrais savoir s'il n'est pas préférable de les mettres plutot dans une autre table temporaire que tu détruira.
je te réponds: peu importe où que tu mets les données de ton user dans une variable, une table, un fichier... à toi de voir l'intérêt que cela t'apporte et ce que tu recherche;
variable globale: vitesse, simplicité, mais 'volage'...
table: un peu plus lent, un peu plus compliqué à mettre en oeuvre, mais plus sécurisé (par rapport au plantage).
fichier: ouverture éventuelle sur d'autre application.
...
pour moi, ceux ne sont que différent emplacement mémoire.

je te conseillais seulement d'avoir dans cette emplacement mémoire que je nomme 'paramètre de session' un minimum de donnée: un id_user (et non pas toutes ses champs liés) avec d'autres paramètres de session et d'utiliser une fonction pour récupérer les données du user par l'id_user dans la table t_user.
c'est comme dans tes tables tu ne duplique pas tes champs dans tes tables secondaires tu donne la clef primaire qui te donnera le reste.
par ex: si pour le moment tu as simplement [nom], [mot de passe] tu mettra plutot [id_user] dans 'parametre de session'. et au besoin faire une fonction qui retrouve ce que tu as besoin de savoir sur user.

tu centralise donc les données propre à la session qui pourrait s'étendre par la suite à d'autre paramètre qui pourrait t'être utile.
c'est plus lourd mais plus structuré.
windows 'crée' une clef pour une session utilisateur et tu peux constater qu'il y a beaucoup à mettre quand on voit grand...
à toi de voir si cela vaut le coup de faire ainsi.

j'espère avoir été plus clair Zoupla.
mais peut être d'autre auront leur point de vue à faire partager.

[Zoupla]

Envoyé par vodiem

pour ce qui est de l'emploi des variables globales:
c'est beaucoup plus simple d'utiliser dans un code le nom d'une variable qu'une fonction pour récupérer une valeur, c'est plus lisible aussi et simple en maintenance. (bien que certains le proscrivent)
le pb lors de la conception de la base c'est qu'il arrive qu'il y ait des erreurs d'exécution de code comme souligne damkre et tu constate que les variables peuvent être réinitialisé. donc si tu donne une application qui n'est pas stable (qui peut provoquer une erreur non géré) il risque d'avoir des pb... mais dans ce cas là tu n'est pas sensé la leur donner... non plus.
et si c'est le cas, tu es vite informé de la boulette et tu fais ce qu'il faut pour que cela ne se reproduise plus.

A chaque procédure, j'ai un "on error..." Je ne sais pas si c'est de cela que tu parles. Quand le numéro de l'erreur n'est pas connu, j'ai prévu une table des erreurs...

[vodiem]

si tu as prévu une gestion d'erreur, c'est prudent de ta part et cela t'évitera effectivement des soucis (pour peu que tu gère bien l'erreur et ses conséquences).

l'idéal étant bien sur de ne pas à y avoir recours.

[Zoupla]

Envoyé par vodiem

si tu as prévu une gestion d'erreur, c'est prudent de ta part et cela t'évitera effectivement des soucis (pour peu que tu gère bien l'erreur et ses conséquences).

l'idéal étant bien sur de ne pas à y avoir recours.

Oui, évidemment ^^