कैसे एक बाहरी (SQLCLR) SQL सर्वर ट्रिगर

Question

मैं एक उत्प्रेरक है कि इस तरह एक विधानसभा कॉल बनाया है तर्क पारित करने के लिए:

CREATE TRIGGER Testrigger ON STATION 
FOR INSERT 
AS EXTERNAL NAME assemblytest.[WriteTimeInfile.Program].Testrigger 

कि विधानसभा में नेट कोड है कि कुछ इस तरह है:

namespace WriteTimeInfile 
{ 
    public class Program 
    { 
     [SqlTrigger(Name = @"Testrigger", Target = "[dbo].[STATION]", Event = "FOR INSERT, UPDATE, DELETE")] 
     public static void Testrigger() 
     { 
      File.AppendAllText(@"C:\Users\Vivien\date.txt", 
      DateTime.Now.ToString() + Environment.NewLine); 
     } 
    } 
} 

मैं एक तर्क, बनाया पंक्ति या इस तरह अद्यतन पंक्ति कुछ के रूप में, पारित करने में सक्षम होना चाहते हैं:

CREATE TRIGGER Testrigger ON STATION 
AFTER INSERT 
AS 
EXTERNAL NAME assemblytest.[WriteTimeInfile.Program].Testrigger (STATION.ID) 

मुझे स्टैक ओवरफ्लो पर 7 साल पुराना topic मिला जो बताता है कि सीएलआर असेंबली को तर्क देने का कोई तरीका नहीं है।
मैं पूछ रहा हूं कि यह हाल ही में SQL सर्वर संस्करणों में संभव है या नहीं।

क्या आपको पता है कि कोई रास्ता है और यदि हां, तो कृपया इसे कैसे करें?

Answer 1

नहीं, आप सीधे एसक्यूएलसीएलआर ट्रिगर्स को तर्क नहीं दे सकते हैं। हालांकि, आप मूल्यों परोक्ष रूप से कुछ तरीकों से (एक ही नियमित T-SQL ट्रिगर के साथ के रूप में) पारित कर सकते हैं:

1. स्थानीय अस्थायी तालिका
2. SET CONTEXT_INFO/CONTEXT_INFO
3. एसक्यूएल सर्वर 2016 या नए पर: sp_set_session_context/SESSION_CONTEXT

सभी मामलों में आप एक निर्गम SqlParameter के साथ एक SqlCommand क्रियान्वित नेट कोड में मूल्य को खींचने के लिए से मूल्यों को प्राप्त होगा। (कृपया उपयोग के अंत में नोट देखें)।

लेकिन अगर आप inserted और/या deleted तालिकाओं के मान चाहते हैं, तो वे तर्क या पैरामीटर नहीं होंगे। कनेक्शन स्ट्रिंग के लिए Context Connection = true का उपयोग करके SqlCommand का उपयोग करके SELECT और SqlDataReader का उपयोग कर रहे हैं। Sample CLR Trigger अनुभाग में, आप CLR Triggers के लिए एमएसडीएन पृष्ठ में इसका एक उदाहरण देख सकते हैं।

---

कि DML ऑपरेशन का हिस्सा नहीं हैं ट्रिगर करने के लिए गुजर मूल्यों के बारे में ध्यान दें:

हालांकि यह नहीं है बहुत का एक टुकड़ा पारित करने के लिए, वहाँ निश्चित रूप से कर रहे हैं वैध उपयोग के मामलों करने के लिए आम मुख्य संदर्भ से जानकारी घटनाओं की श्रृंखला में एक या अधिक ट्रिगर्स तक। मेरे द्वारा सामने आने वाले दो सबसे आम मामले हैं: 1) एप-आधारित लॉगिन या उपयोगकर्ता आईडी (एसक्यूएल सर्वर का हिस्सा नहीं) में गुजरने वाले पंक्तियों के लिए एक ऑडिट ट्रिगर में गुज़रना (क्योंकि उस जानकारी को DELETE में संशोधित बाई कॉलम में जोड़ा नहीं जा सकता है ऑपरेशन), और 2) अस्थायी रूप से एक शर्त के आधार पर एक ट्रिगर अक्षम करना। और हाँ, यह संभव है और यह काम करता है। डीबीए पर मेरा निम्नलिखित जवाब देखें।StackExchange:

• how to update column on same row with trigger without recursion?
• Disabled or enabled trigger from another trigger

Answer 2

डाला जाता है और हटा छद्म तालिकाओं के रूप में दस्तावेज की this 9+ years old version में दिखाया गया है, एक SQLCLR ट्रिगर अंदर प्रत्यक्ष क्वेरी किए जाने के लिए उपलब्ध हमेशा थे। आप हमेशा उनसे पूछ सकते हैं, उदाहरण के लिए:

using (SqlConnection conn = new SqlConnection("context connection=true")) 
{ 
    conn.Open(); 
    SqlCommand sqlComm = new SqlCommand(); 
    SqlPipe sqlP = SqlContext.Pipe; 

    sqlComm.Connection = conn; 
    sqlComm.CommandText = "SELECT UserName from INSERTED"; 

    userName.Value = sqlComm.ExecuteScalar().ToString(); 

    if (IsEMailAddress(userName.Value.ToString())) 
    { 
     sqlComm.Parameters.Add(userName); 
     sqlComm.CommandText = "INSERT UsersAudit(UserName) VALUES(@username)"; 
     sqlP.Send(sqlComm.CommandText); 
     sqlP.ExecuteAndSend(sqlComm); 
    } 
} 

नवीनतम नमूने समान हैं।

आपको उन्हें पैरामीटर के रूप में पास करने की आवश्यकता नहीं है, जैसे कि आपको सामान्य ट्रिगर्स के पैरामीटर के रूप में पास करने की आवश्यकता नहीं है। पूछताछ के लिए टेबल हमेशा उपलब्ध हैं।

मुझे संदेह है कि इन तालिकाओं को संदर्भ वस्तु पर संग्रहीत नहीं किया गया है क्योंकि उन्हें SQL सर्वर के बफर (सीपीयू और मेमोरी को बर्बाद करने) से कॉपी करने की आवश्यकता होगी। एक अन्य कारण यह है कि एक संग्रह प्रभावी ढंग से पूछताछ नहीं की जा सकती है। आपको या तो LINQ (और भी सीपीयू का उपयोग करके) का उपयोग करना होगा या पूरी सामग्री (मेमोरी और सीपीयू कचरा) पर बस फिर से उपयोग करना होगा। मेमोरी कचरा बड़ी समस्या होगी, क्योंकि इस मेमोरी का उपयोग अधिक डेटा और इंडेक्स को बफर करने के लिए किया जा सकता है, इस प्रकार पहुंच को तेज़ी से बढ़ाया जा सकता है।

मुझे संदेह है कि आप जिस प्रश्न से जुड़े थे, वही सवाल पूछना चाहते थे, लेकिन ओपी ने माना कि छद्म-टेबल को पैरामीटर के रूप में पारित किया जाना था। तो उन्होंने वास्तविक मुद्दे के बजाय पैरामीटर के बारे में पूछा।