You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by "Williamson, Nick" <ni...@mentor.com> on 2008/01/31 12:51:28 UTC

WARNING 02000 (was "Error 00200")

Sorry - typo in the thread title. Should have been "WARNING 02000".

 

-----Original Message-----
From: Williamson, Nick 
Sent: 31 January 2008 11:50
To: 'Derby Discussion'
Subject: Error 00200

Hi all,

I'm running 10.3 and I get this message several times in the Derby log
file when my Java app deletes a row from a table that is the top table
in a fairly extensive multi-level "ON DELETE CASCADE" foreign key
hierarchy:

"No row was found for FETCH, UPDATE or DELETE; or the result of a query
is an empty table."

I assume that Derby is just telling me that, in the course of deleting
the row from the parent table, several of the child tables didn't
contain any rows that should be deleted as a result. What has surprised
me is that I couldn't reproduce the error in a very simple test case. I
created a parent table and a child table, and I linked them together by
means of a CASCADE DELETE FK on the child table. When I added a row to
the parent table, committed, deleted it and committed, Derby didn't give
me the message despite there being no matching rows in the child table.

So... I guess there's more to this than meets the eye, and there must be
a certain set of circumstances that cause this error to occur. Can
anyone advise me what the circumstances are?

TIA
Nick

Re: WARNING 02000 (was "Error 00200")

Posted by Daniel John Debrunner <dj...@apache.org>.
Stanley Bradbury wrote:

> Hi Nick -
> This seems to be an IJ issue with updates and deletes (maybe others but 
> not a SELECT statement). I only see this message using IJ - it does not 
> happen when executing the same SQL in a JDBC program and I never get the 
> message in the derby.log file.  Have you seen this message from non-IJ 
> sources?

That's only because your JDBC program is not printing warnings (from 
getWarnings method on Statement or ResultSet). IJ always prints warnings 
because it's a generic JDBC script tool and thus it shows everything it 
can about the current execution.

> Would you file a JIRA bug for this issue - it is very annoying.

http://issues.apache.org/jira/browse/DERBY-448  (closed as invalid)

Dan.

Re: WARNING 02000 (was "Error 00200")

Posted by Stanley Bradbury <St...@gmail.com>.
Williamson, Nick wrote:
> -----Original Message-----
> From: Stanley Bradbury [mailto:Stan.Bradbury@gmail.com] 
> Sent: 31 January 2008 16:04
> To: Derby Discussion
> Subject: Re: WARNING 02000 (was "Error 00200")
>
> Hi Nick -
> Warnings messages should only be displayed when the
> derby.stream.error.logSeverityLevel property is set to zero, not with
> the default setting of 40000.  Are you running with this this property
> setting ?  If not it sounds like you have encountered a bug.  I'm not
> sure how useful such a Warning is either.  Most of the time I would not
> want to be informed of this.
>
> I seem to recall having encountered this myself when reporting a
> different problem and may have a test case for it - JIRA is down at the
> moment but I will check later to see if I can find the issue. 
>
> Do you agree this is something that should be ignored (not reported)
> most of the time?
>
>
> -----------------------------------------------
>
> Hi Stanley,
>
> I was running with a value of 3 but having now set it to 40000 and
> started ij again, I still get the warning. I changed the value in
> derby.properties in the derbydbs folder, which is the folder that I'm
> invoking ij from in my OS prompt, so I'm assuming that it's picking up
> the new setting and that the database isn't overriding it with the
> setting that was in place when it was created...
>
> I agree completely that it's not something I would wish to see in the
> normal course of events... 
>
> Thanks,
> Nick
>
>   
Hi Nick -
This seems to be an IJ issue with updates and deletes (maybe others but 
not a SELECT statement). 
I only see this message using IJ - it does not happen when executing the 
same SQL in a JDBC program and I never get the message in the derby.log 
file.  Have you seen this message from non-IJ sources? 

Would you file a JIRA bug for this issue - it is very annoying.

Here's a simple test for the problem derived from the example in JIRA 
entry DERBY-1574:

java -Dderby.stream.error.logSeverityLevel=40000 org.apache.derby.tools.ij
 ij> create table t1 (i INTEGER);
  ij> create table t2 (i INTEGER);
  ij> update t1 set i = (select i FROM t2 WHERE t2.i=t1.i);
0 rows inserted/updated/deleted
WARNING 02000: No row was found for FETCH, UPDATE or DELETE; or the 
result of a query is an empty table.
   




RE: WARNING 02000 (was "Error 00200")

Posted by "Williamson, Nick" <ni...@mentor.com>.
-----Original Message-----
From: Stanley Bradbury [mailto:Stan.Bradbury@gmail.com] 
Sent: 31 January 2008 16:04
To: Derby Discussion
Subject: Re: WARNING 02000 (was "Error 00200")

Hi Nick -
Warnings messages should only be displayed when the
derby.stream.error.logSeverityLevel property is set to zero, not with
the default setting of 40000.  Are you running with this this property
setting ?  If not it sounds like you have encountered a bug.  I'm not
sure how useful such a Warning is either.  Most of the time I would not
want to be informed of this.

I seem to recall having encountered this myself when reporting a
different problem and may have a test case for it - JIRA is down at the
moment but I will check later to see if I can find the issue. 

Do you agree this is something that should be ignored (not reported)
most of the time?


-----------------------------------------------

Hi Stanley,

I was running with a value of 3 but having now set it to 40000 and
started ij again, I still get the warning. I changed the value in
derby.properties in the derbydbs folder, which is the folder that I'm
invoking ij from in my OS prompt, so I'm assuming that it's picking up
the new setting and that the database isn't overriding it with the
setting that was in place when it was created...

I agree completely that it's not something I would wish to see in the
normal course of events... 

Thanks,
Nick

Re: WARNING 02000 (was "Error 00200")

Posted by Stanley Bradbury <St...@gmail.com>.
Williamson, Nick wrote:
> Sorry - typo in the thread title. Should have been "WARNING 02000".
>
>  
>
> -----Original Message-----
> From: Williamson, Nick 
> Sent: 31 January 2008 11:50
> To: 'Derby Discussion'
> Subject: Error 00200
>
> Hi all,
>
> I'm running 10.3 and I get this message several times in the Derby log
> file when my Java app deletes a row from a table that is the top table
> in a fairly extensive multi-level "ON DELETE CASCADE" foreign key
> hierarchy:
>
> "No row was found for FETCH, UPDATE or DELETE; or the result of a query
> is an empty table."
>
> I assume that Derby is just telling me that, in the course of deleting
> the row from the parent table, several of the child tables didn'tf
> me is that I couldn't reproduce the error in a very simple test case. I
> created a parent table and a child table, and I linked them together by
> means of a CASCADE DELETE FK on the child table. When I added a row to
> the parent table, committed, deleted it and committed, Derby didn't give
> me the message despite there being no matching rows in the child table.
>
> So... I guess there's more to this than meets the eye, and there must be
> a certain set of circumstances that cause this error to occur. Can
> anyone advise me what the circumstances are?
>
> TIA
> Nick
>
>   
Hi Nick -
Warnings messages should only be displayed when the 
derby.stream.error.logSeverityLevel property is set to zero, not with 
the default setting of 40000.  Are you running with this this property 
setting ?  If not it sounds like you have encountered a bug.  I'm not 
sure how useful such a Warning is either.  Most of the time I would not 
want to be informed of this.

I seem to recall having encountered this myself when reporting a 
different problem and may have a test case for it - JIRA is down at the 
moment but I will check later to see if I can find the issue. 

Do you agree this is something that should be ignored (not reported) 
most of the time?