Discussion :

[Delioneras]

Bonjour à tous et à toutes,

Dans une base SQL Server 2008 r2, je stocke l'ensemble des informations mes adhésions pour mon suivi client (table ADHESIONS).

Toutes les applications jusqu'à présents développées (je suis nouveau dans l'entreprise), interrogent et modifient les données de cette table ADHESIONS sans problème, et notamment les INSERT INTO SELECT sont utilisés à l'aide du joker *.

Mais depuis quelques temps, la structure de cette table ADHESIONS est modifiée par l'ajout d'une colonne GUID_CONTACT_ID, et dont les valeurs sont toujours à NULL.
Le problème étant que cette colonne supplémentaire a tendance à faire planter toutes les applications internes qui interrogent la table ADHESIONS.


Je sais qu'il n'y a rien dans les applications internes de l'entreprise qui génère cette colonne, et je soupçonne vaguement une application tierce de générer ce GUID_CONTACT_ID, mais impossible de savoir quand cela se produit.

Existe-t-il un moyen de tracer les commandes ALTER TABLE qui sont envoyées au serveur ?
Ou mieux, de les capturer pour les empêcher, du moins les modifications indésirables ?

J'ai commencé à regarder du côté des TRIGGER, mais je sais qu'ils sont plus utilisés pour veiller sur les données plutôt que sur la structure même de la table.

Y a-t-il des outils d'administration qui puissent me permettre de monitorer ces ALTER TABLE ?

Merci d'avance,
Cordialement,
Delio

[aieeeuuuuu]

Bonjour

notamment les INSERT INTO SELECT sont utilisés à l'aide du joker *.

ça c'est une mauvaise pratique, mais je crois que vous veniez de vous en rendre compte

et je soupçonne vaguement une application tierce de générer ce GUID_CONTACT_ID, mais impossible de savoir quand cela se produit

Qu'entendez-vous par application tierce ?
des applications que vous ne maitrisez pas accèdent à votre BDD, avec des privilèges suffisants pour modifier la structure de votre base ?

J'ai commencé à regarder du côté des TRIGGER, mais je sais qu'ils sont plus utilisés pour veiller sur les données plutôt que sur la structure même de la table.

Vous pouvez en effet mettre des triggers DDL qui vont capturer les commandes ALTER TABLE sur cette table.

Plus simplement, vous pouvez aussi utiliser le profiler pour surveiller les évènements Object:Altered.

[Boubou2020]

Bonjour

Vu que vous été avec la version SQL2008 et on espérant que vous été avec la version Entreprise tu peut profiter la fonctionnalité d'audit
Il faut choisir l'option DATABASE_OBJECT_CHANGE_GROUP

[Delioneras]

Merci à vous deux pour vos réponses.

ça c'est une mauvaise pratique, mais je crois que vous veniez de vous en rendre compte

Oh, ça fait plus de 10 ans que je m'en rends compte, je suis particulièrement convaincu sur le sujet.
J'ai juste deux petits défauts qui n'aident pas mon argumentation, à rajouter à un contexte d'entreprise:
- Le contexte: il y a déjà un existant établi, en production depuis un moment
- Les défauts: je suis le "petit dernier technicien" de l'entreprise, et je suis toujours en période d'essai.

J'ai arrêté d'essayer d'expliquer le pourquoi il faut les intégrités référentielles, pourquoi les select * sont à bannir, ça me déprime, mais personne ne m'écoute. Alors je fais avec, et j'essaye de faire de mon mieux.

Qu'entendez-vous par application tierce ?
des applications que vous ne maitrisez pas accèdent à votre BDD, avec des privilèges suffisants pour modifier la structure de votre base ?

Pour la petite histoire, je travaille dans une startup de Call Center. L'outils d'appel est en effet une application tierce, même si au coeur de notre activité.
Et pour rire jaune, l'application en question se connecte en sa. Comme toutes les autres applications qui se connectent sur la base.
Donc question droits ... Comment dire ... Dieu le père qui parle en gros.

Vous pouvez en effet mettre des triggers DDL qui vont capturer les commandes ALTER TABLE sur cette table.

Plus simplement, vous pouvez aussi utiliser le profiler pour surveiller les évènements Object:Altered.

J'ai commencé à regarder sur ce sujet, j'ai trouvé des débuts de piste sur les triggers DDL un peu après avoir posté sur le forum. Mais j'avoue ne pas encore trop comprendre comment manipuler le EventData.

Je vais regarder du côté du profiler et du DATABASE_OBJECT_CHANGE_GROUP, merci, ça me donne de quoi creuser.

[aieeeuuuuu]

J'ai commencé à regarder sur ce sujet, j'ai trouvé des débuts de piste sur les triggers DDL un peu après avoir posté sur le forum. Mais j'avoue ne pas encore trop comprendre comment manipuler le EventData.

Tout dépend de ce que vous voulez faire (le but est-il simplement pour le moment d'identifier qui ajoute cette colonne ? )

pour mieux comprendre EvenData, vous pouvez (sur un serveur de dev dans un premier temps)
1/ créer une table pour recevoir les évènements :

Code :

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

CREATE TABLE DDLLog(DateHeure DATETIME2(3), Donnee XML);

2/ ajouter un trigger qui ajoute l'intégralité de ce que renvoi EVENTDATA() :

Code :

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

1
2
3
4
5
6
CREATE TRIGGER TRG_LOG_ALTER_TABLE
ON DATABASE
FOR ALTER_TABLE
AS
	INSERT INTO DDLLog(DateHeure, Donnee) VALUES(CURRENT_TIMESTAMP, EVENTDATA())
;

Vous pourrez alors récupérer l'ensemble de son contenu et le manipuler en dehors du contexte trigger où c'est un peu plus compliqué.

Mais par la suite, vous pourrez par exemple empêcher spécifiquement l'ajout de cette colonne dans cette table, en exploitant le contenu de EVENTDATA et en faisant un rollback dans le trigger.