Nie udało się włączyć ograniczeń. Co najmniej jeden wiersz zawiera wartości naruszające ograniczenia inne niż null, unikatowe lub związane z kluczem obcym

Wykonuję sprzężenie zewnętrzne i pomyślnie wykonuję je w informixbazie danych, ale w moim kodzie pojawia się następujący wyjątek:

DataTable dt = TeachingLoadDAL.GetCoursesWithEvalState(i, bat);

Nie udało się włączyć ograniczeń. Co najmniej jeden wiersz zawiera wartości naruszające ograniczenia inne niż null, unikatowe lub związane z kluczem obcym.

Znam problem, ale nie wiem, jak go naprawić.

Druga tabela, w której wykonuję sprzężenie zewnętrzne, zawiera złożony klucz podstawowy, który ma wartość zerową w poprzednim zapytaniu sprzężenia zewnętrznego.

EDYTOWAĆ:

    SELECT UNIQUE a.crs_e,  a.crs_e  || '/ ' || a.crst crs_name, b.period,
           b.crscls, c.crsday, c.from_lect, c.to_lect,
           c.to_lect - c.from_lect + 1 Subtraction, c.lect_kind, e.eval, e.batch_no,
           e.crsnum, e.lect_code, e.prof_course
    FROM rlm1course a, rfc14crsgrp b, ckj1table c, mnltablelectev d,
         OUTER(cc1assiscrseval e)  
    WHERE a.crsnum = b.crsnum 
    AND b.crsnum = c.crsnum 
    AND b.crscls = c.crscls 
    AND b.batch_no = c.batch_no 
    AND c.serial_key = d.serial_key  
    AND c.crsnum = e.crsnum  
    AND c.batch_no = e.batch_no  
    AND d.lect_code= e.lect_code 
    AND d.lect_code = .... 
    AND b.batch_no = ....

Problem dotyczy stołu cc1assiscrseval. Klucz podstawowy to (batch_no, crsnum, lect_code).

Jak rozwiązać ten problem?

EDYTOWAĆ:

Zgodnie z @PaulStockradą: robię, co powiedział, i otrzymuję:

? dt.GetErrors () [0] {System.Data.DataRow} HasErrors: true ItemArray: {object [10]} RowError: "Kolumna 'eval' nie zezwala na DBNull.Value."

Więc rozwiązuję swój problem, zamieniając e.evalna,., A NVL (e.eval,'') evalto rozwiązuje mój problem. Wielkie dzięki.

Ten problem jest zwykle spowodowany jedną z następujących przyczyn

• zwracane wartości null dla kolumn nie ustawionych na AllowDBNull
• zduplikowane wiersze są zwracane z tym samym kluczem podstawowym.
• niezgodność definicji kolumn (np. rozmiar pól char) między bazą danych a zbiorem danych

Spróbuj uruchomić zapytanie natywnie i spójrz na wyniki, jeśli zestaw wyników nie jest zbyt duży. Jeśli wyeliminowałeś wartości null, przypuszczam, że kolumny klucza podstawowego są duplikowane.

Lub, aby zobaczyć dokładny błąd, możesz ręcznie dodać blok Try / Catch do wygenerowanego kodu w ten sposób, a następnie przerwać, gdy zostanie zgłoszony wyjątek:

Następnie w oknie poleceń wywołaj GetErrorsmetodę w tabeli, aby uzyskać błąd.
Dla języka C # polecenie byłoby ? dataTable.GetErrors()
dla VB, polecenie to? dataTable.GetErrors

Spowoduje to wyświetlenie wszystkich wierszy danych, które zawierają błąd. Możesz wtedy przyjrzeć się RowErrorkażdemu z nich, co powinno wskazać kolumnę, która jest nieprawidłowa, wraz z problemem. Tak więc, aby zobaczyć błąd pierwszego wiersza danych w błędzie, polecenie brzmi:
? dataTable.GetErrors(0).RowError
lub w C # byłoby? dataTable.GetErrors()[0].RowError

Możesz wyłączyć ograniczenia w zbiorze danych. Pozwoli ci to zidentyfikować złe dane i pomóc rozwiązać problem.

na przykład

