"no index" i "Invalid token Error Code: 23"

[problem]

W wyniku awarii zasilania (UPS-a) podczas aktualizacji PPS'a, mam teraz taki komunikat: "invalid request BLR offset 833 there is no index EPD_PAC_FK for table EPD Invalid token Error Code: 23". Co ciekawe, w wyniku różnego rodzaju działań naprawczych, udało się ograniczyć występowanie tego komunikatu do pojawiania się podczas próby filtrowania świadczeń w module rejestracja. Rzecz jasna kombinowałem już z isql.exe, bo doszedłem do wniosku że po prostu brak jest tego indeksu - niestety bez rezultatu. We FlameRobinie zauważyłem że ten indeks jest, tyle że podobnie jak trzy inne, nieaktywny. Próby aktywowania we FlameRobinie nie dały efektu, zakończyły się komunikatem: "violation of FOREIGN KEY constraint "". Wiem że zawsze mogę zapłacić KAMSOFT'owi, jednak może ktoś zna "domowe" rozwiązanie problemu? Rzecz jasna, w starszej wersji nie było tego problemu i jak przywrócę program to komunikatu nie ma, jest za to info o nowszej wersji bazy danych.

[Piotr29]

A ponowna aktualizacja nie załatwia problemu?

[problem]

A ponowna aktualizacja nie załatwia problemu?

niestety nie.

[bart]

A ponowna aktualizacja nie załatwia problemu?

niestety nie.

Spróbuj odpalić załączony skrypt (wykonuje backup i restore bazy)
w lokalizacji bazy (oczywiście najpierw kopia fizyczna wyłączonej bazy)
jako parametr podając nazwę bazy bez rozszerzenia (np. ~\napraw.bat kspps )

Jeśli to nie pomoże to pozostaje "ręczne" szukanie brakujących elementów klucza  EPD_PAC_FK
 w tabelach EPD i PAC np. można wykonać takie zapytanie:
 SELECT E.* FROM EPD E WHERE NOT EXISTS (SELECT NULL FROM PAC P WHERE P.NPAC = E.NPAC AND P.NINS=E.NINS_PAC )

[problem]

Spróbuj odpalić załączony skrypt

Niestety nie pomogło, gbak zwrócił błąd: "cannot commit index RPT_PAC_FK" i tradycyjnie: "violation of FOREIGN KEY constraint RPT_PAC_FK on table RPT" oraz "Foreign key reference target does not exist". Spróbuję te zapytanie, pochwalę się wynikami Swoją drogą to zapytanie nie przyszło mi do głowy... Ogromne dzięki za podpowiedź i zaangażowanie.

[bart]

Spróbuj odpalić załączony skrypt

Niestety nie pomogło, gbak zwrócił błąd: "cannot commit index RPT_PAC_FK" i tradycyjnie: "violation of FOREIGN KEY constraint RPT_PAC_FK on table RPT" oraz "Foreign key reference target does not exist". Spróbuję te zapytanie, pochwalę się wynikami Swoją drogą to zapytanie nie przyszło mi do głowy... Ogromne dzięki za podpowiedź i zaangażowanie.

Zwracam uwagę, że tym razem komunikat dotyczył innego indexu , z innej tabeli - RPT - natomiast powiązanego
też z tabelą PAC, więc coś mi podpowiada, że to wpisy w tabeli pacjentów PAC (lub ich brak) są powodem problemów

[problem]

generalnie mam problem z czterema indeksami (RPT_PAC_FK, PUP_PAC_FK, EPD_PAC_FK, DKL_PAC_FK) i wszystkie są powiązane z tabelą PAC (NINS_PAC,NPAC), czyli tam jest problem. Niestety nie rozumiem za bardzo podanego zapytania (dlaczego E.* skoro tabela to EPD, skad E w EPD E, P w P.NPAC czy P.NINS itp.) i nie mogę sklecić czegoś co da mi wyniki na tabeli PAC. FlameRobin pokazał mi jeden rekord z niewłaściwymi danymi, jednak jakakolwiek próba zmiany tych danych nie daje efektu, uparcie pamięta te dane. Myślałem już aby wyrzucić cały rekord, ale ponieważ tych rekordów jest kilka tys. to takich kwiatków może być więcej a po drugie znowu składnia zapytania się kłania...

[bart]

W moim zapytaniu bazuje na EPD, bo szukam to czego nie mogę znaleźć w tabeli PAC - może to być brakujące ID pacjenta, albo cały rekord dlatego nie szukam tego w bazie PAC (no bo trudno szukać czegoś czego nie ma ;-) )
Klucz EPD_PAC_FK wiąże dane w EPD z tabelą PAC (a nie odwrotnie)

Czyli szukam rekordów w bazie EPD (E.*) dla których nie znajduję rekordów bazie PAC (P)
o tym samym id pacjenta (P.NPAC ) co zapisany w bazie EPD (E.NPAC) (no i tym samym numerze instalacji)

Napisz  dokładniej co znalazł Flamerobin i po jaki zapytaniu i jak próbujesz to poprawić to może coś ci będzie
można doradzić.   

[problem]

