Internet

Podjęto próbę wstawienia nieunikalnej wartości do unikalnego indeksu. Błąd: próba wstawienia nieunikalnej wartości do unikalnego indeksu: serwer microsoft sql

Natrafiłeś na wiadomość zawierającą wiersze:
Dostawca Microsoft OLE DB dla programu SQL Server: CREATE UNIQUE INDEX zakończone, ponieważ znaleziono zduplikowany klucz dla identyfikatora indeksu
lub
Nie można wstawić zduplikowanego wiersza klucza w obiekcie
lub
Podjęto próbę wstawienia nieunikalnej wartości do unikalnego indeksu.

Opcje rozwiązania:

1. W studiu zarządzania SQL Server fizycznie niszczymy uszkodzony indeks (w moim przypadku był to indeks na tablicy sum rejestru księgowego). W 1C będziemy dystrybuować wadliwe dokumenty. W trybie testowania i korekcji zaznacz pola wyboru dla ponownego indeksowania tabel + przeliczania sum. 1C odtwarza indeks bez błędów. Wykonujemy wcześniej nieudane dokumenty.

2. 1) Z pomocą Management Studio 2005 wygenerowałem skrypt do tworzenia indeksu, który był błędny i zapisałem go do pliku.
2) Ręcznie zabił indeks z tabeli _AccumRgTn19455
3) Uruchomiono prośbę, taką jak
Kod SQL S_elect count(*), index_fields
FR OM AccumRgTn19455
GROUP BY index_field
POSIADAJĄC liczbę(*)>1
Po zabiciu indeksu wyświetliłem 15 zduplikowanych rekordów, chociaż przed krokiem 2 zapytanie nic nie zwróciło.
4) Przejrzałem wszystkie zapisy i ręcznie wyczyściłem duplikaty. W rzeczywistości użyłem również przetwarzania „Struktury raportu”, aby zrozumieć, z czym mam do czynienia w ogóle. Okazało się, że w tabeli _AccumRgTn19455 przechowywany jest rejestr akumulacji „Produkt wyjściowy (rozliczenie podatkowe)”. Pogrzebałem też w zapytaniach sql, zidentyfikowałem 15 nieunikalnych dokumentów i po wykonaniu wszystkich czynności sprawdziłem w 1C, że dokumenty te są przetwarzane normalnie, bez błędów. Oczywiście nie warto tak po prostu czyścić stołów na chybił trafił: ważne jest, aby zrozumieć, co jest czyszczone i w co może się to zmienić.
5) Uruchomiono zapytanie o utworzenie indeksu, które zostało zapisane w pliku.
6) Przełączyłem bazę danych w tryb pojedynczego użytkownika i uruchomiłem dbcc checkdb - tym razem nie było błędów.
7) Przeniesiono bazę z powrotem do trybu pojedynczego użytkownika.
Wszystko... problem został pokonany. Cóż, nawet w 1C uruchomiłem „Testing and Correction”, tam też wszystko poszło dobrze, przestało przeklinać nieunikalny indeks.

3. Jeśli nieunikalność tkwi w datach o wartościach zerowych, problem rozwiązuje się tworząc bazę z parametrem offset równym 2000.

1. Jeżeli problemem jest ładowanie bazy danych, to:
1.1. Jeśli ładujesz (za pomocą pliku dt) do bazy danych MS SQL Server, to podczas tworzenia bazy danych, przed załadowaniem, określ przesunięcie daty - 2000.
Jeśli podstawa została już utworzona z odsunięciem 0, utwórz nową z 2000.

1.2. Jeżeli istnieje możliwość pracy z bazą danych w wersji plikowej to należy wykonać Testowanie i Naprawę oraz Konfiguracja - Sprawdzenie konfiguracji - Sprawdzenie logicznej spójności konfiguracji + Wyszukiwanie błędnych linków.

