2008-09-18 9 views
5

यहां कुछ ऐसा है जो मैं ठीक करने में सक्षम नहीं हूं, और मैंने हर जगह देखा है। शायद यहां कोई व्यक्ति जानता होगा!टी-एसक्यूएल एक "कॉलम नाम या आपूर्ति किए गए मानों की संख्या को फायरिंग से मेल नहीं खाता है" त्रुटि

मेरे पास dandb_raw नामक एक सारणी है, जिसमें विशेष रूप से तीन कॉलम हैं: dunsId (PK), name, और searchName।

insert into [dandb_raw](dunsId, name) 
    select 3442355, 'harper' 
    union all 
    select 34425355, 'har 466per' 
update [dandb_raw] set name ='grap6767e' 

इस त्रुटि के साथ:

Msg 213, Level 16, State 1, Procedure companies_contactInfo_updateTerritories, Line 20 
Insert Error: Column name or number of supplied values does not match table definition. 

इस बारे में सबसे उत्सुक बात है

SET ANSI_NULLS ON 
GO 
SET QUOTED_IDENTIFIER ON 
GO 

ALTER TRIGGER [dandb_raw_searchNames] 
    ON [dandb_raw] 
    FOR INSERT, UPDATE 
    AS 

SET NOCOUNT ON 

    select dunsId, name into #magic from inserted 

     UPDATE dandb 
      SET dandb.searchName = company_generateSearchName(dandb.name) 
      FROM (select dunsId, name from #magic) i 
      INNER JOIN dandb_raw dandb 
       on i.dunsId = dandb.dunsId 


     --Add new search matches 
     SELECT c.companyId, dandb.dunsId 
      INTO #newMatches 
      FROM dandb_raw dandb 
      INNER JOIN (select dunsId, name from #magic) a 
       on a.dunsId = dandb.dunsId 
      INNER JOIN companies c 
       ON dandb.searchName = c.searchBrand 
       --avoid url matches that are potentially wrong 
       AND (lower(dandb.url) = lower(c.url) 
        OR dandb.url = '' 
        OR c.url = '' 
        OR c.url is null) 


     INSERT INTO #newMatches (companyId, dunsId) 
     SELECT c.companyId, max(dandb.dunsId) dunsId 
      FROM dandb_raw dandb 
      INNER JOIN 
       (
        select 
        case when charindex('/',url) <> 0 then left(url, charindex('/',url)-1) 
        else url 
        end urlMatch, * from companies 
       ) c 
       ON dandb.url = c.urlMatch 
      where subsidiaryOf = 1 and isReported = 1 and dandb.url <> '' 
       and c.companyId not in (select companyId from #newMatches) 
      group by companyId 
      having count(dandb.dunsId) = 1 

     UPDATE cd 
      SET cd.dunsId = nm.dunsId 
      FROM companies_dandb cd 
      INNER JOIN #newMatches nm 
       ON cd.companyId = nm.companyId 
GO 

ट्रिगर आवेषण विफल कारण बनता है: मैं भी एक ट्रिगर है कि इस मेज पर कार्य करता है है कि ट्रिगर में व्यक्तिगत विवरणों में से प्रत्येक अपने आप पर काम करता है। यह लगभग उतना ही है जैसा कि डाला गया एक-ऑफ टेबल है जो अस्थायी तालिकाओं को संक्रमित करता है यदि आप उनमें से किसी एक में डालने की कोशिश करते हैं।

तो ट्रिगर विफल होने का क्या कारण बनता है? इसे कैसे रोका जा सकता है?

उत्तर

2

मुझे लगता है कि डेविड और सेर्वो संयुक्त ने यहां समस्या पर मारा है।

मुझे यह पता चल रहा है कि क्या हो रहा था यह था कि हम एकाधिक ट्रिगर्स में #newMatches का उपयोग कर रहे थे। जब एक ट्रिगर ने कुछ पंक्तियों को बदल दिया, तो यह एक और ट्रिगर आग लगाएगा, जो #newMatchches कनेक्शन कनेक्शन का उपयोग करने का प्रयास करेगा।

नतीजतन, यह एक अलग स्कीमा के साथ पहले से मौजूद तालिका को ढूंढने, मरने और ऊपर दिए गए संदेश का उत्पादन करने का प्रयास करेगा। साक्ष्य का एक टुकड़ा जो पक्ष में होगा: क्या स्टैक स्टाइल स्कोप का उपयोग किया जाता है (नेस्टेड ट्रिगर्स के पास अपनी खुद की प्रविष्टियां होती हैं?)

फिर भी अटकलें - कम से कम चीजें अब काम कर रही हैं!

+0

नेस्टेड ट्रिगर्स में प्रत्येक की अपनी डाली गई जादू तालिका होती है। –

1

कंपनियां_contactInfo_updateTerritories क्या हैं? वास्तविक संदर्भ प्रक्रिया "Companies_contactInfo_updateTerritories" का उल्लेख करता है लेकिन मुझे इसे दिए गए कोड में नहीं दिखाई देता है। इसके अलावा मुझे नहीं पता कि इसे कहां कहा जा रहा है। जब तक यह आपके एप्लिकेशन से नहीं है जो SQL को कॉल कर रहा है और इसलिए अप्रासंगिक है ....

यदि आपने सब कुछ परीक्षण किया है और यह काम करता है लेकिन अब यह काम नहीं करता है, तो कुछ अलग होना चाहिए। विचार करने की एक बात सुरक्षा है। मैंने देखा कि आप केवल टेबल [dandb_raw] को कॉल करें और नहीं [dbo]। [Dandb_raw]। तो यदि उपयोगकर्ता के पास एक ही नाम [उपयोगकर्ता] की एक तालिका थी। [Dandb_raw], उस तालिका का उपयोग आपकी तालिका के बजाय परिभाषाओं की जांच के लिए किया जाएगा। इसके अलावा, ट्रिगर temp टेबल बनाता है। लेकिन अगर कुछ अस्थायी सारणी पहले से ही किसी भी कारण से मौजूद हैं लेकिन विभिन्न परिभाषाओं के साथ, यह भी एक समस्या हो सकती है।

+0

यह बहुत उपयोगी था ... मैंने ट्रिगर कंपनियों_contactInfo_updateTerritories को याद किया था। मैं इसमें और अधिक देखने जा रहा हूं और देख सकता हूं कि मैं समस्या को दूर कर सकता हूं या नहीं। – Chris

1

मुझे कोड में कोई स्पष्ट समस्या नहीं दिखाई देती है।

"चयन करें .. INTO" कमजोर कुंग-फू है।

CREATE TABLE #newMatches 
(
    CompanyID int PRIMARY KEY, 
    DunsID int 
) 

आप #newMatches पूरे कर चुके हैं, तो आप यह से छुटकारा पाने, तो आप इसे बाद में फिर से बना सकते हैं चाहिए (अस्थायी तालिकाओं कनेक्शन scoped हैं !!)

DROP TABLE #newMatches 
: स्पष्ट रूप से अस्थायी तालिका परिभाषा बनाने का प्रयास करें
+0

वैरिएबल टेबल का उपयोग करने पर भी विचार करें, क्योंकि वे चर के रूप में स्कॉप्ड हैं। डेक्लेयर @ न्यूमैच टेबल (कंपनीआईडी ​​इंट प्राइमरी कुंजी, ड्यून्सआईडी इंट) –

0

ट्रिगर कोड (क्योंकि यह डेटा अपडेट होने पर हर बार चलाना चाहिए) कुशल होना चाहिए और एकाधिक रिकॉर्ड प्रविष्टियों के लिए खाता होना चाहिए। आप दूसरे पर सफल रहे हैं लेकिन पहले नहीं।आपने इसे अत्यधिक जटिल बना दिया है और ऐसी चीजों का उपयोग किया है जैसे बयान में शामिल नहीं है जो आमतौर पर बाएं जुड़ने के उपयोग से कम प्रभावशाली होते हैं। टेम्प्लेट टेबल अनावश्यक हैं (मैं ट्रिगर में किसी का उपयोग करने पर कभी विचार नहीं करता) क्योंकि वे ट्रिगर की अक्षमता में जोड़ते हैं। वहां से डाला मैं बजाय से (dunsId, #magic से नाम चुनें) लिखने के लिए नहीं कारण नहीं है मैं

पहले तेजी से होने की संभावना है और पढ़ सकते हैं और बनाए रखने के लिए आसान है।

यहाँ: (मामले का चयन जब CHARINDEX ('/', यूआरएल) <> 0 तो (यूआरएल, CHARINDEX ('/', यूआरएल) -1) किसी और यूआरएल अंत urlMatch, कंपनियों से * बाएं) में शामिल होने C पर dandb.url = c.urlMatch

आप तालिका में सभी फ़ील्ड का चयन कर रहे हैं भले ही आप केवल एक का उपयोग कर रहे हों। क्यूं कर? आप कंपनी में सभी रिकॉर्ड्स पर उस केस स्टैम को भी चला रहे हैं, भले ही आपसे जुड़ने के बाद भी उन सभी की आवश्यकता न हो।

सामान्य रूप से मैं चुनिंदा * लेकिन विशेष रूप से एक ट्रिगर में उपयोग करने से बचूंगा। मान लीजिए कि आप किसी अन्य तालिका में डालने लगे हैं और आपने कुछ तालिका से चयन * हटाए गए या हटाए गए हैं। उस तालिका में एक कॉलम जोड़ने से ट्रिगर विफल हो जाएगा और जब तक यह तय नहीं हो जाता तब तक सभी डेटा परिवर्तनों को रोक दें।

आपने ट्रिगर में एक फ़ंक्शन भी उपयोग किया है। यदि आपके पास बड़ी डालने है तो यह कउड दर्द से धीमा हो जाएगा। मेरा सुझाव है कि आप रिकॉर्ड के बड़े समूह को अपडेट करके इसका परीक्षण करें और देखें कि क्या होता है। सभी डेटा परिवर्तन केवल उपयोगकर्ता इंटरफ़ेस से नहीं होते हैं, एक समय में एक रिकॉर्ड। ऐसे समय होंगे जब प्रबंधन स्टूडियो में विज्ञापन-प्रसार क्वेरी से एक फ़ील्ड अपडेट किया जाता है (जब सभी कीमतों को दिमाग में आने वाले सबसे सरल उदाहरण के रूप में 10% द्वारा समायोजित करने की आवश्यकता होती है।) आपके ट्रिगर को उन प्रकारों को संभालने में सक्षम होना चाहिए यदि अपडेट्स के साथ-साथ आप जिनकी अपेक्षा कर रहे हैं। मैं 100000 पंक्तियों को अपडेट करने वाला एक टेस्ट केस चलाऊंगा और देख सकता हूं कि यह ट्रिगर चीजों को धीमा कर देता है।

शायद यह वास्तव में आपकी समस्या का जवाब नहीं दे रहा है, लेकिन ट्रिगर इष्टतम से अभी तक बहुत दूर है, मुझे यह कहना था।

+0

वास्तव में अस्थायी सारणी चली गई हैं। मुझे नहीं पता कि अतिरिक्त कॉलम क्या थे, इसलिए वे भी चले गए हैं। हमें अंततः प्रत्येक पंक्ति पर फ़ंक्शन चलाने की ज़रूरत है। हमें वास्तव में प्रदर्शन का एक अच्छा मीट्रिक मिला क्योंकि हम थोक लोडिंग करते हैं। थोक के लिए प्रक्रिया का उपयोग करते समय मैं ट्रिगर को अक्षम कर सकता हूं ... – Chris

+0

बल्क लोड बराबर ट्रिगर से तेज होने के बाद अद्यतन कर रहा है? – Chris

संबंधित मुद्दे