gusdev-gusdev

[Gusdev-gusdev] GBParser Failures...:(

[MICHAEL L. <lu...@cs...>]

Hello-
We have advanced a little further in our effort to get the gbparser plugin
running on a new GUS installation.  Thank you for the help so far, and we
have resolved the dependency regarding the Dots.sequencetype table, but
unfortunately we have new dependency errors.  Here a snapshot from the
generated error log:



 ------------------ entry number 1 -----------------

 SQL ERROR!! involving

    INSERT INTO DoTS.NAEntry (  created_date, row_user_id, user_write,
group_write, created_rel_ver, na_sequence_id, row_project_id, group_read,
row_group_id, other_read, na_entry_id, source_id, modification_date,
user_read, row_alg_invocation_id, other_write, version, division )
    VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, ?, ?
)
 Values: 2003-5-03 00:00:00, 6, 1, 1, 135, 1809, 2, 1, 3, 1, 205,
AY140947, 1, 138, 0, 1, INV at
/home/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 184

GUS::ObjRelP::DbiDbHandle::death('GUS::ObjRelP::DbiDbHandle=HASH(0x8afbd68)',
'^J SQL ERROR!! involving^J ^J    INSERT INTO DoTS.NAEntry (  create...')
called at /home/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 147

GUS::ObjRelP::DbiDbHandle::sqlExec('GUS::ObjRelP::DbiDbHandle=HASH(0x8afbd68)',
'GUS::ObjRelP::DbiDbHandle::st=HASH(0x8f3e0ec)', 'ARRAY(0x8f3c990)', '^J
INSERT INTO DoTS.NAEntry (  created_date, row_user_id, user...') called at
/home/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 674

GUS::ObjRelP::DbiRow::quote_and_insert('GUS::Model::DoTS::NAEntry=HASH(0x8d72bf0)',
'HASH(0x8f3c810)') called at /home/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm
line 621

GUS::ObjRelP::DbiRow::insert('GUS::Model::DoTS::NAEntry=HASH(0x8d72bf0)')
called at /home/gus_home/lib/perl/GUS/Model/GusRow.pm line 1677

GUS::Model::GusRow::submit('GUS::Model::DoTS::NAEntry=HASH(0x8d72bf0)',
undef, 1) called at /home/gus_home/lib/perl/GUS/Model/GusRow.pm line 1765

GUS::Model::GusRow::submitChildrenInClass('GUS::Model::DoTS::ExternalNASequence=HASH(0x8d6b500)',
'GUS::Model::DoTS::NAEntry') called at
/home/gus_home/lib/perl/GUS/Model/GusRow.pm line 1746

GUS::Model::GusRow::submitAllChildren('GUS::Model::DoTS::ExternalNASequence=HASH(0x8d6b500)')
called at /home/gus_home/lib/perl/GUS/Model/GusRow.pm line 1684

GUS::Model::GusRow::submit('GUS::Model::DoTS::ExternalNASequence=HASH(0x8d6b500)')
called at /home/gus_home/lib/perl/GUS/Common/Plugin/GBParser.pm line 284

GUS::Common::Plugin::GBParser::processEntry('GUS::Common::Plugin::GBParser=HASH(0x84be838)',
'CBIL::Bio::GenBank::ArrayStream=HASH(0x8ccac48)') called at
/home/gus_home/lib/perl/GUS/Common/Plugin/GBParser.pm line 185
	eval {...} called at
/home/gus_home/lib/perl/GUS/Common/Plugin/GBParser.pm line 184

GUS::Common::Plugin::GBParser::run('GUS::Common::Plugin::GBParser=HASH(0x84be838)',
'HASH(0x8c60dc8)') called at
/home/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 389
	eval {...} called at
/home/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 385

GUS::PluginMgr::GusApplication::doMajorMode_Run('GUS::PluginMgr::GusApplication=HASH(0x80fbb0c)',
'GUS::Common::Plugin::GBParser') called at
/home/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 284

GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr::GusApplication=HASH(0x80fbb0c)',
'GUS::Common::Plugin::GBParser') called at
/home/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 193

GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr::GusApplication=HASH(0x80fbb0c)',
'ARRAY(0x8105130)') called at /home/gus_home/bin/ga line 11


