Récupérer l'information sur le user qui lance le trigger

Bonsoir à tous,

J'ai un trigger qui permet de remplir une table. Je voudrais récupérer l'ID ou le USER_NAME de celui qui lance ce trigger, le stocker dans cette même table, afin que le 2eme trigger efface les données de cette meme table, mais seulement les enregistrements rattachés à cet user, pour ne pas effacer les lignes des autres users. (WHERE NAMEUSER (champ table) = USER_NAME)

J'ai tout testé, SUSER_NAME, SUSER_SNAME, CURRENT_USER, USER_NAME...

Le renvoi systématique est tout le temps le même, à savoir l'ID 1

Y a t-il un process qui mappe l'uilisateur à sa connexion (via DSN accès) sur l'ID 1 ?

Je tourne je vire, je trouve pas.

Merci pour vos retours

USER

A +

Ce me ressort dbo quelque soit l'utilisateur

Parce que votre utilisateur SQL est dbo….

Si vous voulez gérer différents utilisateurs, il faut les créer au niveau de la base (et éventuellement les comptes de connexion associés) et se connecter chaque fois avec l'utilisateur approprié.

Lisez l'article que j'ai écrit à ce sujet : https://blog.developpez.com/sqlpro/p..._et_utilisateu

A +

Bonjour,

si c'est la connexion utilisée que vous voulez obtenir, alors vous pouvez utiliser ORIGINAL_LOGIN().

Cela dit, j'ai l’impression que vous montez une usine à gaz à base de triggers dans tous les sens, là où des vues bien pensées seraient surement plus simples à développer et à maintenir, en plus d'être probablement plus performantes.

Citation:

---

Envoyé par aieeeuuuuu

Bonjour,

Cela dit, j'ai l’impression que vous montez une usine à gaz à base de triggers dans tous les sens, là où des vues bien pensées seraient surement plus simples à développer et à maintenir, en plus d'être probablement plus performantes.

---

Bonjour,

Le souci étant que j'utilise la BDD depuis Access. La table concernée contient beaucoup de lignes, et utiliser une requête dans Access pour filtrer une vue (j'ai testé) prend beaucoup plus de temps que de charger une table avec un trigger et de la lire directement sous Access.
L'autre souci est que les données affichées proviennent de 3 tables avec des colonnes communes. Il n'y a à mon sens, que un INSERT INTO qui permette ceci.