T-SQL يتسبب في إطلاق "اسم العمود أو رقم الموردة القيم لا يطابق تعريف الجدول" خطأ

Question

هنا شيء لم أكن قادرة على إصلاح و بحثت في كل مكان.ربما شخص ما هنا سوف تعرف!

لدي جدول يسمى dandb_raw مع ثلاثة أعمدة على وجه الخصوص:dunsId (PK), اسم, و searchName.أود أيضا أن يكون الزناد الذي يعمل في هذا الجدول:

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

الزناد أسباب إدراج الفشل:

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.

معظم الشيء الغريب في هذا هو أن كل من البيانات الفردية في المشغل يعمل من تلقاء نفسها.انها تقريبا كما لو إدراج واحدة قبالة الجدول الذي يصيب الجداول المؤقتة إذا حاولت نقل تضاف إلى واحد منهم.

إذن ما هي أسباب تؤدي إلى الفشل ؟ كيف يمكن إيقافها ؟

Answer 1

أعتقد أن ديفيد و سيرفو مجتمعة قد ضرب على مشكلة هنا.

أنا متأكد جزء من ما كان يحدث هو أننا كنا نستخدم #newMatches في العديد من المشغلات.عندما واحدة تؤدي إلى تغير بعض الصفوف ، فإنه حريق آخر الزناد ، والتي من شأنها أن محاولة استخدام اتصال راقب #newMatches.

ونتيجة لذلك ، فإنه محاولة العثور على الجدول موجودة بالفعل مع مختلف مخطط, يموت, و تنتج الرسالة أعلاه.قطعة واحدة من الأدلة التي من شأنها أن تكون في صالح:هل إدخال استخدام كومة نمط نطاق (متداخلة المشغلات الخاصة بهم inserteds?)

لا تزال المضاربة ولو - على الأقل الأشياء يبدو أن العمل الآن!

Answer 2

ما هو companies_contactInfo_updateTerritories?الفعلية إشارة يذكر الإجراء "companies_contactInfo_updateTerritories" لكن أنا لا أرى ذلك في رمز معين.أيضا أنا لا أرى أين هو استدعائه.إلا إذا كان من التطبيق الخاص بك أن تدعو SQL وبالتالي لا صلة لها بالموضوع....

إذا كنت اختبار كل شيء وعملت ولكن الآن لا يعمل ، ثم شيء يجب أن تكون مختلفة.شيء واحد للنظر هو الأمن.لاحظت أن تتصل الجدول [dandb_raw] و لا [dbo].[dandb_raw].حتى إذا كان المستخدم جدول بنفس الاسم [المستخدم].[dandb_raw] هذا الجدول سوف تستخدم للتحقق من التعاريف بدلا من الجدول الخاص بك.أيضا ، على الزناد يخلق temp الجداول.ولكن إذا كان بعض temp الجداول موجودة بالفعل لأي سبب كان ولكن مع تعريفات مختلفة ، وهذا قد يكون أيضا مشكلة.

Answer 3

أنا لا أرى أي مشكلة واضحة في القانون.

"حدد ..في" ضعيف الكونغ فو.محاولة صراحة إيجاد temp تعريف الجدول:

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

عندما كنت فعلت مع #newMatches ، يجب التخلص منه حتى تتمكن من خلق ذلك مرة أخرى في وقت لاحق (temp الجداول اتصال راقب!!)

DROP TABLE #newMatches

Answer 4

يؤدي رمز (لأنه يجب أن يعمل في كل مرة يتم تحديث البيانات) يجب أن تكون فعالة ، يجب أن تراعي عدة سجل إدراج.لقد نجحت في الثاني وليس الأول.كنت قد قدمت هذا معقد و قد استخدمت أشياء مثل لا في البيانات التي عادة ما تكون أقل efficeint من استخدام اليسار الانضمام.درجة الحرارة الجداول لا لزوم لها هنا (أنا لن تنظر في استخدام واحدة في النار) كما أنها إضافة إلى عدم كفاءة الزناد.ليس هناك سبب عدم الكتابة من إدراج أنا بدلا من من (حدد dunsId, اسم من #السحر) أنا

أول من المرجح أن تكون أسرع و أبسط إلى قراءة وصيانة.

هنا:الانضمام إلى ( حدد الحالة عندما charindex('/',url) <> 0 ثم اليسار(url ، charindex('/',url)-1) آخر url نهاية urlMatch, * من الشركات ) ج على dandb.url = c.urlMatch

يمكنك اختيار جميع الحقول في الجدول حتى ولو كنت تظهر فقط إلى استخدام واحد.لماذا ؟ يمكنك أيضا تشغيل هذه الحالة stament على جميع سجلات الشركة حتى ولو بعد انضمام قد لا تحتاج كل منهم.

أيضا في العام وأود أن تجنب استخدام select * ولكن خصوصا في الزناد.لنفترض أنك إدراج في جدول آخر كنت تستخدم حدد * من الجدول انضم إلى إدراجها أو حذفها.إضافة عمود إلى الجدول تسبب تؤدي إلى فشل ووقف جميع البيانات التغييرات حتى كانت ثابتة.

كنت قد أيضا استخدام وظيفة في الزناد.هذا coudl يكون بطيئا للغاية إذا كان لديك كبيرة إدراج.أقترح يمكنك اختبار هذا عن طريق تحديث مجموعة كبيرة من الوثائق ونرى ما سيحدث.جميع البيانات التغييرات لا تحدث فقط من واجهة المستخدم ، سجل واحد في كل مرة.وسوف يكون هناك أوقات عندما يتم تحديث الحقل من مخصص الاستعلام في إدارة studio (عند جميع الأسعار تحتاج إلى تعديل بنسبة 10% مع أبسط مثال يتبادر إلى الذهن.) المشغل الخاص بك يحتاج إلى أن تكون قادرة على التعامل مع تلك الأنواع إذا كانت التحديثات وكذلك تلك التي كنت تتوقع.أود أن تشغيل اختبار حالة تحديث 100000 الصفوف وانظر كم الزناد يبطئ الأمور.

ربما هذا ليس حقا الرد على مشكلتك, ولكن على الزناد فقط حتى الآن من الأمثل ، كان لي أن أقول ذلك.