błąd przy konwersji do 1.73

[Ireneusz Kaźmierczak 0]

Czy miał ktoś coś takiego? Jak sobie poradzić?

Aktualizacja podmiotu: KDK22 z wersji: 1.7221 do wersji: 1.7300.0.5448 dnia: 2022-10-20 08:20:48
Zapisywanie informacji o początku konwersji
Zastosowano do podmiotu skrypt: C:\Program Files (x86)\InsERT\InsERT GT\Skrypty\skrypt1.7221_1.7300.enc
Modyfikacja wartości wersji struktury bazy z 1.7221 na 1.7300
Wartość wersji została zmodyfikowana
Aktualizacja podmiotu nie powiodła się: 0x80040e2f: The INSERT statement conflicted with the FOREIGN KEY constraint "FK_plb_SkladnikAbsencja_plb_Skladnik". The conflict occurred in database "KDK22", table "dbo.plb_Skladnik", column 'sp_Id'.
Przywrócenie podmiotu powiodło się.

[Małgorzata Malik 2]

Dzień dobry, u nas to samo

[Daniel Kozłowski 1 171]

Została znaleziona przyczyna, problem ujawnia się kiedy zostały usunięte wbudowane w program składniki, można to naprawić serwisowo lub poczekać na wersję poprawkową.

[Kamil Goleń 116]

Dziękuję bardzo za udzielenie odpowiedzi!

[Paweł Orfin 0]

Czekamy niecierpliwie na poprawkę...

[Jacek Omieciński 0]

Dzień dobry,

Czy już jest znane rozwiązanie tego problemu?

Obecnie zainstalowałem wersję 1,74 a przy aktualizacji bazy danych nie mogę przejść z 1,72 na 1,73.

[Jacek Omieciński 0]

W dniu 20.10.2022 o 13:19, Daniel Kozłowski napisał:

Została znaleziona przyczyna, problem ujawnia się kiedy zostały usunięte wbudowane w program składniki, można to naprawić serwisowo lub poczekać na wersję poprawkową.

Tzn?

Jest niedziela, wersję Subiekta mam 1,74.. wersję bazy 1,72..