Thank you...

Michael Luchtan
http://www.cs.uga.edu/~luchtan

Re: [Gusdev-gusdev] GBParser Failures...:(

[Steve F. <st...@pc...>]

michael-

look in the log that captures stdout for sql errors on or near line 144 
of DbDbiHandle.pm

that was the main clue last time.

steve

MICHAEL LUCHTAN wrote:

>Hello-
>We have advanced a little further in our effort to get the gbparser plugin
>running on a new GUS installation.  Thank you for the help so far, and we
>have resolved the dependency regarding the Dots.sequencetype table, but
>unfortunately we have new dependency errors.  Here a snapshot from the
>generated error log:
>
>
>
> ------------------ entry number 1 -----------------
>
> SQL ERROR!! involving
>
>    INSERT INTO DoTS.NAEntry (  created_date, row_user_id, user_write,
>group_write, created_rel_ver, na_sequence_id, row_project_id, group_read,
>row_group_id, other_read, na_entry_id, source_id, modification_date,
>user_read, row_alg_invocation_id, other_write, version, division )
>    VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, ?, ?
>)
> Values: 2003-5-03 00:00:00, 6, 1, 1, 135, 1809, 2, 1, 3, 1, 205,
>AY140947, 1, 138, 0, 1, INV at
>/home/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 184
>
>GUS::ObjRelP::DbiDbHandle::death('GUS::ObjRelP::DbiDbHandle=HASH(0x8afbd68)',
>'^J SQL ERROR!! involving^J ^J    INSERT INTO DoTS.NAEntry (  create...')
>called at /home/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 147
>
>GUS::ObjRelP::DbiDbHandle::sqlExec('GUS::ObjRelP::DbiDbHandle=HASH(0x8afbd68)',
>'GUS::ObjRelP::DbiDbHandle::st=HASH(0x8f3e0ec)', 'ARRAY(0x8f3c990)', '^J
>INSERT INTO DoTS.NAEntry (  created_date, row_user_id, user...') called at
>/home/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 674
>
>GUS::ObjRelP::DbiRow::quote_and_insert('GUS::Model::DoTS::NAEntry=HASH(0x8d72bf0)',
>'HASH(0x8f3c810)') called at /home/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm
>line 621
>
>GUS::ObjRelP::DbiRow::insert('GUS::Model::DoTS::NAEntry=HASH(0x8d72bf0)')
>called at /home/gus_home/lib/perl/GUS/Model/GusRow.pm line 1677
>
>GUS::Model::GusRow::submit('GUS::Model::DoTS::NAEntry=HASH(0x8d72bf0)',
>undef, 1) called at /home/gus_home/lib/perl/GUS/Model/GusRow.pm line 1765
>
>GUS::Model::GusRow::submitChildrenInClass('GUS::Model::DoTS::ExternalNASequence=HASH(0x8d6b500)',
>'GUS::Model::DoTS::NAEntry') called at
>/home/gus_home/lib/perl/GUS/Model/GusRow.pm line 1746
>
>GUS::Model::GusRow::submitAllChildren('GUS::Model::DoTS::ExternalNASequence=HASH(0x8d6b500)')
>called at /home/gus_home/lib/perl/GUS/Model/GusRow.pm line 1684
>
>GUS::Model::GusRow::submit('GUS::Model::DoTS::ExternalNASequence=HASH(0x8d6b500)')
>called at /home/gus_home/lib/perl/GUS/Common/Plugin/GBParser.pm line 284
>
>GUS::Common::Plugin::GBParser::processEntry('GUS::Common::Plugin::GBParser=HASH(0x84be838)',
>'CBIL::Bio::GenBank::ArrayStream=HASH(0x8ccac48)') called at
>/home/gus_home/lib/perl/GUS/Common/Plugin/GBParser.pm line 185
>	eval {...} called at
>/home/gus_home/lib/perl/GUS/Common/Plugin/GBParser.pm line 184
>
>GUS::Common::Plugin::GBParser::run('GUS::Common::Plugin::GBParser=HASH(0x84be838)',
>'HASH(0x8c60dc8)') called at
>/home/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 389
>	eval {...} called at
>/home/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 385
>
>GUS::PluginMgr::GusApplication::doMajorMode_Run('GUS::PluginMgr::GusApplication=HASH(0x80fbb0c)',
>'GUS::Common::Plugin::GBParser') called at
>/home/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 284
>
>GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr::GusApplication=HASH(0x80fbb0c)',
>'GUS::Common::Plugin::GBParser') called at
>/home/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 193
>
>GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr::GusApplication=HASH(0x80fbb0c)',
>'ARRAY(0x8105130)') called at /home/gus_home/bin/ga line 11
>
>
>Thank you...
>
>Michael Luchtan
>http://www.cs.uga.edu/~luchtan
>
>
>
>
>-------------------------------------------------------
>Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
>The only event dedicated to issues related to Linux enterprise solutions
>www.enterpriselinuxforum.com
>
>_______________________________________________
>Gusdev-gusdev mailing list
>Gus...@li...
>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>  
>

