[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