1.3. Jeśli nie ma wariantu pliku, spróbuj załadować z DT do wariantu klient/serwer DB2 (która jest mniej wybredna jeśli chodzi o unikalność), a następnie uruchom Test i naprawę oraz Konfiguracja - Sprawdzanie konfiguracji - Sprawdzanie spójności logicznej konfiguracji + Wyszukiwarka złych referencji.

1.4. Aby zlokalizować problem, możesz określić dane obiektu, którego wczytanie nie powiodło się. W tym celu należy włączyć śledzenie w czasie rozruchu w narzędziu Profiler lub włączyć rejestrowanie w dzienniku zdarzeń procesu DBMSSQL i EXCP.

2. Jeżeli problem nieunikalności ujawni się podczas pracy użytkowników:

2.1. Znajdź problematyczne żądanie, korzystając z metody opisanej w paragrafie 1.4.

2.1.2. Czasami podczas realizacji żądań pojawia się błąd, na przykład:

Ten błąd występuje ze względu na fakt, że w module rejestru akumulacji " Czas pracy pracowników organizacji” w procedurze „RejestrRecalculations” we wniosku nie zawiera słowa serwisowego „INNE”.
Kod 1C v 8.x Czyli Powinien być:
Żądanie = Nowe żądanie (
„WYBIERZ INNY
| Podstawowe.Indywidualne,
. . . . .
W najnowszych wydanych wydaniach ZUP i UPP błąd nie występuje, ponieważ. mówi „RÓŻNE”.

2.2. Po znalezieniu problematycznego indeksu z poprzedniego akapitu, musisz znaleźć nieunikalny wpis.
2.2.1. Skrypt "Fish" do definiowania nieunikalnych rekordów za pomocą SQL:
Kod SQL S_elect COUNT(*) Licznik,<перечисление всех полей соответствующего индекса>z<имя таблицы>
GRUPUJ WEDŁUG<перечисление всех полей соответствующего индекса>
POSIADAJĄCY Licznik > 1

2.2.2 Przykład. Indeks błędu nosi nazwę „_Document140_VT1385_IntKeyIndNG”.
Lista pól tabeli:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RRRef, _Fld1394, _Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld22261_RRRef
Przed wykonaniem poniższej procedury wykonaj utworzyć kopię zapasową Baza danych.
Uruchom w MS SQL Server Query Analyzer:
Kod SQL S_elect count(*), _Document140_IDRRef, _KeyField
z _Dokument140_VT1385
grupuj według _Document140_IDRRef, _KeyField
mając liczbę (*) > 1
Użyj go, aby znaleźć wartości kolumn _Document140_IDRRef, _KeyField, zduplikowane rekordy (id, klucz).

Z prośbą:
Kod SQL S_elect *
z _Dokument140_VT1385
gdzie _Document140_IDRRef = id1 i _KeyField = klucz1 lub _Document140_IDRRef = id2 i _KeyField = klucz2 lub ...
spójrz na wartości innych kolumn zduplikowanych wpisów.
Jeśli oba wpisy mają znaczące wartości, a te wartości są różne, ustaw wartość _KeyField tak, aby była unikalna. W tym celu zdefiniuj maksymalną zajętą wartość _KeyField(keymax):
Kod SQL S_elect max(_KeyField)
z _Dokument140_VT1385
gdzie_Document140_IDRRef=id1?
Zastąp wartość _KeyField w jednym ze zduplikowanych wpisów poprawną wartością:
Aktualizacja kodu SQL _Document140_VT1385
ustaw _KeyField = keymax + 1

Tutaj _LineNo1386 = jest dodatkowym warunkiem, który pozwala wybrać jeden z dwóch zduplikowanych wpisów.

Jeśli jeden (lub oba) zduplikowane wpisy mają ewidentnie błędną wartość, należy ją usunąć:
Usuń kod SQL z _Document140_VT1385
gdzie _Document140_IDRRef = id1 i _LineNo1386 = lineno1
Jeśli zduplikowane wpisy mają te same wartości we wszystkich kolumnach, należy pozostawić jeden z nich:
Kod SQL S_elect odrębny *
w #tmp1
z _Dokument140_VT1385

Usuń z _Document140_VT1385
gdzie _Document140_IDRRef = id1 i _KeyField = klucz1

Wstawiam do _Dokument140_VT1385
Wybierz #tmp1

Tabela D_rop #tmp1

Opisaną procedurę należy wykonać dla każdej pary zduplikowanych wpisów.

2.2.3. Drugi przykład:
Kod SQL S_elect COUNT(*) AS Wyr2, _IDRRef AS Wyr1, _Opis
OD _Odniesienie8_
GRUPA WG _IDRRef, _Opis
POSIADAJĄC (LICZBA (*) > 1)

2.3.4 Przykład definiowania nieunikalnych rekordów za pomocą zapytania 1C:Enterprise:
Kod 1C v 8.x WYBIERZ Podręcznik. Link
Katalog FROM Katalog AS Katalog
GRUPUJ WEDŁUG
POSIADAJĄCY ILOŚĆ (*) > 1

Informacje zaczerpnięte ze strony

Opcje rozwiązania:

2. 1) Z pomocą Management Studio 2005 wygenerowałem skrypt do tworzenia indeksu, który był błędny i zapisałem go do pliku.
2) Ręcznie zabił indeks z tabeli _AccumRgTn19455
3) Uruchomiono prośbę, taką jak
Kod SQL S_elect count(*), index_fields
Z AkumulacjiRgTn19455
GROUP BY index_field
POSIADAJĄC liczbę(*)>1
Po zabiciu indeksu wyświetliłem 15 zduplikowanych rekordów, chociaż przed krokiem 2 zapytanie nic nie zwróciło.
4) Przejrzałem wszystkie zapisy i ręcznie wyczyściłem duplikaty. W rzeczywistości użyłem również przetwarzania „Struktury raportu”, aby zrozumieć, z czym mam do czynienia w ogóle. Okazało się, że w tabeli _AccumRgTn19455 przechowywany jest rejestr akumulacji „Produkt wyjściowy (rozliczenie podatkowe)”. Pogrzebałem też w zapytaniach sql, zidentyfikowałem 15 nieunikalnych dokumentów i po wykonaniu wszystkich czynności sprawdziłem w 1C, że dokumenty te są przetwarzane normalnie, bez błędów. Oczywiście nie warto tak po prostu czyścić stołów na chybił trafił: ważne jest, aby zrozumieć, co jest czyszczone i w co może się to zmienić.
5) Uruchomiono zapytanie o utworzenie indeksu, które zostało zapisane w pliku.
6) Przełączyłem bazę danych w tryb pojedynczego użytkownika i uruchomiłem dbcc checkdb - tym razem nie było błędów.
7) Przeniesiono bazę z powrotem do trybu pojedynczego użytkownika.
Wszystko... problem został pokonany. Cóż, nawet w 1C uruchomiłem „Testing and Correction”, tam też wszystko poszło dobrze, przestało przeklinać nieunikalny indeks.

