Trafiłeś na wiadomość zawierającą wiersze:
Dostawca Microsoft OLE DB dla SQL Server: operacja CREATE UNIQUE INDEX zakończona, ponieważ znaleziono zduplikowany klucz dla identyfikatora indeksu
lub
Nie można I_nsert 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 zły indeks (w moim przypadku był to indeks w tabeli sumarycznej rejestru księgowego). W 1C będziemy dystrybuować wadliwe dokumenty. W trybie testowania i korygowania zaznacz pola dla ponownego indeksowania tabel + ponownego obliczania sum. 1C odtwarza indeks bez błędów. Wykonujemy wcześniej nieudane dokumenty.
2.
1) Używając Management Studio 2005, wygenerowałem skrypt do tworzenia indeksu, który był błędny i zapisałem go do pliku.
2) Ręcznie zabiłem indeks z tabeli _AccumRgTn19455
3) Uruchomiono zapytanie, takie jak
Kod SQL S_elect count (*) index_fields
Z AccumRgTn19455
GROUP BY index_field
MAJĄC licznik (*)\u003e 1
Po zabiciu indeksu otrzymałem 15 zduplikowanych rekordów, chociaż przed krokiem 2 zapytanie nic nie zwróciło.
4) Przejrzałem wszystkie rekordy i ręcznie wyczyściłem duplikaty. W rzeczywistości korzystałem również z przetwarzania „Struktury raportu”, aby zrozumieć, z czym w ogóle mam do czynienia. Okazało się, że w tabeli _AccumRgTn19455 przechowywany jest rejestr akumulacji „Wyjście produktu (rozliczenie podatkowe)”. Nadal kopałem z zapytaniami sql, zidentyfikowałem 15 nieunikalnych dokumentów i po wykonaniu wszystkich czynności, które sprawdziłem w 1C, że te dokumenty są przetwarzane normalnie, bez błędów. Oczywiście nie warto po prostu czyścić stołów na chybił trafił: ważne jest, aby zrozumieć, co jest czyszczone i jak może się to skończyć.
5) Uruchomiono żądanie utworzenia indeksu, który został zapisany w pliku.
6) Przełączyłem bazę danych w tryb pojedynczego użytkownika i uruchomiłem dbcc checkdb - tym razem nie było żadnych błędów.
7) Przeniesiono bazę z powrotem do trybu pojedynczego użytkownika.
To wszystko ... problem został pokonany. Cóż, nawet w 1C uruchomiłem "Testowanie i korekta", tam też wszystko poszło dobrze, przestałem przeklinać na nieunikalny indeks.
3. Jeśli niejednoznaczność polega na datach o zerowej wartości, to problem zostanie rozwiązany przez utworzenie bazy z parametrem przesunięcia równym 2000.
1. Jeśli problem dotyczy ładowania bazy danych, to:
1.1. Jeśli wgrywasz (korzystasz z 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śli możliwa jest praca z bazą danych w wersji plikowej, należy wykonać Testowanie i Korektę oraz Konfiguracja - Sprawdzenie konfiguracji - Sprawdzenie logicznej integralności konfiguracji + Poszukiwanie nieprawidłowych linków.
1.3. Jeśli nie ma wersji pliku, spróbuj uruchomić system z DT do wersji klient / serwer z DB2 (która jest mniej wymagająca pod względem unikalności), a następnie wykonaj Test i napraw, a następnie Konfiguracja - Sprawdź konfigurację - Sprawdź integralność konfiguracji logicznej + Znajdź nieprawidłowe odwołania.
1.4. Aby wyodrębnić problem, możesz określić dane obiektu, którego nie udało się załadować. Aby to zrobić, należy włączyć śledzenie podczas rozruchu w programie Profiler lub włączyć rejestrowanie w dzienniku zdarzeń technologicznych DBMSSQL i EXCP.
2. Jeśli problem niejednorodności przejawia się podczas pracy użytkownika:
2.1. Znajdź zgłoszenie problemu, korzystając z metody opisanej w paragrafie 1.4.
2.1.2. Czasami podczas wykonywania żądań pojawia się błąd, na przykład:
Błąd ten występuje z uwagi na fakt, że w module rejestru akumulacji „Godziny pracy pracowników organizacji” w procedurze „RejestrRekalkulacje” żądanie nie zawiera słowa serwisowego „RÓŻNE”.
Kod 1C v 8.x Tj. Powinien być:
Żądanie \u003d Nowe żądanie (
„WYBIERZ RÓŻNE
| Basic.PhysFace,
. . . . .
W najnowszych wydanych wersjach ZUP i UPP błąd nie występuje, ponieważ jest „RÓŻNE”.
2.2. Po znalezieniu problematycznego indeksu z poprzedniego punktu, musisz znaleźć nieunikalny wpis.
2.2.1. Skrypt Fish do definiowania nieunikalnych rekordów za pomocą SQL:
Kod SQL S_elect COUNT (*) Licznik,<перечисление всех полей соответствующего индекса> od<имя таблицы>
GRUPUJ WEDŁUG<перечисление всех полей соответствующего индекса>
MAJĄC licznik\u003e 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 analizatorze zapytań MS SQL Server:
Kod SQL S_elect count (*), _Document140_IDRRef, _KeyField
z _Document140_VT1385
grupuj według _Document140_IDRRef, _KeyField
liczenie (*)\u003e 1
Użyj go, aby znaleźć wartości kolumn _Document140_IDRRef, _KeyField, zduplikowane rekordy (id, klucz).
Na żądanie:
SQL S_elect *
z _Document140_VT1385
lub _Document140_IDRRef \u003d id2 i _KeyField \u003d key2 lub ...
spójrz na wartości innych kolumn zduplikowanych rekordów.
Jeśli oba wpisy mają znaczące wartości, a wartości są różne, popraw wartość _KeyField, aby była unikalna. Aby to zrobić, zdefiniuj maksymalną zajmowaną wartość _KeyField (keymax):
Kod SQL S_elect max (_KeyField)
z _Document140_VT1385
gdzie _Document140_IDRRef \u003d id1
Zastąp wartość _KeyField w jednym ze zduplikowanych wpisów na poprawną:
Aktualizacja SQL _Document140_VT1385
ustaw _KeyField \u003d keymax + 1
Tutaj _LineNo1386 \u003d - dodatkowy warunekco pozwala wybrać jeden z dwóch zduplikowanych wpisów.
Jeśli jeden (lub oba) zduplikowane rekordy mają ewidentnie nieprawidłową wartość, należy ją usunąć:
Usuń kod SQL z _Document140_VT1385
gdzie _Document140_IDRRef \u003d id1 i _LineNo1386 \u003d lineno1
Jeśli zduplikowane rekordy mają te same wartości we wszystkich kolumnach, to jeden z nich należy pozostawić:
SQL S_elect odrębny *
do # tmp1
z _Document140_VT1385
gdzie _Document140_IDRRef \u003d id1 i _KeyField \u003d key1
Usuń z _Document140_VT1385
gdzie _Document140_IDRRef \u003d id1 i _KeyField \u003d key1
I_nsert do _Document140_VT1385
S_elect # tmp1
D_rop tabela # tmp1
Opisaną procedurę należy wykonać dla każdej pary zduplikowanych rekordów.
2.2.3. Drugi przykład:
Kod SQL S_elect COUNT (*) AS Wyr2, _IDRRef AS Wyr1, _Opis
OD _Reference8_
GROUP BY _IDRRef, _Description
POSIADA (COUNT (*)\u003e 1)
2.3.4 Przykład definiowania nieunikalnych rekordów za pomocą zapytania 1C: Enterprise:
Kod 1C v 8.x SELECT Reference.Link
FROM Reference. Reference AS Reference
ŁADUJ WEDŁUG referencji.Link
MAJĄCE ILOŚĆ (*)\u003e 1
Błąd występuje, jeśli niektóre obiekty, atrybuty, subconto mają w bazie danych wartość NULL, ale nie mogą mieć takiej wartości. A ten błąd pojawia się tylko w bazach danych SQL. Te. jeśli taka baza danych zostanie wyładowana do pliku, to tego błędu nie będzie. Dlatego baza plików ma swoje własne tabele (łącznie 4), podczas gdy SQL ma swoje własne. Baza danych SQL reaguje krytycznie na takie wartości w swoich tabelach.
Tego problemu nie rozwiązuje żadne testowanie (ani zewnętrzne, ani wewnętrzne) jakichkolwiek opcji bazy danych (SQL lub plik), a nawet procedura _1sp_DBReindex w menedżerze SQL, która wydaje się mieć na celu restrukturyzację tabel w SQL.
Przeanalizujmy rozwiązanie problemu na przykładzie przejścia z Rachunkowości 3.0 PROF do CORP. Po przeniesieniu konto 68.01 ma nowe subkonto Rejestracja w urzędzie skarbowym. A potem w bazach danych SQL wszystkie dokumenty utworzone w wersji PROF korzystające z tego konta nie będą ponownie publikowane. Zostanie wyświetlony powyższy błąd. Dlatego to nowe subkonto dla starych dokumentów w transakcjach będzie miało wartość NULL (chociaż powinna być pusta wartość, cóż, lub w jakiś sposób organ podatkowy).
Aby naprawić ten błąd, musisz usunąć wartości NULL tam, gdzie nie powinny. W tym przypadku w dokumentach, w których subkonto jest używane Rejestracja w Urzędzie Skarbowym. Możesz to zrobić, pisząc przetwarzanie, które zastępuje NULL pustą wartością (możesz pobrać ukończone przetwarzanie z tego artykułu). Zrób to przetwarzając, ponieważ próba ręcznej zmiany wartości tego subkonta w księgowaniach dokumentów powoduje ten sam błąd.
Przetwarzanie w celu zastąpienia wartości NULL we wszystkich subkontach rejestracji w urzędzie skarbowym można pobrać z tego artykułu poniżej.
ALE nie będzie działać, aby zastąpić 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ę SQL do dt'shnik (w konfiguratorze Administracja - Wyładuj bazę danych - wybierz gdzie wyładować bazę danych jako plik * .dt)
2. Załaduj dt'shnik do bazy plików (niepotrzebne lub przygotowane wcześniej, czyste, baza plików, w konfiguratorze Administracja - Podstawa obciążenia - wybierz wcześniej rozładowany dt'shnik)
3. Przeprowadź przetwarzanie w bazie danych plików (nie będzie żadnych błędów, a wszystkie wartości NULL zostaną poprawnie zastąpione) (sposób przetwarzania opisano poniżej)
5. Teraz przeciwnie, wyładuj plik dt z bazy danych plików i załaduj go do bazy danych SQL. Teraz przy wysyłaniu przetworzonych dokumentów błędy nie będą się pojawiać.
Przetwarzanie z tego artykułu powoduje znalezienie wszystkich dokumentów z określonego okresu, w którym subkontynent Rejestracja w urzędzie skarbowym (pojawiający się w wersji CORP) występuje w transakcjach, które mają wartość NULL. I zastępuje tę wartość wartością Pustą.
W trakcie przetwarzania konieczne jest wskazanie okresu, przez jaki konieczne jest przetwarzanie dokumentów (możliwe jest to przez cały okres przechowywania zapisów w bazie danych) i kliknięcie „Wypełnij sekcję tabelaryczną”. Następnie możesz zaznaczyć polami wyboru, które dokumenty mają zostać przetworzone (możesz wybrać wszystkie) i kliknąć przycisk „Przetwarzaj”.
W związku z tym, jeśli ktoś ma ten sam błąd, ale NIE po przełączeniu na CORP, a np. Po wymianie, pobraniu jakichś danych, wykonaniu jakiejś obróbki itp. Następnie należy dowiedzieć się, gdzie została przypisana wartość NULL w konkretnym dokumencie / książce informacyjnej i w podobny sposób usunąć tę wartość NULL, ale z naszym własnym przetwarzaniem, ale w kolejności opisanej powyżej. Pamiętaj, że NULL może być, tak jak w przypadku transakcji dokumentowych, m.in. nie tylko księgowości, ale gdzieś w formie dokumentu / podręcznika, w jakichś potrzebnych, ale w tym przypadku prawdopodobnie nawet się nie otworzy.
Ponadto, jeśli wystąpił ten błąd podczas publikowania dokumentu, po przeniesieniu bazy pliku Bukh CORP do SQL (a bazą była pierwotnie PROF), to te dokumenty, które zostały utworzone w wersji PROF, są teraz również na subkoncie rejestracyjnym w organie podatkowym wartość NULL, a baza danych SQL tego nie akceptuje. A przy ładowaniu bazy danych do SQL pojawi się taki błąd. Tutaj w rzeczywistości w bazie danych plików wartości NULL w rzeczywistości nie, ale SQL załaduje tylko takie wartości do swoich tabel. Dlatego tutaj musisz zmusić bazę danych SQL do utworzenia tych wartości NULL, a następnie naprawić je w bazie danych plików, ale nie powiem ci, jak to zrobić.
Trafiłeś na wiadomość zawierającą wiersze:
Dostawca Microsoft OLE DB dla SQL Server: operacja CREATE UNIQUE INDEX zakończona, ponieważ znaleziono zduplikowany klucz dla identyfikatora indeksu
lub
Nie można I_nsert 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 zły indeks (w moim przypadku był to indeks w tabeli sumarycznej rejestru księgowego). W 1C będziemy dystrybuować wadliwe dokumenty. W trybie testowania i korygowania zaznacz pola dla ponownego indeksowania tabel + ponownego obliczania sum. 1C odtwarza indeks bez błędów. Wykonujemy wcześniej nieudane dokumenty.
2.
1) Używając Management Studio 2005, wygenerowałem skrypt do tworzenia indeksu, który był błędny i zapisałem go do pliku.
2) Ręcznie zabiłem indeks z tabeli _AccumRgTn19455
3) Uruchomiono zapytanie, takie jak
Kod SQL S_elect count (*) index_fields
FR OM AccumRgTn19455
GROUP BY index_field
MAJĄC licznik (*)\u003e 1
Po zabiciu indeksu otrzymałem 15 zduplikowanych rekordów, chociaż przed krokiem 2 zapytanie nic nie zwróciło.
4) Przejrzałem wszystkie rekordy i ręcznie wyczyściłem duplikaty. W rzeczywistości korzystałem również z przetwarzania „Struktury raportu”, aby zrozumieć, z czym w ogóle mam do czynienia. Okazało się, że w tabeli _AccumRgTn19455 przechowywany jest rejestr akumulacji „Wyjście produktu (rozliczenie podatkowe)”. Nadal kopałem z zapytaniami sql, zidentyfikowałem 15 nieunikalnych dokumentów i po wykonaniu wszystkich czynności, które sprawdziłem w 1C, że te dokumenty są przetwarzane normalnie, bez błędów. Oczywiście nie warto po prostu czyścić stołów na chybił trafił: ważne jest, aby zrozumieć, co jest czyszczone i jak może się to skończyć.
5) Uruchomiono żądanie utworzenia indeksu, który został zapisany w pliku.
6) Przełączyłem bazę danych w tryb pojedynczego użytkownika i uruchomiłem dbcc checkdb - tym razem nie było żadnych błędów.
7) Przeniesiono bazę z powrotem do trybu pojedynczego użytkownika.
To wszystko ... problem został pokonany. Cóż, nawet w 1C uruchomiłem "Testowanie i korekta", tam też wszystko poszło dobrze, przestałem przeklinać na nieunikalny indeks.
3. Jeśli niejednoznaczność polega na datach o zerowej wartości, to problem zostanie rozwiązany przez utworzenie bazy z parametrem przesunięcia równym 2000.
1. Jeśli problem dotyczy ładowania bazy danych, to:
1.1. Jeśli wgrywasz (korzystasz z 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śli możliwa jest praca z bazą danych w wersji plikowej, należy wykonać Testowanie i Korektę oraz Konfiguracja - Sprawdzenie konfiguracji - Sprawdzenie logicznej integralności konfiguracji + Poszukiwanie nieprawidłowych linków.
1.3. Jeśli nie ma wersji pliku, spróbuj uruchomić system z DT do wersji klient / serwer z DB2 (która jest mniej wymagająca pod względem unikalności), a następnie wykonaj Test i napraw, a następnie Konfiguracja - Sprawdź konfigurację - Sprawdź integralność konfiguracji logicznej + Znajdź nieprawidłowe odwołania.
1.4. Aby wyodrębnić problem, możesz określić dane obiektu, którego nie udało się załadować. Aby to zrobić, należy włączyć śledzenie podczas rozruchu w programie Profiler lub włączyć rejestrowanie w dzienniku zdarzeń technologicznych DBMSSQL i EXCP.
2. Jeśli problem niejednorodności przejawia się podczas pracy użytkownika:
2.1. Znajdź zgłoszenie problemu, korzystając z metody opisanej w paragrafie 1.4.
2.1.2. Czasami podczas wykonywania żądań pojawia się błąd, na przykład:
Błąd ten występuje z uwagi na fakt, że w module rejestru akumulacji „Godziny pracy pracowników organizacji” w procedurze „RejestrRekalkulacje” żądanie nie zawiera słowa serwisowego „RÓŻNE”.
Kod 1C v 8.x tj. Powinien być:
Żądanie \u003d Nowe żądanie (
„WYBIERZ RÓŻNE
| Basic.PhysFace,
. . . . .
W najnowszych wydanych wersjach ZUP i UPP błąd nie występuje, ponieważ jest „RÓŻNE”.
2.2. Po znalezieniu problematycznego indeksu z poprzedniego punktu, musisz znaleźć nieunikalny wpis.
2.2.1. Skrypt Fish do definiowania nieunikalnych rekordów za pomocą SQL:
Kod SQL S_elect COUNT (*) Licznik,<перечисление всех полей соответствующего индекса> od<имя таблицы>
GRUPUJ WEDŁUG<перечисление всех полей соответствующего индекса>
MAJĄC licznik\u003e 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
Wykonaj kopię zapasową bazy danych przed wykonaniem poniższej procedury.
Uruchom w analizatorze zapytań MS SQL Server:
Kod SQL S_elect count (*), _Document140_IDRRef, _KeyField
fr om _Document140_VT1385
grupuj według _Document140_IDRRef, _KeyField
liczenie (*)\u003e 1
Użyj go, aby znaleźć wartości kolumn _Document140_IDRRef, _KeyField, zduplikowane rekordy (id, klucz).
Na żądanie:
SQL S_elect *
fr om _Document140_VT1385
gdzie _Document140_IDRRef \u003d id1 i _KeyField \u003d key1 lub _Document140_IDRRef \u003d id2 i _KeyField \u003d key2 lub ...
spójrz na wartości innych kolumn zduplikowanych rekordów.
Jeśli oba wpisy mają znaczące wartości, a wartości są różne, popraw wartość _KeyField, aby była unikalna. Aby to zrobić, zdefiniuj maksymalną zajmowaną wartość _KeyField (keymax):
Kod SQL S_elect max (_KeyField)
fr om _Document140_VT1385
gdzie _Document140_IDRRef \u003d id1
Zastąp wartość _KeyField w jednym ze zduplikowanych wpisów na poprawną:
Aktualizacja SQL ate _Document140_VT1385
ustaw _KeyField \u003d keymax + 1
Tutaj _LineNo1386 \u003d jest dodatkowym warunkiem, który pozwala wybrać jeden z dwóch zduplikowanych wpisów.
Jeśli jeden (lub oba) zduplikowane rekordy mają ewidentnie nieprawidłową wartość, należy ją usunąć:
Usuń kod SQL z _Document140_VT1385
gdzie _Document140_IDRRef \u003d id1 i _LineNo1386 \u003d lineno1
Jeśli zduplikowane rekordy mają takie same wartości we wszystkich kolumnach, należy pozostawić jedną z nich:
SQL S_elect odrębny *
do # tmp1
z _Document140_VT1385
Usuń z _Document140_VT1385
gdzie _Document140_IDRRef \u003d id1 i _KeyField \u003d key1
I_nsert do _Document140_VT1385
S_elect # tmp1
D_rop tabela # tmp1
Opisaną procedurę należy wykonać dla każdej pary zduplikowanych rekordów.
2.2.3. Drugi przykład:
Kod SQL S_elect COUNT (*) AS Wyr2, _IDRRef AS Wyr1, _Opis
OD _Reference8_
GROUP BY _IDRRef, _Description
POSIADA (COUNT (*)\u003e 1)
2.3.4 Przykład definiowania nieunikalnych rekordów za pomocą zapytania 1C: Enterprise:
Kod 1C v 8.x SELECT Reference.Link
FROM Reference. Reference AS Reference
ŁADUJ WEDŁUG referencji.Link
MAJĄCE ILOŚĆ (*)\u003e 1
Informacje zaczerpnięte z serwisu
W tym artykule opiszemy, co zrobić, jeśli podczas pracy z 1C: Enterprise 8.1 natkniesz się na wiadomość zawierającą wiersze:
Nie można wstawić zduplikowanego wiersza klucza w obiekcie
Podjęto próbę wstawienia nieunikalnej wartości do unikalnego indeksu.
Co to jest indeks?
Indeksy to struktura, która umożliwia szybki dostęp do wierszy tabeli na podstawie wartości jednej lub kilku kolumn.
Indeks zawiera klucze zbudowane na podstawie co najmniej jednej kolumny tabeli lub widoku oraz wskaźniki, które odwzorowują miejsce przechowywania danych.
Indeksy zmniejszają ilość danych, które muszą zostać odczytane, aby zwrócić zestaw wyników.
Chociaż indeks jest powiązany z określoną kolumną (lub kolumnami) w tabeli, nadal jest sam w sobie obiektem bazy danych.
Indeksy tabel w bazie danych 1C: Enterprise są tworzone niejawnie podczas tworzenia obiektów konfiguracyjnych, a także z określonymi ustawieniami obiektów konfiguracyjnych.
Fizyczny charakter indeksów w MS SQL Server 2005.
Fizycznie dane są przechowywane na stronach 8Kb... Zaraz po utworzeniu tabela nie ma indeksów i wygląda jak sterta danych. Rekordy nie mają określonej kolejności przechowywania.
Jeśli chcesz uzyskać dostęp do danych, SQL Server wyprodukuje skanowanie tabeli (skanowanie stołu). SQL Server skanuje całą tabelę, aby znaleźć rekordy, których szuka.
Stąd staje się jasne podstawowe funkcje indeksy:
- zwiększenie szybkości dostępu do danych,
- wsparcie dla unikalności danych.
Pomimo swoich zalet indeksy mają również szereg wad. Pierwsza to indeksy zajmują dodatkowe miejsce na dysku i w pamięć o dostępie swobodnym... Za każdym razem, gdy tworzysz indeks, przechowujesz klucze w porządku malejącym lub rosnącym, które można nakładać na warstwy. Im większy / dłuższy klucz, tym większy rozmiar indeks. Druga wada to operacje spowalniają wstawianie, aktualizowanie i usuwanie zapisów.
W MS SQL Server 2005 zaimplementowano kilka typów indeksów:
- indeksy nieklastrowe;
- indeksy klastrowe (lub klastrowane);
- unikalne indeksy;
- indeksy z dołączonymi kolumnami
- widoki indeksowane
- pełny tekst
Unikalny indeks
Unikalność wartości w indeksowanej kolumnie jest gwarantowana przez unikalne indeksy. Jeśli są obecne, serwer nie pozwoli na wstawienie nowej wartości lub zmianę istniejącej wartości tak, aby w wyniku tej operacji w kolumnie pojawiły się dwie identyczne wartości.
Unikalny indeks jest rodzajem dodatku i można go zaimplementować zarówno dla indeksów klastrowych, jak i nieklastrowych. Jedna tabela może mieć jeden unikalny indeks klastrowy i wiele unikatowych indeksów nieklastrowych.
Unikalne indeksy należy definiować tylko wtedy, gdy jest to absolutnie konieczne. Aby zapewnić integralność danych w kolumnie, można zdefiniować ograniczenie integralności UNIQUE lub PRIMARY KEY zamiast uciekać się do unikalnych indeksów. Używanie ich tylko w celu zapewnienia integralności danych jest niepotrzebną stratą miejsca w bazie danych. Ponadto czas procesora jest poświęcany na ich konserwację.
1C: Enterprise 8.1 począwszy od wersji 8.1 aktywnie wykorzystuje klastrowe unikalne indeksy. Oznacza to, że podczas konwersji z wersji 8.0 lub przejścia z wersji 8.1.7 może wystąpić nieunikalny błąd indeksu.
Jeśli daty z zerowymi wartościami nie są unikalne, problem zostanie rozwiązany przez utworzenie podstawy z parametrem przesunięcia 2000.
Co robić?
1. Jeśli problem dotyczy ładowania bazy danych, to:
1.1. Jeśli wgrywasz (korzystasz z 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śli możliwa jest praca z bazą danych w wersji plikowej, należy wykonać Testowanie i Korektę oraz Konfiguracja - Sprawdzenie konfiguracji - Sprawdzenie logicznej integralności konfiguracji + Poszukiwanie nieprawidłowych linków.
1.3. Jeśli nie ma wersji pliku, spróbuj uruchomić system z DT do wersji klient / serwer z DB2 (która jest mniej wymagająca pod względem unikalności), a następnie wykonaj Test i napraw, a następnie Konfiguracja - Sprawdź konfigurację - Sprawdź integralność konfiguracji logicznej + Znajdź nieprawidłowe odwołania.
1.4. Aby wyodrębnić problem, możesz określić dane obiektu, którego nie udało się załadować. Aby to zrobić, należy włączyć śledzenie podczas rozruchu w programie Profiler lub włączyć rejestrowanie w dzienniku zdarzeń technologicznych DBMSSQL i EXCP.
1.5. Jeśli węzeł jest dostępny (plany wymiany), przeprowadź wymianę. Przed wymianą możesz dodatkowo wykonać paragraf 2.3.5.
2. Jeśli problem niejednorodności przejawia się podczas pracy użytkownika:
2.1. Znajdź zgłoszenie problemu, korzystając z metody opisanej w paragrafie 1.4.
2.1.2. Czasami podczas wykonywania żądań pojawia się błąd, na przykład:
Błąd ten występuje z uwagi na fakt, że w module rejestru akumulacji „Godziny pracy pracowników organizacji” w procedurze „RejestrRekalkulacje” żądanie nie zawiera słowa serwisowego „RÓŻNE”.
Te. Powinien być:
Żądanie \u003d Nowe żądanie (
WYBIERZ RÓŻNE
| Basic.PhysFace,
W najnowszych wydanych wersjach ZUP i UPP błąd nie występuje, ponieważ jest „RÓŻNE”.
2.2. Po znalezieniu problematycznego indeksu z poprzedniego punktu, musisz znaleźć nieunikalny wpis.
2.2.1. Skrypt Fish do definiowania nieunikalnych rekordów za pomocą SQL:
WYBIERZ LICZ (*) Licznik,<перечисление всех полей соответствующего индекса> od<имя таблицы>
GRUPUJ WEDŁUG<перечисление всех полей соответствующего индекса>
MAJĄC licznik\u003e 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_R9413R94, _Fld1393_R13R93_13
Fld1395, _Fld1396RRef, _Fld1397, _Fld1398, _Fld1399RRef, _Fld22260_TYPE, _Fld22260_RTRef, _Fld22260_RRRef, _Fld22261_TYPE, _Fld22261_Ref_RFRld2226
Wykonaj kopię zapasową bazy danych przed wykonaniem poniższej procedury.
Uruchom w analizatorze zapytań MS SQL Server:
select count (*), _Document140_IDRRef, _KeyField
z _Document140_VT1385
grupuj według _Document140_IDRRef, _KeyField
liczenie (*)\u003e 1
Użyj go, aby znaleźć wartości kolumn _Document140_IDRRef, _KeyField, zduplikowane rekordy (id, klucz).
Na żądanie:
wybierz *
z _Document140_VT1385
lub _Document140_IDRRef \u003d id2 i _KeyField \u003d key2 lub ...
spójrz na wartości innych kolumn zduplikowanych rekordów.
Jeśli oba wpisy mają znaczące wartości, a wartości są różne, popraw wartość _KeyField, aby była unikalna. Aby to zrobić, zdefiniuj maksymalną zajmowaną wartość _KeyField (keymax):
wybierz maks. (_KeyField)
z _Document140_VT1385
gdzie _Document140_IDRRef \u003d id1
Zastąp wartość _KeyField w jednym ze zduplikowanych wpisów na poprawną:
aktualizacja _Document140_VT1385
ustaw _KeyField \u003d keymax + 1
Tutaj _LineNo1386 \u003d jest dodatkowym warunkiem, który pozwala wybrać jeden z dwóch zduplikowanych wpisów.
Jeśli jeden (lub oba) zduplikowane rekordy mają ewidentnie nieprawidłową wartość, należy ją usunąć:
gdzie _Document140_IDRRef \u003d id1 i _LineNo1386 \u003d lineno1
Jeśli zduplikowane rekordy mają takie same wartości we wszystkich kolumnach, należy pozostawić jedną z nich:
wybierz odrębne *
do # tmp1
z _Document140_VT1385
gdzie _Document140_IDRRef \u003d id1 i _KeyField \u003d key1
usuń z _Document140_VT1385
gdzie _Document140_IDRRef \u003d id1 i _KeyField \u003d key1
wstaw do _Document140_VT1385
wybierz # tmp1
drop table # tmp1
Opisaną procedurę należy wykonać dla każdej pary zduplikowanych rekordów.
2.2.3. Drugi przykład:
SELECT COUNT (*) AS Wyr2, _IDRRef AS Wyr1, _Opis
OD _Reference8_
GROUP BY _IDRRef, _Description
POSIADA (COUNT (*)\u003e 1)
2.3.4 Przykład definiowania nieunikalnych rekordów za pomocą zapytania 1C: Enterprise:
lub do księgowości
WYBIERZ
Podzapytanie Okres,
Subquery.Registrator,
<измерения>,
SUMA (podzapytanie. Liczba rekordów) AS liczba rekordów
Z
(WYBIERZ
Okres samowystarczalny AS Okres
Samodzielny Rejestrator AS Rejestrator,
<измерения>,
1 AS Liczba rekordów
Z
Rejestr Księgowości Samonośne AS Samonośne AS Podzapytanie
ZAŁADUJ PRZEZ
Podzapytanie Okres,
Subquery.Registrator,
<измерения>
MAJĄCY
SUMA (Subquery.NumberRecords)\u003e 1
2.3.5 Spraw, aby indeks subdanych nie był unikalny. Skrypt indeksu za pomocą Management Studio.
2.3.6 Szczególny przypadek przy wymianie w RDB. Błąd przypada na tabele „pomocnicze” związane z obliczaniem sum lub wymiarów. Na przykład:
Wystąpił błąd podczas wywoływania metody kontekstowej (Write): Próba wstawienia nieunikalnej wartości do unikalnego indeksu:
Dostawca Microsoft OLE DB dla SQL Server: nie można wstawić zduplikowanego wiersza klucza w obiekcie „dbo._AccntRegED10319” z unikalnym indeksem „_Accnt10319_ByPeriod_TRNRN”.
HRESULT \u003d 80040E2F, SQLSrvr: stan błędu \u003d 1, wskaźnik ważności \u003d E, natywny \u003d 2601, wiersz \u003d 1
W takim przypadku przed załadowaniem wyłącz używanie sum, załaduj wiadomość, włącz używanie sum i przelicz ponownie.