dataset.TableA.Clear();
dataset.EnforceConstraints = false;
dataAdapter1.daTableA.Fill(dataset, TableA");

Metoda wypełniania może być nieco inna dla Ciebie.

Spowoduje to znalezienie wszystkich wierszy w tabeli, które zawierają błędy, wydrukowanie klucza podstawowego wiersza i błędu, który wystąpił w tym wierszu ...

To jest w C #, ale konwersja do VB nie powinna być trudna.

 foreach (DataRow dr in dataTable)
 {
   if (dr.HasErrors)
     {
        Debug.Write("Row ");
        foreach (DataColumn dc in dataTable.PKColumns)
          Debug.Write(dc.ColumnName + ": '" + dr.ItemArray[dc.Ordinal] + "', ");
        Debug.WriteLine(" has error: " + dr.RowError);
     }
  }

Ups - przepraszam, PKColumns to coś, co dodałem, kiedy rozszerzyłem DataTable, który informuje mnie o wszystkich kolumnach, które tworzą klucz podstawowy DataTable. Jeśli znasz kolumny klucza podstawowego w pliku danych, możesz je przeglądać w pętli tutaj. W moim przypadku, ponieważ wszystkie moje dane znają swoje kolumny PK, mogę automatycznie napisać debugowanie dla tych błędów dla wszystkich tabel.

Wynik wygląda następująco:

Row FIRST_NAME: 'HOMER', LAST_NAME: 'SIMPSON', MIDDLE_NAME: 'J',  has error: Column 'HAIR_COLOR' does not allow DBNull.Value.

Jeśli nie masz pewności co do powyższej sekcji PKColumns - powoduje to wydrukowanie nazw i wartości kolumn i nie jest to konieczne, ale dodaje przydatne informacje dotyczące rozwiązywania problemów w celu określenia, które wartości kolumn mogą powodować problem. Usunięcie tej sekcji i zachowanie reszty nadal spowoduje wydrukowanie generowanego błędu SQLite, który wskaże kolumnę, której dotyczy problem.

• Upewnij się, że pola wymienione w zapytaniu adaptera tabeli są zgodne z polami w zdefiniowanym zapytaniu. Wydaje się, że DAL nie lubi niedopasowań. Zwykle dzieje się to z Twoimi sprocami i zapytaniami po dodaniu nowego pola do tabeli.

• Jeśli zmieniłeś długość pola varchar w bazie danych, a XML zawarty w pliku XSS go nie pobrał, znajdź nazwę pola i definicję atrybutu w XML i zmień ręcznie.

• Usuń klucze podstawowe z list wyboru w adapterach tabel, jeśli nie są one związane z zwracanymi danymi.

• Uruchom zapytanie w SQL Management Studio i upewnij się, że nie są zwracane zduplikowane rekordy. Zduplikowane rekordy mogą generować zduplikowane klucze podstawowe, co spowoduje ten błąd.

• Związki SQL mogą oznaczać kłopoty. Zmodyfikowałem jeden adapter do stołu, dodając rekord „proszę wybrać pracownika” poprzedzający pozostałe. Dla pozostałych pól podałem fikcyjne dane, w tym na przykład łańcuchy o długości jeden. DAL wywnioskował schemat z tego rekordu początkowego. Zapisy z ciągami o długości 12 nie powiodły się.

To zadziałało dla mnie, źródło: tutaj

Miałem ten błąd i nie był on związany z ograniczeniami DB (przynajmniej w moim przypadku). Mam plik .xsd z zapytaniem GetRecord, które zwraca grupę rekordów. Jedną z kolumn tej tabeli było „nvarchar (512)” i w środku projektu musiałem zmienić ją na „nvarchar (MAX)”.

Wszystko działało poprawnie, dopóki użytkownik nie wprowadził w tym polu więcej niż 512 i zaczęliśmy otrzymywać słynny komunikat o błędzie „Nie udało się włączyć ograniczeń. Jeden lub więcej wierszy zawiera wartości naruszające ograniczenia inne niż null, unikatowe lub związane z kluczem obcym”.

Rozwiązanie: sprawdź wszystkie właściwości MaxLength kolumn w DataTable.

Kolumna, którą zmieniłem z „nvarchar (512)” na „nvarchar (MAX)” nadal miała wartość 512 we właściwości MaxLength, więc zmieniłem na „-1” i działa !!.

Problem dotyczy projektanta dostępu do danych. W programie Visual Studio, kiedy ściągamy Widok z „Eksploratora serwera” do okna Projektanta, jest to losowe dodawanie klucza podstawowego do kolumny lub oznaczanie czegoś jako NOT NULL, chociaż w rzeczywistości jest ustawiony na null. Chociaż faktyczne tworzenie widoku na serwerze bazy danych SQL nie ma zdefiniowanego żadnego klucza podstawowego ani zdefiniowanej wartości NOT NULL, projektant VS dodaje ten klucz / ograniczenie.

Możesz to zobaczyć w projektancie - jest to pokazane za pomocą ikony klucza po lewej stronie nazwy kolumny.

Rozwiązanie: Kliknij prawym przyciskiem myszy ikonę klucza i wybierz „Usuń klucz”. To powinno rozwiązać problem. Możesz także kliknąć prawym przyciskiem myszy kolumnę i wybrać „Właściwości”, aby wyświetlić listę właściwości kolumny w projektancie dostępu do danych VS i odpowiednio zmienić wartości.

Ten błąd pojawiał się również w moim projekcie. Wypróbowałem wszystkie zaproponowane tutaj rozwiązania, ale bez powodzenia, ponieważ problem nie miał nic wspólnego z rozmiarem pól, definicją pól kluczy tabeli, ograniczeniami lub zmienną zestawu danych EnforceConstraints.

W moim przypadku mam również obiekt .xsd, który umieściłem tam podczas projektowania projektu (warstwa dostępu do danych). Podczas przeciągania obiektów tabeli bazy danych do elementu wizualnego zestawu danych odczytuje on każdą definicję tabeli z bazowej bazy danych i kopiuje ograniczenia do obiektu zestawu danych dokładnie tak, jak zostały zdefiniowane podczas tworzenia tabel w bazie danych (SQL Server 2008 R2 w moim walizka). Oznacza to, że każda kolumna tabeli utworzona z ograniczeniem „nie null” lub „klucz obcy” musi być również obecna w wyniku instrukcji SQL lub procedury składowanej.

Po uwzględnieniu w zapytaniach wszystkich kolumn kluczowych i kolumn zdefiniowanych jako „niezerowe” problem całkowicie zniknął.

Mój zaczął działać, kiedy ustawiłem AllowDBNullna True w polu daty w tabeli danych w pliku xsd.

Wygląda na to, że wybrano jedną lub więcej kolumn za pomocą:

   e.eval, e.batch_no, e.crsnum, e.lect_code, e.prof_course

ma AllowDBNull ustawioną na False w definicji zestawu danych.

Nie jest jasne, dlaczego wykonanie instrukcji SELECT powinno obejmować włączanie ograniczeń. Nie znam języka C # ani technologii pokrewnych, ale znam bazę danych Informix. Coś dziwnego dzieje się z systemem, jeśli kod zapytania włącza (i przypuszczalnie również wyłącza) ograniczenia.

Należy również unikać staromodnej, niestandardowej notacji łączenia Informix OUTER. Jeśli nie używasz niemożliwie starej wersji Informix, powinieneś używać stylu łączenia SQL-92.

Wydaje się, że Twoje pytanie wspomina o dwóch połączeniach zewnętrznych, ale w przykładowym zapytaniu pokazujesz tylko jedno. To też jest nieco zagadkowe.

Warunki łączenia między „ e” a pozostałymi tabelami to:

AND c.crsnum = e.crsnum  
AND c.batch_no = e.batch_no  
AND d.lect_code= e.lect_code 

To niezwykłe połączenie. Ponieważ nie mamy odpowiedniego podzbioru schematu z odpowiednimi ograniczeniami integralności referencyjnej, trudno jest stwierdzić, czy jest to poprawne, czy nie, ale połączenie między 3 takimi tabelami jest trochę niezwykłe.

Nic z tego nie jest ostateczną odpowiedzią na twój problem; może jednak dostarczyć pewnych wskazówek.

Dziękuję za wszystkie dotychczasowe informacje. Chcę tylko dodać, że chociaż można z powodzeniem znormalizować DB, zaktualizować wszelkie zmiany schematu w swojej aplikacji (np. Do zbioru danych), jest też inna przyczyna: produkt sql CARTESIAN (podczas łączenia tabel w zapytaniach).

Istnienie wyniku zapytania w postaci kartezjańskiej spowoduje, że zduplikowane rekordy w podstawowej (lub najpierw kluczowej) tabeli dwóch lub więcej tabel zostaną połączone. Nawet jeśli określisz klauzulę „Where” w kodzie SQL, nadal może wystąpić klauzula kartezjańska, jeśli JOIN z tabelą pomocniczą zawiera na przykład sprzężenie nierówne (przydatne, gdy uzyskuje się dane z 2 lub więcej niepowiązanych tabel):

OD tbFirst INNER DOŁĄCZ tbSystem ON tbFirst.reference_str <> tbSystem.systemKey_str

Rozwiązanie tego problemu: tabele powinny być powiązane.

Dzięki. Chagbert

Rozwiązałem ten sam problem, zmieniając to z fałszywego na prawdziwe. w końcu wszedłem do bazy danych i zmieniłem moje pole bitowe, aby zezwolić na null, a następnie odświeżyłem moje xsd i odświeżyłem moje wsdl i reference.cs i teraz wszystko jest w porządku.

this.columnAttachPDFToEmailFlag.AllowDBNull = true;

Krótkie i łatwe rozwiązanie:

Idź do MSSQL Studio Sever;

Uruchom zapytanie o przyczynę tego błędu: w moim przypadku widzę, że wartość id była zerowa, ponieważ zapomniałem ustawić przyrost specyfikacji tożsamości o 1.

Tak więc wprowadzono 1 dla pola id, ponieważ jest to autoincremane i modyfikuj nie zezwalaj na NULLS w widoku projektowania

To był błąd, który spowodował, że mój adapter źródła powiązań i tabeli tabel zgłosił błąd w tym kodzie:

   this.exchangeCheckoutReportTableAdapter.Fill(this.sbmsDataSet.ExchangeCheckouReportTable);

DirectCast (dt.Rows (0), DataRow) .RowError

To bezpośrednio daje błąd

Jeśli używasz projektanta zestawów danych programu Visual Studio w celu uzyskania tabeli danych i zgłasza błąd „Nie udało się włączyć ograniczeń”. Napotkałem ten sam problem, spróbuj wyświetlić podgląd danych z samego projektanta zestawu danych i dopasuj je do tabeli w bazie danych.

Najlepszym sposobem rozwiązania tego problemu jest usunięcie adaptera tabeli i utworzenie w zamian nowego.

* Drugi sposób: *

Jeśli nie potrzebujesz, aby [id] był kluczem podstawowym,

Usuń jego atrybut klucza podstawowego:

w swoim zestawie danych> TableAdapter> kliknij prawym przyciskiem kolumnę [id]> wybierz Usuń klucz ...

Problem zostanie rozwiązany.

Miałem również ten problem i został on rozwiązany po zmodyfikowaniu pliku * .xsd, aby odzwierciedlić zmieniony rozmiar kolumny zmieniony na podstawowym serwerze SQL.

Aby naprawić ten błąd, zdjąłem kłopotliwy adapter tabel z projektanta zestawu danych i zapisałem zestaw danych, a następnie przeciągnąłem nową kopię adaptera tabel z eksploratora serwera i to naprawiło

Rozwiązałem ten problem, otwierając plik .xsd za pomocą czytnika XML i usuwając ograniczenie nałożone na jeden z moich widoków. Z jakiegoś powodu, kiedy dodałem widok do danych, dodałem ograniczenie klucza podstawowego do jednej z kolumn, podczas gdy nie powinno być.

Innym sposobem jest normalne otwarcie pliku .xsd, obejrzenie tabeli / widoku powodującego problem i usunięcie wszelkich kluczy (kliknij prawym przyciskiem kolumnę, wybierz delete key), których nie powinno tam być.

Po prostu chcę dodać kolejny możliwy powód wyjątku do tych wymienionych powyżej (szczególnie dla osób, które lubią ręcznie definiować schemat zbioru danych):

gdy w zbiorze danych masz dwie tabele i istnieje relacja ( DataSet.Reletions.Add()) zdefiniowana między polem pierwszej tabeli ( chfield) a polem drugiej tabeli ( pfield), to do tego pola jest dodawane niejawne ograniczenie, aby było unikalne nawet jeśli może nie być określony jako taki jawnie w Twojej definicji ani jako unikalny, ani jako klucz podstawowy.

W konsekwencji, jeśli masz wiersze z powtarzającymi się wartościami w tym polu nadrzędnym ( pfield), otrzymasz również ten wyjątek.

            using (var tbl = new DataTable())
            using (var rdr = cmd.ExecuteReader())
            {
                tbl.BeginLoadData();

                try
                {
                    tbl.Load(rdr);
                }
                catch (ConstraintException ex)
                {
                    rdr.Close();
                    tbl.Clear();

                    // clear constraints, source of exceptions
                    // note: column schema already loaded!
                    tbl.Constraints.Clear();
                    tbl.Load(cmd.ExecuteReader());
                }
                finally
                {
                    tbl.EndLoadData();
                }
            }

Otrzymałem ten sam typ błędu iw moim przypadku rozwiązałem go, usuwając zaznaczone pola i zastępując je *. Nie mam pojęcia, dlaczego to się dzieje. W zapytaniu nie było literówek ani niczego szczególnego.

Nie było to najlepsze rozwiązanie, ale nic innego nie działało i byłem wyczerpany.

W moich poszukiwaniach jasnej odpowiedzi znalazłem to pod tym adresem : https://www.codeproject.com/questions/45516/failed-to-enable-constraints-one-or-more-rows-cont

Rozwiązanie 8

Ten błąd pojawiał się również w moim projekcie, używając Visual Studio 2010. Próbowałem innych rozwiązań opublikowanych na innych blogach, ale bez powodzenia, ponieważ problem nie miał nic wspólnego z rozmiarem pól, definicją pól kluczy tabeli, ograniczeniami lub EnforceConstraints zmienną zbioru danych.

W moim przypadku mam obiekt .xsd, który umieściłem tam podczas projektowania projektu (w warstwie dostępu do danych). Podczas przeciągania obiektów tabeli bazy danych do elementu wizualnego Zestaw danych odczytuje każdą definicję tabeli z podstawowej bazy danych i kopiuje ograniczenia do elementuDataset obiektu dokładnie tak, jak je zdefiniowałeś podczas tworzenia tabel w bazie danych (w moim przypadku SQL Server 2008 R2 ). Oznacza to, że każda kolumna tabeli utworzona z ograniczeniem „nie null” lub „klucz obcy” musi być również obecna w wyniku instrukcji SQL lub procedury składowanej.

Po uwzględnieniu wszystkich kolumn z ograniczeniami (nie null, klucza podstawowego, klucza obcego itp.) Do moich zapytań problem całkowicie zniknął.

Być może nie potrzebujesz, aby wszystkie kolumny tabeli były obecne w zapytaniu / wyniku procedury składowanej, ale ponieważ ograniczenia są nadal stosowane, błąd jest wyświetlany, jeśli w wyniku nie pojawia się jakaś kolumna z ograniczeniami.

Mam nadzieję, że to pomoże komuś innemu.

W moim przypadku ten błąd został wywołany rozmiarem kolumny typu string. Dziwne było to, że gdy wykonałem dokładnie to samo zapytanie w innym narzędziu, nie było tam powtarzających się wartości ani wartości zerowych.

Potem odkryłem, że rozmiar kolumny łańcuchowej wynosił 50, więc kiedy wywołałem metodę fill, wartość została obcięta, rzucając ten wyjątek.
Klikam na kolumnę i ustawiam we właściwościach rozmiar na 200 i błąd zniknął.

Mam nadzieję, że to pomoże

Rozwiązałem ten problem, wykonując „podselekcję” w ten sposób:

string newQuery = "select * from (" + query + ") as temp";

Kiedy zrobisz to na mysql, wszystkie właściwości collunms (unikalne, niezerowe ...) zostaną wyczyszczone.