o ósmej w poniedziałek startują sklepy a ja nie wiem jak rozwiązać problem:(

[Andrzej Kubik 1 099]

Zawsze może Pan odinstalować 1.74, zainstalować 1.72 i działać bez konwersji, w międzyczasie np znajdując serwisanta, który załatwi sprawę.

[Daniel Kozłowski 1 171]

2 godziny temu, Jacek Omieciński napisał:

Czy już jest znane rozwiązanie tego problemu?

Rozwiązanie problemu było znane w momencie jego powstania (przywrócenie spójności bazy danych poprzez uzupełnienie brakujących danych), przypadek ten został obsłużony przez firmę InsERT, jak widać od 3 miesięcy jest cisza, gdzie w tym czasie było wiele aktualizacji. Ja osobiście nie trafiłem na ten problem.

 

3 godziny temu, Jacek Omieciński napisał:

Obecnie zainstalowałem wersję 1,74 a przy aktualizacji bazy danych nie mogę przejść z 1,72 na 1,73.

Dla jasności / potwierdzenia, że to ta sama przyczyna można było zamieścić log z konwersji.

 

2 godziny temu, Jacek Omieciński napisał:

o ósmej w poniedziałek startują sklepy a ja nie wiem jak rozwiązać problem:(

Należy skorzystać z pomocy kogoś, kto wie jak rozwiązać problem, na przykład wybranego przez siebie dostawcy programu. Jako obejście problemu / odłożenie w czasie proszę zrobić jak napisał Andrzej.

 

Podejmując się samodzielnej aktualizacji programu należy wiedzieć, że może pojawić się wiele problemów, czy to z instalacją programu / dodatkowych komponentów, kompatybilnością innych programów (sterowniki urządzeń, SUZ) jak również z samą konwersją bazy danych (fizyczne uszkodzenia bazy danych, rozwiązania dodatkowe, błędy programu), więc należy robić to z odpowiednim przygotowaniem (po wcześniejszych testach) i/lub takim czasie, kiedy będzie można otrzymać wsparcie serwisowe.

[Arkadiusz Cieśla 199]

Dzień dobry, nie odnotowujemy problemów związanych z konwersją bazy danych. Zgodnie z przedmówcą, w celu analizy problemu proszę zamieścić log z konwersji podmiotu lub przesłać go przez formularz kontaktowy.

• InsERT GT – Jak uzyskać logi z nieudanej konwersji?

[Jacek Omieciński 0]

Aktualizacja podmiotu: BSC z wersji: 1.7220 do wersji: 1.7404.4.5529 dnia: 2023-01-22 14:01:05
Zapisywanie informacji o początku konwersji
Modyfikacja wartości wersji struktury bazy z 1.7220 na 1.7221
Wartość wersji została zmodyfikowana
Zastosowano do podmiotu skrypt: C:\Program Files (x86)\InsERT\InsERT GT\Skrypty\skrypt1.7221_1.7300.enc
Nie powiodło się wykonanie polecenia:
ALTER TABLE dok__Dokument ALTER COLUMN dok_NumerKSeF varchar(64) COLLATE Polish_CI_AS NULL

ALTER TABLE dok__Dokument ALTER COLUMN dok_DoNumerKSeF varchar(64) COLLATE Polish_CI_AS NULL

ALTER TABLE dok__Dokument ALTER COLUMN dok_SesjaKSeF varchar(64) COLLATE Polish_CI_AS NULL

ALTER TABLE dok__Dokument ALTER COLUMN dok_IdPrzetwarzaniaKSeF varchar(64) COLLATE Polish_CI_AS NULL

ALTER TABLE ksef_Faktury ALTER COLUMN ksef_Numer varchar(256) COLLATE Polish_CI_AS NULL

ALTER TABLE ksef_Faktury ALTER COLUMN ksef_Kontrahent varchar(256) COLLATE Polish_CI_AS NULL

ALTER TABLE ksef_Sesja ALTER COLUMN ksefs_SessionId varchar(64) COLLATE Polish_CI_AS NOT NULL
Błąd 0x80040E14: The index 'missing_index_50006_5' is dependent on column 'dok_NumerKSeF'.
The index 'missing_index_50006_5' is dependent on column 'dok_NumerKSeF'.ALTER TABLE ALTER COLUMN dok_NumerKSeF failed because one or more objects access this column.Aktualizacja podmiotu nie powiodła się: 0x80040e14: The index 'missing_index_50006_5' is dependent on column 'dok_NumerKSeF'.
Przywrócenie podmiotu powiodło się.

[Paweł B 20]

Nie zakładaliście przypadkiem własnych indeksów? Na to wskazuje log.

 

Takie polecenie SQL:
drop index missing_index_50006_5 on dbo.dok__dokument

powinno pomóc, chyba że macie więcej takich własnych indeksów.

 

 

[Daniel Kozłowski 1 171]

16 godzin temu, Daniel Kozłowski napisał:

Dla jasności / potwierdzenia, że to ta sama przyczyna można było zamieścić log z konwersji.

Czyli jednak inna przyczyna... Przy opisie problemów z konwersją bazy danych wypadałoby wspomnieć o modyfikacjach struktury bazy danych...  

[Jacek Omieciński 0]

18 godzin temu, Andrzej Kubik napisał:

Zawsze może Pan odinstalować 1.74, zainstalować 1.72 i działać bez konwersji, w międzyczasie np znajdując serwisanta, który załatwi sprawę.

Zainstalowałem 1,72

[Jacek Omieciński 0]

26 minut temu, Paweł B napisał:

Nie zakładaliście przypadkiem własnych indeksów? Na to wskazuje log.

 

Takie polecenie SQL:
drop index missing_index_50006_5 on dbo.dok__dokument

powinno pomóc, chyba że macie więcej takich własnych indeksów.

 

 

Nic nie robiliśmy z bazą

[Andrzej Kubik 1 099]

5 minut temu, Jacek Omieciński napisał:

Nic nie robiliśmy z bazą

No to wszystko wskazuje na cud! 😉

I na pewno nikt, nigdy nie instalował żadnego dodatku do GT (nawet na próbę, zaraz potem odinstalowanego)?

[Jacek Omieciński 0]

Subiekt jest zainstalowany na serwerze zewnętrznym, do którego tylko ja mam dostęp.

Więc żadnych dodatków nie instalowaliśmy...

W sobotę zainstalowałem najnowszą wersję programu pobraną ze strony.

Przy aktualizacji naszej bazy pojawił się problem z jej konwersją do 1.74.

Teraz odinstalowałem wersję 1.74 i zainstalowałem 1.72 i na niej musimy pracować.

Mam nadzieję, że Insert poradzi sobie z naszym problemem, oficjalne zgłoszenie otrzymali...

[Andrzej Kubik 1 099]

6 minut temu, Jacek Omieciński napisał:

Teraz odinstalowałem wersję 1.74 i zainstalowałem 1.72 i na niej musimy pracować.

Nie, to Pan wybrał taki sposób pracy, w którym rozwiązywanie problemów trwa tak długo.

7 minut temu, Jacek Omieciński napisał:

Mam nadzieję, że Insert poradzi sobie z naszym problemem, oficjalne zgłoszenie otrzymali...

Powodzenia i wyłączam się.

[Paweł B 20]

7 minut temu, Jacek Omieciński napisał:

Subiekt jest zainstalowany na serwerze zewnętrznym, do którego tylko ja mam dostęp.

Więc żadnych dodatków nie instalowaliśmy...

Problem nie jest po stronie programu Insertu tylko po stronie waszej bazy, która została zmodyfikowana. Log jasno wskazuje, że został założony dodatkowy indeks, który blokuje proces konwersji. Ktoś lub coś go założyło, "sam" się nie dodał. Skoro Pan tego nie zrobił to trzeba zapytać waszego usługodawcę czy na waszej bazie pracuje jakieś narzędzie do automatycznego zakładania indeksów - nazwa indeksu to sugeruje. Usunięcie niefabrycznych indeksów powinno załatwić sprawę.

[Jacek Omieciński 0]

Dziękuję za wiadomość.

Spróbuję to ustalić.

Do tej pory (jakieś 15 lat) nie mieliśmy takiego przypadku.

W sumie, samo się nic nie robi... Może było coś zainstalowane przez lata, coś co do tej pory nic nie robiło a po ostatniej aktualizacji na 1.72 utworzyło jakiś wiersz.

Pytanie jak to bezpiecznie usunąć aby się nie okazało, że o czymś innym ktoś zapomniał i cała baza leży.

[Paweł B 20]

Kojarzę tylko jedną sytuacje, w której usunięcie indeksu może coś "zepsuć": jak ktoś użył "index hint" w zapytaniu. Wtedy zapytanie korzystające z usuniętego indeksu przestanie działać przez co jest to bardzo rzadko stosowane. Z tego co wiem, żadne fabryczne zapytania insertowskie nie korzystają z takich wynalazków.

 

A tak poza tym to przed usunięciem indeksów można sobie wyeksportować ich definicje do pliku i je przywrócić potem.

[Daniel Kozłowski 1 171]

7 godzin temu, Jacek Omieciński napisał:

Subiekt jest zainstalowany na serwerze zewnętrznym, do którego tylko ja mam dostęp.

Jest Pan jedynym użytkownikiem programu, gdyż za chwilę pojawia się liczba mnoga:

7 godzin temu, Jacek Omieciński napisał:

Więc żadnych dodatków nie instalowaliśmy...

--

7 godzin temu, Jacek Omieciński napisał:

W sumie, samo się nic nie robi... Może było coś zainstalowane przez lata, coś co do tej pory nic nie robiło a po ostatniej aktualizacji na 1.72 utworzyło jakiś wiersz.

Nie, to raczej stało się nie dawno, gdyż dotyczy kolumny związanej z KSeF'em, a nazwa indeksu sugeruje wykorzystanie narzędzi do optymalizacji bazy danych.