Aktualizacja z 1.6501 do 1.6600 błąd update tw__Towar set tw_OplCukrowaKofeinaKwota = 0.1

[Tomasz Ochniowski 16]

Dzień dobry,  baza Subiekt GT + Rachmistrz GT. Rozmiar bazy 608MB,  SQL 2014 Express , Windows Server 2012 R2 Foundation. Brak rozwiązań firm trzecich.

Błąd powtarzalny na 3 komputerach na których przeniosłem archiwum bazy:

 

Nie powiodło się wykonanie polecenia:
update tw__Towar set tw_OplCukrowaKofeinaKwota = 0.1

Błąd 0x80040E14: Internal error.

 

1. Nie spotkałem się nigdy z takim problemem ani żadnym tego typu przy aktualizacji bazy podmiotu.

2. Czytając inne posty na forum znalazłem jedynie podobne problemy ale wiązały się z rozwiązaniami firm trzecich

3. Nigdy z tą bazą nie było dotychczas żadnych problemów.

 

Jakieś sugestie? Czy taki problem kwalifikuje się jedynie do wysyłki bazy do serwisu Insert w ramach Telekonsultanta?

 

 

 

[Paweł Szczygieł 36]

Próbował Pan na bazie puścić skrypt ?

 

update tw__Towar set tw_OplCukrowaKofeinaKwota = 0.1

 

[Tomasz Ochniowski 16]

3 minuty temu, Paweł Szczygieł napisał:

Próbował Pan na bazie puścić skrypt ?

 

update tw__Towar set tw_OplCukrowaKofeinaKwota = 0.1

 

A no nie... nie miałem stanowiska testowego z SQL Management Studio. Doinstaluję i spróbuję?

 

[Tomasz Ochniowski 16]

6 minut temu, Tomasz Ochniowski napisał:

A no nie... nie miałem stanowiska testowego z SQL Management Studio. Doinstaluję i spróbuję?

 

Po wykonaniu update jest zgodnie z prawdą:

Invalid column name 'tw_OplCukrowaKofeinaKwota'

 

[Daniel Kozłowski 1 167]

7 minut temu, Tomasz Ochniowski napisał:

1. Nie spotkałem się nigdy z takim problemem ani żadnym tego typu przy aktualizacji bazy podmiotu.

A ja ma mam to "na co dzień".

 

7 minut temu, Tomasz Ochniowski napisał:

2. Czytając inne posty na forum znalazłem jedynie podobne problemy ale wiązały się z rozwiązaniami firm trzecich

Niestety w wielu przypadkach są to rozwiązania dodatkowe, do których użytkownicy się nie przyznają / nie pamiętają, że je instalowali - nie dawny przykład z tabelą pd__Podmiot2, która pochodziła z rozwiązania z roku 2014.

 

11 minut temu, Tomasz Ochniowski napisał:

3. Nigdy z tą bazą nie było dotychczas żadnych problemów.

Jak z problemami - nie ma ich dopóki się nie pojawią, z programami i bazami danych jest ta trudność, że problemy potrafią się ujawnić po jakimś czasie od powstania, na przykład w takim momencie jak konwersja bazy danych, która może przetwarzać dane, które nie są przetwarzane przy codziennej pracy.

 

13 minut temu, Tomasz Ochniowski napisał:

Jakieś sugestie?

Sprawdziłbym, czy baza danych nie została fizycznie uszkodzona.

 

14 minut temu, Tomasz Ochniowski napisał:

Czy taki problem kwalifikuje się jedynie do wysyłki bazy do serwisu Insert w ramach Telekonsultanta?

Oczywiście, że nie takie usługi świadczą doświadczeni serwisanci programów Insertu, więc najlepiej w takich firmach zamawiać programy.

 

11 minut temu, Paweł Szczygieł napisał:

Próbował Pan na bazie puścić skrypt ?

 

update tw__Towar set tw_OplCukrowaKofeinaKwota = 0.1

 

Ale przed konwersją jeszcze nie będzie tej kolumny, więc na pewno zakończy się błędem.

[Tomasz Ochniowski 16]

Podziałałem zgodnie z sugestią.

Sprawdzenie bazy ujawniło problem:CHECKDB found 0 allocation errors and 2 consistency errors

naprawa zgodnie z pomocą internetu: dbcc checkdb ('DB-NAME', REPAIR_REBUILD)

dała taki efekt:

DBCC results for 'xtw_Ewid'.
Repair:  Successfully deleted row in index "dbo.xtw_Ewid, IX_xtw_Ewid_2" in database "BAZA".
Repair:  Successfully inserted row in index "dbo.xtw_Ewid, IX_xtw_Ewid_2" in database "BAZA".
Table error: table 'xtw_Ewid' (ID 869630191). Data row does not have a matching index row in the index 'IX_xtw_Ewid_2' (ID 3). Possible missing or invalid keys for the index row matching:
There are 40754 rows in 324 pages for object "xtw_Ewid".
CHECKDB found 0 allocation errors and 2 consistency errors in table 'xtw_Ewid' (object ID 869630191).
CHECKDB fixed 0 allocation errors and 2 consistency errors in table 'xtw_Ewid' (object ID 869630191).

 

Po wykonaniu naprawy - aktualizacja do 1.6600 przeszła bez problemu. Dziękuje za wskazówki

[Daniel Kozłowski 1 167]

Jak widać to było "szczęśliwe uszkodzenie" bazy danych, w obszarze danych do odtworzenia (słownik InsTYNKT'u towarów) oraz była możliwa naprawa bez utraty danych, ale mogło być dużo gorzej - mogły to być ruchy magazynowe lub rozrachunki... Sprawdziły się też moje przypuszczenia - problem był już wcześniej, baza danych została uszkodzona wcześniej, a uszkodzenie to ujawniło się dopiero teraz przez konwersję. Polecam spróbować zabezpieczyć się przed takimi przypadkami na przyszłość.