Temat: Naprawa "uszkodzonej" bazy danych - problem przy...

Witajcie,
problem z bazą ujawnił się przy próbie podniesienia wersji oprogramowania do najwyższej - aktualnej wersji wf-maga. Wersja z której przechodzę to 7.60.8.

Widzę problemy z indeksami produktów, których za nic w programie nie mogę zmienić. W miejscu indeksu program zapisał w bazie numery w "(" i tak mam katalog produktu o numerze (16586) itd.

Dodatkowo w bazie znajdowały się nie zakończone dokumenty - wszystkie zostały z bazy usunięte.

Dodatkowa kontrola z poziomu programu kończy pracę programu błędem i komunikatem:

Wystąpił błąd An inconsistency was detected during an internal operation in database 'PHUKASTA'(ID:5) on page (1:59127). Please contact technical support. Reference number 4. w funkcji Kontrola i naprawa spójności stanu rezerwacji i zamówień (kod I)

Analiza bazy z poziomu Microsoft SQL Management Studio Express wykazuje błędy:
[ dla szukających w poszczególnych wątkach rozwiązań składnia zapytania:

use twojabazadanych
go
dbcc checkdb

]

Msg 8928, Level 16, State 1, Line 1
Object ID 1412200081, index ID 17, partition ID 72057594386186240, alloc unit ID 72057594390315008 (type In-row data): Page (1:57514) could not be processed. See other errors for details.
Msg 8944, Level 16, State 13, Line 1
Table error: Object ID 1412200081, index ID 17, partition ID 72057594386186240, alloc unit ID 72057594390315008 (type In-row data), page (1:57514), row 8. Test (ColumnOffsets <= (nextRec - pRec)) failed. Values are 1053 and 29.
Msg 8944, Level 16, State 13, Line 1
Table error: Object ID 1412200081, index ID 17, partition ID 72057594386186240, alloc unit ID 72057594390315008 (type In-row data), page (1:57514), row 8. Test (ColumnOffsets <= (nextRec - pRec)) failed. Values are 1053 and 29.

Msg 8928, Level 16, State 2, Line 1
Object ID 1881773761, index ID 21, partition ID 72057594395885568, alloc unit ID 72057594400014336 (type In-row data): Page (1:45232) could not be processed. See other errors for details.
Msg 8944, Level 16, State 12, Line 1
Table error: Object ID 1881773761, index ID 21, partition ID 72057594395885568, alloc unit ID 72057594400014336 (type In-row data), page (1:45232), row 188. Test (ColumnOffsets <= (nextRec - pRec)) failed. Values are 19 and 4.
Msg 8944, Level 16, State 12, Line 1
Table error: Object ID 1881773761, index ID 21, partition ID 72057594395885568, alloc unit ID 72057594400014336 (type In-row data), page (1:45232), row 188. Test (ColumnOffsets <= (nextRec - pRec)) failed. Values are 19 and 4.

i jeśli chodzi o chwilę obecną - stoję.

Postaram się przywrócić bazę na lokalny komputer z archiwizacji, zmienić oprogramowanie na nowsze i uruchomić narzędzia z najnowszej wersji oprogramowania.

Temat: Naprawa "uszkodzonej" bazy danych - problem przy...

... czasem odpowiedzi serwisu stanowczo przekraczają moje umiejętności pojmowania. Najprawdopodobniej ma Pan uszkodzoną bazę. Proszę wykonać Bilans otwarcie i pracować na nowej.

Temat: Naprawa "uszkodzonej" bazy danych - problem przy...

Nowa wersja programu nic Panu nie zmieni, komunikat jest jasny i nie pochodzi z programu tylko jak Pan zauważył z serwera bazy danych - baza danych jest fizycznie uszkodzona

An inconsistency was detected during an internal operation in database 'PHUKASTA'(ID:5) on page (1:59127).

Może Pan próbować naprawiać tą bazę danych (na poziomie SQL Server) ale po 1 nie wiadomo co zawiera ta feralna strona danych mogło być na niej ileś informacji, które po naprawie mogą być nie do odzyskania a jaki ma to później wpływ na spójność informacji w systemie to nikt na to pytanie nie odpowie bo to jak wróżenie z fusów.

Sądząc po informacjach jakie Pan umieścił (wiele niezatwierdzonych dokumentów) mogę się tylko domyślać, że dosyć często się zdarzało, że program nie był prawidłowo zamykany a ubijany był proces albo następowało wyłączanie / restartowanie systemu podczas pracy. Jeśli już tak wnikliwie samodzielnie Pan dokonuje analizy to proponuję także w systemie sprawdzić spójność dysku twardego bo może się okazać, że on lub pamięć RAM jest przyczyną tego błędu i zaraz na innej bazie on się również pojawi.

Temat: Naprawa "uszkodzonej" bazy danych - problem przy...

Dziękuję za odpowiedź.

Przechodzę na windows 2012 i inną maszynę na xeon. W sumie zastanawiam się nad tym w jaki sposób przenieść rozrachunki do Nowej bazy.

