gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] single box SOAP functional at last - not


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] single box SOAP functional at last - not
Date: Wed, 25 Jun 2003 14:43:30 +0200
User-agent: Mutt/1.3.22.1i

> [WARN]  
> (/home/ian/gnumed/gnumed/client/python-common/gmPG.py::run_query:546): query 
> >>>insert into clin_health_issue (id_patient, description) values (%s, 
> %s);<<< (args: (3, '__default__')) failed
Seems like we are trying to insert a (second) "__default__"
health issue for patient [3].

> [WARN]  
> (/home/ian/gnumed/gnumed/client/python-common/gmPG.py::run_query:546): 
> exception type : libpq.OperationalError
> [WARN]  
> (/home/ian/gnumed/gnumed/client/python-common/gmPG.py::run_query:546): 
> exception value: ERROR:  Cannot insert a duplicate key into unique index 
> clin_health_issu_id_patient_key
Which, of course, fails, since it is constrained:
 unique(id_patient, description)

And, sure enough, the issue is already there:

> gnumed=# select * from clin_health_issue;
>  pk_audit | row_version |          modify_when          | modify_by | id | 
> id_patient | description
> ----------+-------------+-------------------------------+-----------+----+------------+-------------
>      9209 |           0 | 2003-06-25 17:55:12.606418+10 | _test-doc |  1 |    
>       3 | __default__(1 row)

> [ERROR] 
> (/home/ian/gnumed/gnumed/client/business/gmClinicalRecord.py::_create_health_issue:336):
>  cannot insert health issue [__default__] for patient [3]
> [ERROR] 
> (/home/ian/gnumed/gnumed/client/business/gmClinicalRecord.py::__load_default_health_issue:313):
>  cannot load default health issue for patient [3]
Which leads to an abort in the Clinical Record instantiation.

> And the data isn't appearing:
As it shouldn't.

> gnumed=# select * from clin_root_item;
>  pk_item | id_encounter | id_episode | narrative
> ---------+--------------+------------+-----------
> (0 rows)
> (am I looking in the right table of course?)
Yes and no. The data will appear here as well since
clin_root_item is the ancestor of clin_note (where the note is
stored) and provides the "narrative" column that clin_note
inherits and uses to store the note in. All things considered
one should look both here and in clin_note.

> I've looked at the code, you are checking to see if the health issue exists, 
> but it isn't working (the query returns no rows)
Hm. It appears to work for me.

 Can you send me the entire --debug log ? The query does not
 seem to fail in any obvious way.

 Can you
  print "result:", row
 in _create_health_issue to see what it returns ?

 Are you sure to have appropriate select rights granted on
 "clin_health_issue" for "test-doc" ?

 What happens if you connect to the public database ?

 Does psql return any rows when running that SQL command
 (as "test-doc") ?

Unfortunately (in a way), I don't see anything blatantly
wrong there ...

> I can't look into it any further as I can't seen to get a debugger running on 
> gnumed (BYW, which one's are people using?)
printk() + the log + a brain (if available and online)  :-)

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

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