[Top][All Lists]
[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