3. Jeśli nieunikalność tkwi w datach o wartościach zerowych, problem rozwiązuje się tworząc bazę z parametrem offset równym 2000.

2. Jeżeli problem nieunikalności ujawni się podczas pracy użytkowników:

2.1. Znajdź problematyczne żądanie, korzystając z metody opisanej w paragrafie 1.4.

2.1.2. Czasami podczas realizacji żądań pojawia się błąd, na przykład:

Ten błąd występuje z uwagi na fakt, że w module rejestru akumulacji „Czas pracy pracowników organizacji” w procedurze „Rejestr Przeliczenia” we wniosku nie ma słowa serwisowego „INNE”.
Kod 1C v 8.x Czyli Powinien być:
Żądanie = Nowe żądanie (
„WYBIERZ INNY
| Podstawowe.Indywidualne,
. . . . .
W najnowszych wydanych wydaniach ZUP i UPP błąd nie występuje, ponieważ. mówi „RÓŻNE”.

2.2.2 Przykład. Indeks błędu nosi nazwę „_Document140_VT1385_IntKeyIndNG”.
Lista pól tabeli:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RRRef, _Fld1394, _Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld22261_RRRef
Przed wykonaniem poniższej procedury wykonaj kopię zapasową bazy danych.
Uruchom w MS SQL Server Query Analyzer:
Kod SQL S_elect count(*), _Document140_IDRRef, _KeyField
z _Dokument140_VT1385
grupuj według _Document140_IDRRef, _KeyField
mając liczbę (*) > 1
Użyj go, aby znaleźć wartości kolumn _Document140_IDRRef, _KeyField, zduplikowane rekordy (id, klucz).

Z prośbą:
Kod SQL S_elect *
z _Dokument140_VT1385
lub _Document140_IDRRef = id2 i _KeyField = klucz2 lub ...
spójrz na wartości innych kolumn zduplikowanych wpisów.
Jeśli oba wpisy mają znaczące wartości, a te wartości są różne, ustaw wartość _KeyField tak, aby była unikalna. W tym celu zdefiniuj maksymalną zajętą wartość _KeyField(keymax):
Kod SQL S_elect max(_KeyField)
z _Dokument140_VT1385
gdzie _Document140_IDRRef = id1
Zastąp wartość _KeyField w jednym ze zduplikowanych wpisów poprawną wartością:
Aktualizacja kodu SQL _Document140_VT1385
ustaw _KeyField = keymax + 1
Tutaj _LineNo1386 = jest dodatkowym warunkiem, który pozwala wybrać jeden z dwóch zduplikowanych wpisów.

Usuń z _Document140_VT1385
gdzie _Document140_IDRRef = id1 i _KeyField = klucz1

Wstawiam do _Dokument140_VT1385
Wybierz #tmp1

Tabela D_rop #tmp1

Opisaną procedurę należy wykonać dla każdej pary zduplikowanych wpisów.

2.2.3. Drugi przykład:
Kod SQL S_elect COUNT(*) AS Wyr2, _IDRRef AS Wyr1, _Opis
OD _Odniesienie8_
GRUPA WG _IDRRef, _Opis
POSIADAJĄC (LICZBA (*) > 1)

Opcje rozwiązania:

2. 1) Z pomocą Management Studio 2005 wygenerowałem skrypt do tworzenia indeksu, który był błędny i zapisałem go do pliku.
2) Ręcznie zabił indeks z tabeli _AccumRgTn19455
3) Uruchomiono prośbę, taką jak
Kod SQL S_elect count(*), index_fields
Z AkumulacjiRgTn19455
GROUP BY index_field
POSIADAJĄC liczbę(*)>1
Po zabiciu indeksu wyświetliłem 15 zduplikowanych rekordów, chociaż przed krokiem 2 zapytanie nic nie zwróciło.
4) Przejrzałem wszystkie zapisy i ręcznie wyczyściłem duplikaty. W rzeczywistości użyłem również przetwarzania „Struktury raportu”, aby zrozumieć, z czym mam do czynienia w ogóle. Okazało się, że w tabeli _AccumRgTn19455 przechowywany jest rejestr akumulacji „Produkt wyjściowy (rozliczenie podatkowe)”. Pogrzebałem też w zapytaniach sql, zidentyfikowałem 15 nieunikalnych dokumentów i po wykonaniu wszystkich czynności sprawdziłem w 1C, że dokumenty te są przetwarzane normalnie, bez błędów. Oczywiście nie warto tak po prostu czyścić stołów na chybił trafił: ważne jest, aby zrozumieć, co jest czyszczone i w co może się to zmienić.
5) Uruchomiono zapytanie o utworzenie indeksu, które zostało zapisane w pliku.
6) Przełączyłem bazę danych w tryb pojedynczego użytkownika i uruchomiłem dbcc checkdb - tym razem nie było błędów.
7) Przeniesiono bazę z powrotem do trybu pojedynczego użytkownika.
Wszystko... problem został pokonany. Cóż, nawet w 1C uruchomiłem „Testing and Correction”, tam też wszystko poszło dobrze, przestało przeklinać nieunikalny indeks.

