gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Still no luck with test data


From: Richard Terry
Subject: Re: [Gnumed-devel] Still no luck with test data
Date: Thu, 9 Dec 2004 10:34:07 +1100
User-agent: KMail/1.5.4

Still not luck - attatched are what I did, messages and two log files.

Regards

Richard

Virgin tree
sh redo-max.sh

Result:

================
adding test data
log file is 
[/home/richard/gnumed/gnumed/server/bootstrap/redo-public-test_data.log]
Bootstrapping GnuMed database system...
You are about to install the following GnuMed services:
-------------------------------------------------------
service [historica] => database [gnumed] => server [localhost]
service [historica] => database [gnumed] => server [localhost]
-------------------------------------------------------
This script installs test data into an existing GnuMed database
named "gnumed". Also, the database owner "gm-dbowner" must exist
already.
Do you really want to install this database setup ?
Type yes or no: yes
==> bootstrapping service [historica] (= test data) ...
We are about to check whether we need to create the
database user who owns all GnuMed database objects.

Unless the password for this user is given in the
config file you will be asked to provide it.
If you already ran the bootstrapping script previously
please provide the same password again. Otherwise you
may get connection errors if this database user had
been created previously with a different password.

I need the password for the GnuMed database user [gm-dbowner].
Please type password:
Cannot bootstrap services.
Please check the log file for details.

Note the AMIS import comes after this and simply asks for the path to it not a 
yes/no question (I said yes to everything before this).

Next thing:

I'm an allowed postgres user to create/drop etc:
====================================================
address@hidden:~/gnumed/gnumed/server/sql/test-data$ psql -e gnumed < 
test_data-James_Kirk.sql
delete from names where
        firstnames = 'James T.'
                and
        lastnames = 'Kirk';
DELETE 1
delete from identity where
        gender = 'm'
                and
        cob = 'CA'
                and
        id in (select i_id from v_basic_person where firstnames='James T.' and 
lastnames='Kirk' and dob='1931-3-22+2:00');
DELETE 0
insert into identity (gender, dob, cob, title)
values ('m', '1931-3-22+2:00', 'CA', 'Capt.');
INSERT 918061 1
insert into names (id_identity, active, lastnames, firstnames)
values (currval('identity_id_seq'), true, 'Kirk', 'James T.');
INSERT 918062 1
insert into enum_ext_id_types (name, issuer, context)
values ('Star Fleet Staff Code', 'Star Fleet Central Staff Office', 'o');
ERROR:  Cannot insert a duplicate key into unique index 
enum_ext_id_types_name_key

================================================
On Thu, 9 Dec 2004 09:12 am, you wrote:
> Hi,
>
> I also think a completely new checkout of cvs tree and sh
> redo-public.sh, saying yes to AMIS, should work.
>
> If it doesn't, you can try, to review the error trace:
>
> As postgres user:
> cd gnumed_server_path/sql/test-data
> psql -e gnumed < test_data-James_Kirk.sql
>
> Best regard,
> carlos
>
> >BTW if one is doing the import by hand, what directory does one have to be
> > in?
> >
> >Regards
> >
> >Ricahrd
> >
> >On Thu, 9 Dec 2004 03:15 am, Karsten Hilbert wrote:
> >>>Have tried what you suggested to no avail. Note that it bombs out before
> >>>the AMIS test data (which of course I don't have anyway - this
> >>>installation script needs modifying so as if one installs test data it
> >>>dosn't request that - unless of course it is needed, in which case it
> >>>should be supplied (if possible legally).
> >>
> >>If one uses the script redo-public.sh then one will
> >>not be bothered by missing AMIS data.
> >>
> >>>I once again enclose the log file, but again, it crashes as the same
> >>>place: ===================================================
> >>>2004-12-08 17:09:07 [DATA]
> >>>(/home/richard/gnumed/gnumed/Gnumed/pycommon/gmPsql.py:address@hidden):
> >>>insert into lnk_pat2vacc_reg (fk_patient, fk_regime) values (
> >>>        currval('identity_id_seq'),
> >>>        (select pk_regime from v_vacc_regimes where regime='Tetanus
> >>>(STIKO)') )
> >>>2004-12-08 17:09:07 [ERROR]
> >>>(/home/richard/gnumed/gnumed/Gnumed/pycommon/gmPsql.py:address@hidden):
> >>>../sql/test-data/test_data-James_Kirk.sql:73: ERROR:  ExecInsert: Fail
> >>> to add null value in not null attribute fk_regime
> >>
> >>1) please make sure you have the lastest source
> >>2) this (or some variant thereof) won't work until Psql.py
> >>   gains transaction awareness which I have been unable to
> >>   provide yet
> >>3) nevertheless, one can still work around that problem:
> >>   - a bootstrap should fails on lab regression test data only
> >>   - this is harmless unless one wants to do lab regressions
> >>   - it is possible to still import that test data with:
> >>     psql -d gnumed -U gm-dbowner -f lab_regression*.sql
> >>
> >>>Interestingly if I try and run your multi-sash soap stuff now, I get a
> >>>different set of error messages -doesn't even get to the gnumed logon.
> >>
> >>Like which messages ?
> >>
> >>Karsten
> >
> >_______________________________________________
> >Gnumed-devel mailing list
> >address@hidden
> >http://lists.gnu.org/mailman/listinfo/gnumed-devel

Attachment: SOAPMultiSash.log
Description: Text Data

Attachment: redo-public-test_data.log
Description: Text Data


reply via email to

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