Wracając do problemu obsługi serwisowej:
Niestety dość często zdarza się, iż wersja 7 oprogramowania po prostu traci połączenie z serwerem ( ms sql 2005 express + wss2003). Nadmienić należy, iż dość długą niemoc serwisu w sprawie zrywania połączenia z bazą danych nie udało się wytłumaczyć użytkownikowi do dnia dzisiejszego.

Wspomniał Pan o ilości niezatwierdzonych dokumentów - oczywiście, powstawały w sytuacjach zerwania w/w połączenia. Błędy w bazie, po wnikliwej analizie backapów i notatek dotyczących pracy z programem również powstawały w momentach zerwania połączenia. W dniu wczorajszym otrzymałem podpowiedź co do ewentualnych błędów dysku, które mają być powodem problemów z bazą. Poświęciłem kilka godzin - niestety ani obecny dysk ani poprzedni na którym pracowała baza nie zawierają błędów ... :(

Ciśnie się w tym momencie pytanie - jeśli błędy w bazie pochodzą z czasów w których oprogramowanie niestety samoistnie powodowało problemy, dlaczego za naprawę bazy ( naprawę która podobno nie jest możliwa ) ma płacić klient ?

Zastanawialiście się Państwo dlaczego tak wielu przedsiębiorców nie zakupuje aktualizacji oprogramowania ? Może przez niewystarczające podejście do zgłaszanych problemów ? WFMAG to nie system ERP do którego wdrożenia potrzebny jest specjalista - to rozwiązanie typu: rozpakuj, zainstaluj i działaj ! Tak też powinno pracować takie oprogramowanie. W sytuacjach krytycznych, potrzebna jest rozgarnięta pomoc techniczna.

W szeregach wsparcia WAPRO tylko raz otrzymałem rzeczową odpowiedź - niestety. Problem różnic funkcjonalnych w procesie remanentu pomiędzy wersją DOS a Windows do dnia dzisiejszego nie została wyjaśniona - rozwiązana.

Wracając do uszkodzonej bazy. Dzisiaj dalej kombinuję - jeśli wiedza i samozaparcie w temacie pozwolą rozwiązać ten problem, chętnie podzielę się rozwiązaniem.

Temat: Naprawa "uszkodzonej" bazy danych - problem przy...

Panie Krystianie, uogólnił Pan temat trochę pod siebie. Jakoś znam wiele instalacji, które nadal pracują na 7.7 i tam gdzie środowisko jest skonfigurowane prawidłowo nie ma żadnego problemu w zrywaniu połączenia.
Śpieszę także Pana poinformować iż od tamtej wersji do bieżącej w zakresie samego połączenia nic się nie zmieniło w naszych aplikacjach i ani starsi użytkownicy ani nowsi na to nie narzekają.

Kłopot połączenia to problem warstwy sieciowej środowiska i może zależeć od wielu czynników m.in:
1. Problemy czysto techniczne
- błędna konfiguracja sieci
- błędy w konfiguracji serwerów DHCP/DNS
- brak usług rozgłaszających adresację
- błędne lub zbędne protokoły poinstalowane na kliencie, które powodują, że karta sieciowa wariuje
- często spotykane poprzygniatane krzesłami kable
- sieci WIFI, które mają to do siebie, że potrafią gubić chwilowo zasięg i często są wątki na forach od zwykłych użytkowników
etc.
2. Druga kategoria to prozaiczne problemy
- chociażby włączona funkcja hibernacji systemu (nawet w komputerach stacjonarnych) - po hibernacji nie ma szans aby program transparentnie wznowił pracę sieciową bo starej sesji już zwyczajnie nie ma
- włączona funkcja oszczędzania energii na karcie sieciowej, która powoduje rozłączanie karty

Jak Pan widzi przyczyn jest wiele a serwis odpowiada za obsługę programu a nie rozwiązywanie i analizowanie błędów środowiska jakie ma u siebie klient.

Temat: Naprawa "uszkodzonej" bazy danych - problem przy...

An inconsistency was detected during an internal operation in database 'PHUKASTA'(ID:5) on page (1:59127)

To jest błąd świadczący o fizycznym uszkodzeniu pliku bazy danych, czyli pliku MDF.
SQL Server wykrył nieprawidłowości i to nie ma żadnego związku z działającym na nim programem.
Powodem powyższego najczęściej bywa nieoczekiwane/lub wymuszone wyłączenie zasilania.

Możliwość naprawy bazy danych w SQL Server jest niestety często wyłącznie stratna i nigdy nie polecana - coś z bazy na pewno zniknie, tylko nie wiadomo co.
Jedynym poprawnym rozwiązaniem jest przywrócenie z archiwum poprawnego BACKUPu.

DBCC CHECKDB ma kilka opcji naprawy:
- REPAIR_REBUILD - próba odbudowy BEZ utraty danych
- REPAIR_ALLOW_DATA_LOSS - naprawa ZE stratą na danych - na zasadzie niech się dzieje wola niebios