3. Jeśli nieunikalność tkwi w datach o wartościach zerowych, problem rozwiązuje się tworząc bazę z parametrem offset równym 2000.

2. Jeżeli problem nieunikalności ujawni się podczas pracy użytkowników:

2.1. Znajdź problematyczne żądanie, korzystając z metody opisanej w paragrafie 1.4.

2.1.2. Czasami podczas realizacji żądań pojawia się błąd, na przykład:

2.2.2 Przykład. Indeks błędu nosi nazwę „_Document140_VT1385_IntKeyIndNG”.
Lista pól tabeli:
_Document140_IDRRef, _KeyField, _LineNo1386, _Fld1387, _Fld1388, _Fld1389, _Fld1390, _Fld1391RRef, _Fld1392RRef, _Fld1393_TYPE, _Fld1393_RTRef, _Fld1393_RRRef, _Fld1394, _Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_RTRef, _Fld22261_RRRef
Przed wykonaniem poniższej procedury wykonaj kopię zapasową bazy danych.
Uruchom w MS SQL Server Query Analyzer:
Kod SQL S_elect count(*), _Document140_IDRRef, _KeyField
z _Dokument140_VT1385
grupuj według _Document140_IDRRef, _KeyField
mając liczbę (*) > 1
Użyj go, aby znaleźć wartości kolumn _Document140_IDRRef, _KeyField, zduplikowane rekordy (id, klucz).

