Discussion :

[CHoule]

Bonjour,

Est-ce qu'il y a possibilité d'avoir une table usager et lorsqu'un usager se connecte dans mon programme de passer l'information a SQL server pour par la suite créer des logs avec l'information de cette usager?

Merci d'avance

[aieeeuuuuu]

Bonjour,

Oui c'est bien sûr possible...
Quel est précisément votre problème/difficulté ?

[StringBuilder]

A priori un trigger de base sur la connexion devrait faire l'affaire, non ?

[hmira]

A priori un trigger de base sur la connexion devrait faire l'affaire, non ?

La réponse est Oui, si on se réfère aux connexions et sessions de points de l'instance SQL Server. Mais du point de vue métier (modèle), les "usagers" comme Mlle CHOule les a nommés, correspondent je crois (?) à des personnes physiques ou morales identifiées lors de l'authentification par l'application.

Par ailleurs le pooling de connexions et l'uniformisation des chaines de connexions notamment pour les applications Web, fait que les "usagers" du point vue métier (modèle) ne correspondent que rarement, pour ne pas dire jamais, aux connexions telles quelles sont définies au niveau de l'instance et/ou aux utilisateurs de la base de données.

A+

[StringBuilder]

Le titre parlant d'usager "système", j'en avait déduit que l'utilisateur était authentifié avec un compte "système" propre.

Sinon, c'est juste un niveau de l'authentification "logicielle" qu'il faut rajouter un petit insert qui va bien...

[CHoule]

La réponse est Oui, si on se réfère aux connexions et sessions de points de l'instance SQL Server. Mais du point de vue métier (modèle), les "usagers" comme Mlle CHOule les a nommés, correspondent je crois (?) à des personnes physiques ou morales identifiées lors de l'authentification par l'application.

Par ailleurs le pooling de connexions et l'uniformisation des chaines de connexions notamment pour les applications Web, fait que les "usagers" du point vue métier (modèle) ne correspondent que rarement, pour ne pas dire jamais, aux connexions telles quelles sont définies au niveau de l'instance et/ou aux utilisateurs de la base de données.

A+

Bonjour, c'est exact je parle de personnes physiques.
En fait, comme plusieurs personnes peuvent être connectés dans l'application (donc a la BD) en même temps je voudrais savoir si il est possible de connaître qu'elle usager (de ma table usager) a fait une modification ou un ajout et ce sans nécessairement ajouter un champ ID_Usager dans la table. Est-ce que je devrais avoir un champ dans ma table usager pour faire référence a un usager BD?

[StringBuilder]

Pour citer SQLpro :

Les champs sont à la campagne et les colonnes dans l'étable les tables.

Donc, deux solutions :
- une colonne "modified_by" dans votre table, contenant l'id de la dernière personne qui a fait un update
- une table "modification" contenant les colonnes user_id, modification_date, table_name, column_name, old_value, new_value

Dans les deux cas, si possible alimentées par trigger.

La table "modification", bien qu'elle puisse rapidement devenir mammouth, est plus souple à utiliser et permet de mieux tracer les actions des utilisateurs, mais aussi de revenir en arrière.

Si elle est alimentée par ta couche dataaccess, tu peux éventuellement sérialiser en XML les colonnes "column_name" et "old/new_value", ce qui évitera de dupliquer les lignes lorsqu'on modifie plusieurs lignes, mais aussi rajouter d'autres informations propres aux contexte applicatif.

[CHoule]

je voudrais savoir si il est possible de connaître qu'elle usager (de ma table usager) a fait une modification ou un ajout et ce sans nécessairement ajouter une colonne ID_Usager dans la table modifiée

Donc la réponse a ma première question est "Non".

[SQLpro]

Donc la réponse a ma première question est "Non".

La réponse est OUI si vous utilisez l'outil approprié qui est "DATABASE AUDIT".
=> CREATE SERVER AUDIT
=> CREATE DATABASE AUDIT SPECIFICATION

A +