Comment déterminer dans un déclencheur et des insertions directes inserts via la procédure stockée

Question

TableX peut être modifiée de deux façons:

• client insère des "directs"
• client utilise la procédure stockée aux dossiers inserts

Comment la voie d'une durée déterminée de l'appel du client (proc direct ou enregistré) dans un déclencheur de TABLEx

Merci.

Answer 1

Utilisez SET CONTEXT_INFO dans la procédure stockée et lue dans la déclenchement avec CONTEXT_INFO ()

Avez le déclencheur remis à zéro sur la sortie.

Answer 2

Vous ne pouvez pas déterminer. Tout ce que vous avez à votre disposition est les tables inserted et deleted. Vous pourriez probablement tricher, mais il est un hack gawdawful, sanglante. Définir une vue avec une colonne « extra », ce qu'il est n'a pas d'importance. Tout votre insert / mise à jour proc Assigner une valeur à cette colonne, les mises à jour directes fournissent une (valeur ou inexistante) différente. Créer un lieu de déclencheur sur ce point de vue et faire votre logique de mise à jour sur le drapeau source

CREATE VIEW dbo.vwTableX
AS
SELECT
    X.*
,   'T' AS fake_source_column
FROM
    dbo.tableX X

GO
CREATE TRIGGER insertHack ON dbo.vwTableX
INSTEAD OF INSERT
AS
BEGIN

    SET NOCOUNT ON

    IF EXISTS (SELECT * FROM INSERTED I WHERE I.fake_source_column = 'P')
    BEGIN
        -- perform logic for PROC sourced data
        INSERT INTO
            dbo.tableX
        SELECT
            I.col1
        ,   I.col2
        -- everything but our fake column
        FROM
            INSERTED I
        WHERE
            I.fake_source_column = 'P'
    END

    IF EXISTS (SELECT * FROM INSERTED I WHERE I.fake_source_column = 'D' OR I.fake_source_columns IS NULL)
    BEGIN
        -- perform logic for direct access data
        INSERT INTO
            dbo.tableX
        SELECT
            I.col1 * 2 -- or whatever special logic you wish to apply
        ,   I.col2
        -- everything but our fake column 
        FROM
            INSERTED I
        WHERE
            I.fake_source_column = 'D' OR I.fake_source_columns IS NULL
    END
END
GO

-- lather, rinse, repeat for update and/or delete trigger

Alors, voilà une solution, mais vraiment, quel est le problème que vous essayez de résoudre? Pourquoi vous soucier si le DML vient de proc ou non proc?

Answer 3

Je vous suggère de commencer une session de suivi sur les déclarations qui touchent (faire insérer des actions) TableX et voir quelques informations spécifiques comme le nom d'hôte, loginame, nom_du_programme.

Très probablement les inserts manuels seront effectués à partir de Management Studio en utilisant son poste et son nom d'utilisateur, tandis que les inserts de procédures stockées seront effectuées à partir d'une application spécifique, au moyen d'un utilisateur de l'application et que le nom du programme. Si vous voyez un certain motif constant qui vous aideront à découvrir les différences entre les actions, que vous serez en mesure d'utiliser l'exemple de requête suivante pour enregistrer les données dans une table d'enregistrement:

select sp.hostname, sp.program_name, sp.loginame
from sysprocesses sp
where spid = @@spid

Cette solution (ou le précédent proposé par billinkc) que si vous ne pouvez pas modifier les procédures stockées. Si vous pouvez le faire, que cela devrait être d'ajouter facilement la partie de l'enregistrement.