Re: [Gusdev-gusdev] GBParser Failures...:(

[MICHAEL L. <lu...@cs...>]

Hello Steve--

Here is the first occurence of the dbdbihandle error:
Inserting:
Table: NAEntry
	created_date: [2003-5-03 00:00:00]   <--------
	row_user_id: [6]
	user_write: [1]
	group_write: [1]
	created_rel_ver: [135]
	na_sequence_id: [1911]
	row_project_id: [2]
	group_read: [1]
	row_group_id: [3]
	other_read: [1]
	source_id: [AY140947]
	modification_date: [SYSDATE]
	user_read: [1]
	row_alg_invocation_id: [139]
	other_write: [0]
	version: [1]
	division: [INV]
DBD::Oracle::st execute failed: ORA-01861: literal does not match format
string (DBD ERROR: OCIStmtExecute) at
/home/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 144, <GEN0> line
74.

On the sql prompt we checked the dots.NAentry table, which is this:
SQL> describe dots.naentry;
 Name                                      Null?    Type
 ----------------------------------------- --------
----------------------------
 NA_ENTRY_ID                               NOT NULL NUMBER(10)
 NA_SEQUENCE_ID                            NOT NULL NUMBER(10)
 SOURCE_ID                                 NOT NULL VARCHAR2(15)
 STATUS                                             VARCHAR2(12)
 DIVISION                                           VARCHAR2(15)
 VERSION                                            NUMBER(12)
 NID                                                VARCHAR2(15)
 CREATED_DATE                                       DATE
 CREATED_REL_VER                                    NUMBER(5)
 UPDATE_DATE                                        DATE
 UPDATE_REL_VER                                     NUMBER(5)
 MODIFICATION_DATE                         NOT NULL DATE
 USER_READ                                 NOT NULL NUMBER(1)
 USER_WRITE                                NOT NULL NUMBER(1)
 GROUP_READ                                NOT NULL NUMBER(1)
 GROUP_WRITE                               NOT NULL NUMBER(1)
 OTHER_READ                                NOT NULL NUMBER(1)
 OTHER_WRITE                               NOT NULL NUMBER(1)
 ROW_USER_ID                               NOT NULL NUMBER(12)
 ROW_GROUP_ID                              NOT NULL NUMBER(3)
 ROW_PROJECT_ID                            NOT NULL NUMBER(3)
 ROW_ALG_INVOCATION_ID                     NOT NULL NUMBER(12)


We are guessing that the type mismatch is with the created_date attribute,
which for some reason the parser is attempting to enter in the wrong
format.  Thanks,


Michael Luchtan
http://www.cs.uga.edu/~luchtan


On Tue, 13 May 2003, Steve Fischer wrote:

> michael-
>
> look in the log that captures stdout for sql errors on or near line 144
> of DbDbiHandle.pm
>
> that was the main clue last time.
>
> steve
>
> MICHAEL LUCHTAN wrote:
>
> >Hello-
> >We have advanced a little further in our effort to get the gbparser plugin
> >running on a new GUS installation.  Thank you for the help so far, and we
> >have resolved the dependency regarding the Dots.sequencetype table, but
> >unfortunately we have new dependency errors.  Here a snapshot from the
> >generated error log:
> >
> >
> >
> > ------------------ entry number 1 -----------------
> >
> > SQL ERROR!! involving
> >
> >    INSERT INTO DoTS.NAEntry (  created_date, row_user_id, user_write,
> >group_write, created_rel_ver, na_sequence_id, row_project_id, group_read,
> >row_group_id, other_read, na_entry_id, source_id, modification_date,
> >user_read, row_alg_invocation_id, other_write, version, division )
> >    VALUES   (  ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, SYSDATE, ?, ?, ?, ?, ?
> >)
> > Values: 2003-5-03 00:00:00, 6, 1, 1, 135, 1809, 2, 1, 3, 1, 205,
> >AY140947, 1, 138, 0, 1, INV at
> >/home/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 184
> >
> >GUS::ObjRelP::DbiDbHandle::death('GUS::ObjRelP::DbiDbHandle=HASH(0x8afbd68)',
> >'^J SQL ERROR!! involving^J ^J    INSERT INTO DoTS.NAEntry (  create...')
> >called at /home/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 147
> >
> >GUS::ObjRelP::DbiDbHandle::sqlExec('GUS::ObjRelP::DbiDbHandle=HASH(0x8afbd68)',
> >'GUS::ObjRelP::DbiDbHandle::st=HASH(0x8f3e0ec)', 'ARRAY(0x8f3c990)', '^J
> >INSERT INTO DoTS.NAEntry (  created_date, row_user_id, user...') called at
> >/home/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm line 674
> >
> >GUS::ObjRelP::DbiRow::quote_and_insert('GUS::Model::DoTS::NAEntry=HASH(0x8d72bf0)',
> >'HASH(0x8f3c810)') called at /home/gus_home/lib/perl/GUS/ObjRelP/DbiRow.pm
> >line 621
> >
> >GUS::ObjRelP::DbiRow::insert('GUS::Model::DoTS::NAEntry=HASH(0x8d72bf0)')
> >called at /home/gus_home/lib/perl/GUS/Model/GusRow.pm line 1677
> >
> >GUS::Model::GusRow::submit('GUS::Model::DoTS::NAEntry=HASH(0x8d72bf0)',
> >undef, 1) called at /home/gus_home/lib/perl/GUS/Model/GusRow.pm line 1765
> >
> >GUS::Model::GusRow::submitChildrenInClass('GUS::Model::DoTS::ExternalNASequence=HASH(0x8d6b500)',
> >'GUS::Model::DoTS::NAEntry') called at
> >/home/gus_home/lib/perl/GUS/Model/GusRow.pm line 1746
> >
> >GUS::Model::GusRow::submitAllChildren('GUS::Model::DoTS::ExternalNASequence=HASH(0x8d6b500)')
> >called at /home/gus_home/lib/perl/GUS/Model/GusRow.pm line 1684
> >
> >GUS::Model::GusRow::submit('GUS::Model::DoTS::ExternalNASequence=HASH(0x8d6b500)')
> >called at /home/gus_home/lib/perl/GUS/Common/Plugin/GBParser.pm line 284
> >
> >GUS::Common::Plugin::GBParser::processEntry('GUS::Common::Plugin::GBParser=HASH(0x84be838)',
> >'CBIL::Bio::GenBank::ArrayStream=HASH(0x8ccac48)') called at
> >/home/gus_home/lib/perl/GUS/Common/Plugin/GBParser.pm line 185
> >	eval {...} called at
> >/home/gus_home/lib/perl/GUS/Common/Plugin/GBParser.pm line 184
> >
> >GUS::Common::Plugin::GBParser::run('GUS::Common::Plugin::GBParser=HASH(0x84be838)',
> >'HASH(0x8c60dc8)') called at
> >/home/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 389
> >	eval {...} called at
> >/home/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 385
> >
> >GUS::PluginMgr::GusApplication::doMajorMode_Run('GUS::PluginMgr::GusApplication=HASH(0x80fbb0c)',
> >'GUS::Common::Plugin::GBParser') called at
> >/home/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 284
> >
> >GUS::PluginMgr::GusApplication::doMajorMode('GUS::PluginMgr::GusApplication=HASH(0x80fbb0c)',
> >'GUS::Common::Plugin::GBParser') called at
> >/home/gus_home/lib/perl/GUS/PluginMgr/GusApplication.pm line 193
> >
> >GUS::PluginMgr::GusApplication::parseAndRun('GUS::PluginMgr::GusApplication=HASH(0x80fbb0c)',
> >'ARRAY(0x8105130)') called at /home/gus_home/bin/ga line 11
> >
> >
> >Thank you...
> >
> >Michael Luchtan
> >http://www.cs.uga.edu/~luchtan
> >
> >
> >
> >
> >-------------------------------------------------------
> >Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> >The only event dedicated to issues related to Linux enterprise solutions
> >www.enterpriselinuxforum.com
> >
> >_______________________________________________
> >Gusdev-gusdev mailing list
> >Gus...@li...
> >https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
> >
> >
>
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>

Re: [Gusdev-gusdev] GBParser Failures...:(

[Jonathan C. <cra...@pc...>]

Michael, Steve-

MICHAEL LUCHTAN wrote:
> Here is the first occurence of the dbdbihandle error:
> Inserting:
> Table: NAEntry
> 	created_date: [2003-5-03 00:00:00]   <--------
> 	row_user_id: [6]

This is definitely a date formatting problem, and this is also a known
problem, but one that I thought had been fixed a while ago.  We use a
nonstandard default date format (NLS_DATE_FORMAT) in our Oracle instance,
namely 'YYYY-MM-DD HH24:MI:SS'.  I believe the default Oracle date format
is 'DD--MON-RR' instead.  Clearly the Perl object layer is generating
date literals of the form 'YYYY-MM-DD HH24:MI:SS'; since this does not
match the default format of your Oracle instance (your NLS_DATE_FORMAT),
an error results.

I described a simple fix for this problem when it was first identified,
and I thought it had been applied to the code, but perhaps there was some
complication that I'm forgetting.  Anyway, one solution is to continue
generating dates in a very specific format, but to use the Oracle TO_DATE
function to explicitly tell Oracle what format you're using, rather than
relying on the implicit string -> date conversion (which relies on the
NLS_DATE_FORMAT).  So for example, instead of doing the following:

insert into sample_table1 values ('2003-5-03 00:00:00');

You'd use the following SQL instead:

insert into sample_table1 values (to_date('2003-5-03 00:00:00', 'YYYY-MM-DD HH24:MI:SS'));

In the object layer this would probably mean replacing "?" in the insert/update
statement with "to_date(?, 'YYYY-MM-DD HH24:MI:SS')".  It may be that the
object layer doesn't distinguish between DATEs and strings for the purposes
of quoting, which might make this nontrivial to implement.  If so then an
alternative would be to have the object layer run the following command at
the beginning of each session:

alter session set NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS';

Jonathan