gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Strange


From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] Strange
Date: Thu, 21 Nov 2013 13:39:34 +0100
User-agent: KMail/4.11.2 (Linux/3.11.0-14-generic; KDE/4.11.2; i686; ; )

Am Donnerstag, 21. November 2013, 17:36:56 schrieb Vaibhav Banait:
> What does these errors mean and how can I solve them ?
> 
> The log file says lot about locale. I think that is not creating a
> problem other than showing error message at login.
> 
> 
> 1. ERROR     gm.db
> (d:\workplace\gnumed-server.19.0\build\pyi.win32\gnumed\outpyz1.pyz\gnumed.p
> ycommon.gmpg2::run_rw_queries() #1334): RW query failed: [
> 
> 2.  ERROR     gm.db
> (d:\workplace\gnumed-server.19.0\build\pyi.win32\gnumed\outpyz1.pyz\gnumed.p
> ycommon.gmpg2::run_rw_queries() #1337): PG error code: 23503
> 
> 
> 3. ERROR     gm.db
> (d:\workplace\gnumed-server.19.0\build\pyi.win32\gnumed\outpyz1.pyz\gnumed.p
> ycommon.gmpg2::run_rw_queries() #1339): PG error message: ERROR:  insert or
> update on table
> "substance_intake" violates foreign key constraint
> "substance_intake_fk_episode_fkey"
> DETAIL:  Key (fk_episode)=(555) is not present in table "episode".
> 2013-11-21 11:06:32  ERROR     gm.bootstrapper
> (d:\workplace\gnumed-server.19.0\build\pyi.win32\gnumed\outpyz1.pyz\logging:
> :exception() #1088): unhandled exception caught
> 
> 3. IntegrityError: insert or update on table "substance_intake"
> violates foreign key constraint "substance_intake_fk_episode_fkey"
> DETAIL:  Key (fk_episode)=(555) is not present in table "episode".
>

This shows a data integrity problem related correlation between some episode 
in some patient and data on substances the patient is taking.

This might have originated from inserting data into GNUmed 'drug database'. 
Whatever the reason might be it needs to be fixed in v18 before a successful 
upgrade to v19 makes sense.

There is a good chance the errors can be corrected but this most likely 
involves access to your database by someone who is an database expert.

I believe there could be some database experts on this list. 

>From what I know the process of fixing goes like this.

1.) Find corrupt entries
2.) relink those entry for human review
3.) review relinked entries and decide to link the to a fake entry (epidose ?) 
or delete the entry. This is because it might not be possible to restore *all* 
relationships in a database.

It always makes sense to operate on copies of the database.

Regards,
Sebastian



reply via email to

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