Usuń z _Document140_VT1385
gdzie _Document140_IDRRef = id1 i _KeyField = klucz1

Wstawiam do _Dokument140_VT1385
Wybierz #tmp1

Tabela D_rop #tmp1

Opisaną procedurę należy wykonać dla każdej pary zduplikowanych wpisów.

2.2.3. Drugi przykład:
Kod SQL S_elect COUNT(*) AS Wyr2, _IDRRef AS Wyr1, _Opis
OD _Odniesienie8_
GRUPA WG _IDRRef, _Opis
POSIADAJĄC (LICZBA (*) > 1)

Błąd występuje, jeśli niektóre obiekty, atrybuty, podkonto mają w bazie danych wartość NULL, ale nie mogą mieć takiej wartości. A ten błąd pojawia się tylko w bazach SQL. Tych. jeśli taka baza danych zostanie wyładowana do pliku jeden, to tego błędu nie będzie. Bo baza plików ma swoje własne tabele (w sumie 4), a SQL ma swoje własne. A baza danych SQL krytycznie reaguje na takie wartości w swoich tabelach.

Problemu tego nie rozwiązują żadne testy (ani zewnętrzne, ani wewnętrzne) w dowolnych wariantach baz danych (SQL lub plik), a nawet procedura _1sp_DBReindex w menedżerze SQL, która zdaje się mieć na celu restrukturyzację tabel w SQL.

Przeanalizujmy rozwiązanie problemu na przykładzie przejścia z Accounting 3.0 PROF na CORP. Po przejściu konto 68.01 ma nowy subconto Rejestracja w urzędzie skarbowym. A potem w bazach danych na SQL wszelkie tworzenie w wersji PROF dokumentów korzystających z tego konta nie zostanie przebudowane. Pojawi się błąd pokazany powyżej. Bo to nowe podkonto dla starych dokumentów, w księgowaniach, zostanie zapisane z wartością NULL (chociaż powinno być pusta wartość, no lub jakoś organ podatkowy).