zapytanie: "SELECT a.NINS, a.NPAC, a.PESL, a.IMIE, a.NAZW, a.DATU, a.PLEC, a.NKRJ, a.UPRE, a.LGIW, a.KODP, a.NMSC, a.MISC, a.NGMN, a.GMIN, a.NPOW, a.NWOJ, a.TELE, a.NOKC, a.NRKC, a.NPAC_OPK, a.NUPR, a.NKUZ, a.DWKU, a.UWAG, a.NOPR, a.NOPR_TWO, a.DAKT, a.DTWO, a.AKTW, a.NCON, a.NDDT, a.NINS_OPK, a.IBIO, a.NKNT, a.IPAC, a.OPSL, a.NRDZ, a.ZKDP, a.ZMSC, a.ZNMS, a.ZNGM, a.ZGMN, a.ZPOW, a.ZWOJ, a.NAZ2, a.IMI2, a.NZRD, a.ZTEL, a.KRTK, a.NRKR, a.NWRD, a.NIUU, a.OSOZ, a.CHIP, a.WINF, a.NINS_MWU, a.NMWU, a.NZPR, a.OSTR, a.DZGN, a.REGN, a.ZAWD, a.WKSZ, a.PCZT, a.ZPCZ, a.NZPC, a.ZNPC, a.WRST, a.WAGA, a.PWRZ, a.KSIM, a.IOSZ, a.IODM, a.IINT, a.ULIC, a.NRDM, a.NRLK, a.ZULC, a.ZNDM, a.ZNLK, a.TPLG
FROM PAC a" daje wszystkie rekordy, po ręcznym szukaniu znalazłem rekord w którym NINS zawierał wartość "-2" a NPAC "0", nazwisko "DANYCH", imię "BRAK" a reszta to null-e. Sądziłem że to zasługa tego rekordu (takiego NPAC nie ma żaden z rekordów w tabeli: RPT, PUP, EPD, DKL ) i z poziomu FlameRobina usunąłem go - niestety to nie pomogło. Zapytanie SELECT E.* FROM EPD E WHERE NOT EXISTS (SELECT NULL FROM PAC P WHERE P.NPAC = E.NPAC AND P.NINS=E.NINS_PAC ) daje 196 rekordów ale w polach NPAC i NINS_PAC wszystko wydaje się być w porządku a skoro są to rekordy których NPAC nie ma w tabeli PAC to pozostaje pytanie: dopisać je? jak? całe rekordy? usunąć te 196 rekordów? Jak znaleźć dane tych pacjentów?

[bart]

Może masz kopie bazy z  przed momentu padnięcia wówczas można by pokombinować
i uzupełniać braki, ale to już zajęcie bardziej zaawansowane.
Samodzielnie raczej nic nie usuwaj, bo możesz sobie narobić jeszcze większych kłopotów.
Chyba bez kontaktu z serwisantem się nie obędzie.

[PiotrSz]

masakra tak bazę rozpier^&#..
podobnie jak bart proponuje zaprzestać kombinacji na własną rękę bo to może tylko pogorszyć sprawę!
nie znamy do końca budowy bazy i powiązań między tabelami

czy naprawdę, naprawdę nie zrobiłeś kopii bazy przed aktualizacją programu ?
ja się już nauczyłem przy Kamsofcie, że przed każdą aktualizacją robię kopię bazy i programu żebym miał do czego wrócić jakby się przypadkiem coś zwaliło ..
dawniej miałem większą paranoję i najpierw robiłem aktualizację na kopii bazy na wirtualce, żeby zobaczyć czy nic się nie psuje ale teraz już baza za duża i brak czasu ..
teraz jeżeli mogę to czekam aż ktoś inny potestuje nową wersję i jak nie ma błędów to aktualizuje dopiero
i w ten sposób tkwię teraz na 2012.01.0.1 bo wszystkie nowsze opisujecie takimi problemami że głowa boli :-/
chyba czas napisać do Kamsoftu o co kaman bo chyba jakichś stażystów bez nadzoru zatrudnili w marcu i od tego czasu się wszystko sypie :-/

BTW sprawdźcie sobie czy/ile macie pozycji w kolejce oczekujących ze statusem NIEOKREŚLONY (zamiast STABILNY/PILNY) .. kolejny babol wczoraj mi wyszedł (ale możliwe, że nowsze wersje PPSa mają to poprawione)

pozdrawiam

[problem]

Komputer był tak skonfigurowany że kopia bazy robiła się przy uruchamianiu a w ramach "naprawy" problemu komputer był kilka razy restartowany (przez pielęgniarki) i kopia się nadpisała... Dzięki temu mam tylko starą kopię. Wiem, to błąd, ale teraz już za późno niestety... A sposób aktualizacji Piotra też staram się stosować, niestety zdarzają się "samodzielni" świadczeniodawcy którzy wolą sami i dopiero jak coś się sypie to dzwonią... Faktem jest też, że szczególnie wersja 2.1 jest fatalna, ci stażyści chyba są początkujący Nieokreślonych w kolejce nie stwierdziłem jak na razie. Przyszło mi do głowy żeby wprowadzić jakiegoś pacjenta NN, zobaczyć w tabeli PAC jaki ma NPAC i taki numer wpisać w tych 196 rekordach - co o tym myślicie?

[bart]

<..> Przyszło mi do głowy żeby wprowadzić jakiegoś pacjenta NN, zobaczyć w tabeli PAC jaki ma NPAC i taki numer wpisać w tych 196 rekordach - co o tym myślicie?

Nie radzę ;-)  ... i nie każ mi tego tłumaczyć ...

[problem]

Myślę że sprawa jest zamknięta, KAMSOFT potwierdził, że baza jest uszkodzona w stopniu uniemożliwiającym naprawę.

[PiotrSz]

spróbuj jeszcze zapytać tutaj
http://www.ka-med.com.pl/firebird

pozdrawiam