gnumed-bugs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-bugs] Error bootstrap v21 v22


From: slappinjohn
Subject: Re: [Gnumed-bugs] Error bootstrap v21 v22
Date: Sun, 15 Apr 2018 17:44:36 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

Vielen Dank für die Sonntägliche Antwort! Bei Ärzten ist halt nie
Feierabend.

Grüße aus der alten Heimat

Marc


Am 15.04.2018 um 14:35 schrieb Karsten Hilbert:
> On Sun, Apr 15, 2018 at 10:45:50AM +0200, slappinjohn wrote:
>
>> Testing in psql leads to
>>
>> select fk_stay from blobs.lnk_doc2hospital_stay where fk_document =
>> blobs.doc_med.pk
>> gnumed_v21-# ;
>> ERROR:  missing FROM-clause entry for table "doc_med"
> Das ist normal, zum Testen müßte es sein:
>
>       select fk_stay from blobs.lnk_doc2hospital_stay, blobs.doc_med where 
> fk_document = blobs.doc_med.pk;
>
>> gnumed_v21=# update blobs.doc_med set
>> gnumed_v21-#     fk_hospital_stay = (
>> gnumed_v21(#         select fk_stay from blobs.lnk_doc2hospital_stay where
>> gnumed_v21(# fk_document = blobs.doc_med.pk
>> gnumed_v21(#     )
>> gnumed_v21-# ;
>> ERROR:  column "fk_hospital_stay" of relation "doc_med" does not exist
> Das auch, denn die wird erst in v22 hinzugefügt.
>
> Das eigentliche Problem steht hier:
>
>>> Traceback (most recent call last):
>>>   File "/var/lib/gnumed/Gnumed/pycommon/gmPsql.py", line 137, in run
>>>     curs.execute(curr_cmd)
>>>   File "/usr/lib/python2.7/dist-packages/psycopg2/extras.py", line 144,
>>> in execute
>>>     return super(DictCursor, self).execute(query, vars)
>>> InternalError: UPDATE into blobs.doc_med: Sanity check failed.
>>> fk_encounter=2907 -> patient=761. fk_episode=1539 -> patient=768.
>>> KONTEXT:  PL/pgSQL function clin.trf_sanity_check_enc_epi_ins_upd() line 22 
>>> at RAISE
> Beim Upgraden der Dokumententabellen wird die innere
> Konsistenz überprüft. Dabei stellt sich heraus, daß es ein
> Dokument gibt, bei dem als Encounter die 2907 und als Episode
> die 1539 verlinkt sind. Encounter (a) und Episode (b) gehören
> aber nicht zum selben Patienten (sondern zu Patient 761 (a)
> und Patient 769 (b)).
>
> Solche Zuordnungsfehler können früher mal entstanden sein, im
> Zuge von Problemen mit dem Patientenwechsel. Daher ist mit
> hoher Wahrscheinlichkeit auch eher das Encounter falsch als
> die Episode.
>
> Man muß die Probleme erst in der v21-Datenbank beseitigen,
> ehe ein Upgrade möglich wird.
>
> Für diesen Fall habe ich ein Werkzeug eingebaut:
>
>       man gnumed
>
> für die Version 1.7.1 listet auf:
>
>
>        --tool=TOOL
>               Run the named TOOL instead of a GUI.
>
>               Currently known tools are:
>
>                    check_enc_epi_xref:  Cross-check  that 
>                                  foreign keys values in any given row of
>                                  any table carrying both of fk_episode and
>                                  fk_encounter do point to episodes and
>                                  encounters, respectively, of the very same
>                                  patient.
>
>                    export_pat_emr_structure: Export the EMR
>                                  structure (issues and episodes) of a
>                                  patient into a text file.
>
>       EXIT STATUS
>              Upon normal execution the exit status will be 0.
>
>              If an error occurred while trying to run a tool, the exit status 
> will be < 0.
>
>              If an unknown tool was requested, the exit status will be -1.
>
>              If an error occurred while a known tool was run, the exit status 
> will be < -1.
>
> Man sollte also mal
>
>       $> gnumed --debug --tool=check_enc_epi_xref
>
> laufen lassen. Das produziert dann mehrere Dateien, die
> Informationen zum Problem enthalten. Die kann man nutzen, um
> die Fehlverlinkungen in der Datenbank aufzulösen. Dann kann
> man upgraden.
>
> Karsten




reply via email to

[Prev in Thread] Current Thread [Next in Thread]