Aby rozwiązać ten błąd, musisz usunąć wartości NULL tam, gdzie nie powinny. W tym przypadku w dokumentach, w których stosuje się subconto RegistrationIn Tax Authority. Możesz to zrobić, pisząc przetwarzanie, które zastąpi NULL wartością Empty (gotowe przetwarzanie można pobrać z tego artykułu). Czy przetwarzanie, tk. próba ręcznej zmiany wartości tego podkonta w księgowaniach dokumentów prowadzi do tego samego błędu.

Przetwarzanie w celu zastąpienia wartości NULL we wszystkich kontaktach podrzędnych Rejestracja w urzędzie skarbowym można pobrać z tego artykułu, poniżej.

ALE nie zadziała zastąpienie NULL w bazie danych SQL, ten sam błąd zostanie wygenerowany podczas przetwarzania. Dlatego musisz to zrobić:

1. Wgraj już działającą, przetłumaczoną na wersję CORP bazę danych SQL do dt'snik (w konfiguratorze Administracja - Wgraj bazę - wybierz gdzie wgrać bazę w postaci pliku *.dt)

2. Wgraj dt do bazy plików (w niepotrzebnej lub wcześniej przygotowanej, czystej bazie plików, w konfiguratorze Administracja - Załaduj bazę danych - wybierz wyładowane wcześniej dt)

3. Wykonaj przetwarzanie w bazie plików (nie będzie błędu i wszystkie NULL zostaną poprawnie podmienione) (jak wykonać przetwarzanie opisano poniżej)

5. Teraz przeciwnie, wyładuj dt z bazy plików i załaduj je do bazy danych SQL. Teraz przy księgowaniu przetworzonych dokumentów nie będzie błędów.

Przetwarzanie z tego artykułu wyszukuje wszystkie dokumenty z określonego okresu, w którym księgowania mają pod-kontakt RegistrationIn Tax Authority (który występuje w wersji CORP), który ma wartość NULL. I zastępuje tę wartość pustą wartością.

W przetwarzaniu należy określić okres, na jaki trzeba przetworzyć dokumenty (jest to możliwe przez cały okres przechowywania danych w bazie danych) i kliknąć „Wypełnij część tabelaryczną”. Następnie możesz zaznaczyć pola wyboru, które dokumenty chcesz przetworzyć (możesz zaznaczyć wszystkie) i kliknąć przycisk „Przeprowadź przetwarzanie”.

Odpowiednio jeśli ktoś ma ten sam błąd, ale NIE po przejściu na CORP, ale np. po wymianie, załadowaniu jakichś danych, wykonaniu jakiejś obróbki itp. Następnie należy określić, gdzie w konkretnym dokumencie/katalogu została przypisana wartość NULL i usunąć tę wartość NULL w podobny sposób, ale przez własne przetwarzanie, ale w kolejności opisanej powyżej. Pamiętaj, że NULL może być, podobnie jak w przypadku księgowania dokumentów, m.in. nie tylko księgowość, ale gdzieś w formie dokumentu/katalogu, w jakichś szczegółach, ale w tym przypadku chyba nawet się nie otworzy.

Ponadto, jeśli miałeś ten błąd podczas księgowania dokumentu, to po przeniesieniu bazy plików Bukh CORP do SQL (a baza była pierwotnie PROF), oznacza to, że te dokumenty, które zostały utworzone w wersji PRO, są teraz również w RejestracjiIn Organ podatkowy poda wartość NULL, a baza danych SQL tego nie akceptuje. A podczas ładowania bazy w SQL pojawi się taki błąd. Tutaj faktycznie nie będzie wartości NULL w bazie plików, ale SQL załaduje dokładnie takie wartości do swoich tabel. Dlatego tutaj trzeba wymusić Baza danych SQL utwórz te wartości NULL, a następnie napraw je w bazie plików.Ale nie powiem ci, jak to zrobić.