Re: NullPointerException in Derby 10.9.1.0

[Zorro]

Op 4-12-2012 23:08, Knut Anders Hatlen schreef:

Kim Haase  writes:


Should I file a doc JIRA to clarify that ALTER TABLE adds the new
column at the end?

That would be great.


It seems obvious, but perhaps we should clarify
that a programmatic attempt to change the data type of a column will
still result in the changed column being appended.

I notice it is possible to change the data type of a column using
"ALTER TABLE ALTER column-name SET DATA TYPE", but you can only change
the type to VARCHAR or VARCHAR FOR BIT DATA. Do you know why that is?

We probably only allow changing the maximum length of columns that
already are VARCHAR or VARCHAR FOR BIT DATA. Since changing the maximum
length can be done in the table meta-data without changing the stored
format of each value, that's easier to support than the general case.
For example, changing the type from INT to DOUBLE would require an
update of every row in the table, since they have different formats.
That's my guess, at least.


Hi Knut,

Thanks for looking at this.

As you described it seemed to be related to the Order By in the Select 
phrase of the bulk Insert.


Therefore I removed the Order By of the Select and now the bulk Insert 
went well.


The Order By was not necessary for my conversion.
Out of convenience I used copy/paste to the Insert statement.

I hope my issue helped to clarify the Insert procedure in Derby.

Kind regards,
Harm-Jan Zwinderman

Re: NullPointerException in Derby 10.9.1.0

[Knut Anders Hatlen]

Kim Haase  writes:

> Should I file a doc JIRA to clarify that ALTER TABLE adds the new
> column at the end?

That would be great.

> It seems obvious, but perhaps we should clarify
> that a programmatic attempt to change the data type of a column will
> still result in the changed column being appended.
>
> I notice it is possible to change the data type of a column using
> "ALTER TABLE ALTER column-name SET DATA TYPE", but you can only change
> the type to VARCHAR or VARCHAR FOR BIT DATA. Do you know why that is?

We probably only allow changing the maximum length of columns that
already are VARCHAR or VARCHAR FOR BIT DATA. Since changing the maximum
length can be done in the table meta-data without changing the stored
format of each value, that's easier to support than the general case.
For example, changing the type from INT to DOUBLE would require an
update of every row in the table, since they have different formats.
That's my guess, at least.

-- 
Knut Anders

Re: NullPointerException in Derby 10.9.1.0

[Kim Haase]

On 12/ 4/12 06:10 AM, Knut Anders Hatlen wrote:

david myers  writes:


On 03/12/12 14:12, Knut Anders Hatlen wrote:

 Zorro  writes:


 Dear All,

When doing in ij a bulk Insert into a table of my Derby database I do
get a NullPointerException.


Hi Harm-Jan,

It looks like you've come across a bug. I managed to reproduce the
NullPointerException in my environment, so I filed a bug report and
posted the steps I followed in order to reproduce it there:
https://issues.apache.org/jira/browse/DERBY-6006

Thanks for reporting the problem,

Hi Harm-Jan and Knut,

first off a bit of a long post, but I hope it may be informative...

I've just seen Knut's jira bug ([jira] (DERBY-6006)), and wonder
(having looked at the stack trace that was posted) if the '
conglomerate' error at the top of the stack is related to a problem I
experienced.

My problem can be recreated as follows


Create a table in your db (any structure will do)
programatically take one of your fields and change its data type

(from int to float for example).

 When you do this programatically the only way to do it is to...
 >  create a new 'temp' field
 >  copy the values from the original into the new
 >  drop the original table
 >  rename the 'temp' field so as you can use your table in your
 previously created routines etc...

the problem this creates is that the new 'temp' field, although for

all intents is the 'same' as the original has a different value in the
conglomerates tables.

Result:
If you have use an external process that inserts data into the table
from a select * the order of the fields has changed, and so the insert
fails as the original fields have been 'shifted' to the left.

EG: Original table field order.
field1:field2:changeTypeOfThisfield:field3:field4:field5

new field after the modification.

field1:field2:field3:field4:field5:changedTypeOfThisField

Solution:

Programatically capture the names of the fields to ensure they stay in
a 'predefined' order.

The problem seen by Harm-Jan may have an similar solution, the problem
being of course that it is now neccessary to programatically do the
insert select (rather then being able to do it directly in ij), which
seems a bit brutal.

So the reflection for Knut is: Is it possible to that internally the
engine is creating a temp / shadow table and making a mess of these
conglomerates during that process, and doing something like I have
encountered (and how to test if the conglomerates are changing in this
way)

If so my problem, which I have been considering calling a '
documentation bug' on, may be less benign and require a more involved
solution.

Of course I may be off the mark, it was seeing the 'conglomerates
error' that made me connect the 2 in my mind.

Hi David,

I think you're right that Harm-Jan's insert statement will create a
temporary table internally, in order to sort the results because of the
ORDER BY clause, and that it somehow confuses the columns. The ORDER BY
column is not referenced in the SELECT list, but it still has to be in
the temporary table so that it can be sorted. This may confuse the
insertion logic, especially since ORDER BY in INSERT statements is
fairly new functionality, and some corners of the old code may not be
prepared for it.

I don't expect a fix for this bug to change what you are seeing with
SELECT *, though. Adding columns with ALTER TABLE will append the new
columns to the existing column list (I agree that the documentation
should have stated this clearly), and I think the SQL standard requires
SELECT * to use that column ordering. If a SELECT statement has to work
reliably across schema changes, it will have to use explicit column
names instead of *.



Should I file a doc JIRA to clarify that ALTER TABLE adds the new column 
at the end? It seems obvious, but perhaps we should clarify that a 
programmatic attempt to change the data type of a column will still 
result in the changed column being appended.


I notice it is possible to change the data type of a column using "ALTER 
TABLE ALTER column-name SET DATA TYPE", but you can only change the type 
to VARCHAR or VARCHAR FOR BIT DATA. Do you know why that is?


Thanks,
Kim

Re: NullPointerException in Derby 10.9.1.0

[Knut Anders Hatlen]

david myers  writes:

> On 03/12/12 14:12, Knut Anders Hatlen wrote:
>
> Zorro  writes:
>
> 
> Dear All,
>
> When doing in ij a bulk Insert into a table of my Derby database I do
> get a NullPointerException.
>
> 
> Hi Harm-Jan,
>
> It looks like you've come across a bug. I managed to reproduce the
> NullPointerException in my environment, so I filed a bug report and
> posted the steps I followed in order to reproduce it there:
> https://issues.apache.org/jira/browse/DERBY-6006
>
> Thanks for reporting the problem,
>
> Hi Harm-Jan and Knut,
>
> first off a bit of a long post, but I hope it may be informative...
>
> I've just seen Knut's jira bug ([jira] (DERBY-6006)), and wonder
> (having looked at the stack trace that was posted) if the '
> conglomerate' error at the top of the stack is related to a problem I
> experienced.
>
> My problem can be recreated as follows
>
>> Create a table in your db (any structure will do)
>> programatically take one of your fields and change its data type
> (from int to float for example).
>
> When you do this programatically the only way to do it is to...
> > create a new 'temp' field
> > copy the values from the original into the new
> > drop the original table
> > rename the 'temp' field so as you can use your table in your
> previously created routines etc...
>> the problem this creates is that the new 'temp' field, although for
> all intents is the 'same' as the original has a different value in the
> conglomerates tables.
>
> Result:
> If you have use an external process that inserts data into the table
> from a select * the order of the fields has changed, and so the insert
> fails as the original fields have been 'shifted' to the left.
>
> EG: Original table field order.
> field1:field2:changeTypeOfThisfield:field3:field4:field5
>
> new field after the modification.
>
> field1:field2:field3:field4:field5:changedTypeOfThisField
>
> Solution:
>
> Programatically capture the names of the fields to ensure they stay in
> a 'predefined' order.
>
> The problem seen by Harm-Jan may have an similar solution, the problem
> being of course that it is now neccessary to programatically do the
> insert select (rather then being able to do it directly in ij), which
> seems a bit brutal.
>
> So the reflection for Knut is: Is it possible to that internally the
> engine is creating a temp / shadow table and making a mess of these
> conglomerates during that process, and doing something like I have
> encountered (and how to test if the conglomerates are changing in this
> way)
>
> If so my problem, which I have been considering calling a '
> documentation bug' on, may be less benign and require a more involved
> solution.
>
> Of course I may be off the mark, it was seeing the 'conglomerates
> error' that made me connect the 2 in my mind.

Hi David,

I think you're right that Harm-Jan's insert statement will create a
temporary table internally, in order to sort the results because of the
ORDER BY clause, and that it somehow confuses the columns. The ORDER BY
column is not referenced in the SELECT list, but it still has to be in
the temporary table so that it can be sorted. This may confuse the
insertion logic, especially since ORDER BY in INSERT statements is
fairly new functionality, and some corners of the old code may not be
prepared for it.

I don't expect a fix for this bug to change what you are seeing with
SELECT *, though. Adding columns with ALTER TABLE will append the new
columns to the existing column list (I agree that the documentation
should have stated this clearly), and I think the SQL standard requires
SELECT * to use that column ordering. If a SELECT statement has to work
reliably across schema changes, it will have to use explicit column
names instead of *.

-- 
Knut Anders

Re: NullPointerException in Derby 10.9.1.0

[david myers]

On 03/12/12 14:12, Knut Anders Hatlen wrote:

Zorro  writes:


Dear All,

When doing in ij a bulk Insert into a table of my Derby database I do
get a NullPointerException.

Hi Harm-Jan,

It looks like you've come across a bug. I managed to reproduce the
NullPointerException in my environment, so I filed a bug report and
posted the steps I followed in order to reproduce it there:
https://issues.apache.org/jira/browse/DERBY-6006

Thanks for reporting the problem,


Hi Harm-Jan and Knut,

first off a bit of a long post, but I hope it may be informative...

I've just seen Knut's jira bug ([jira] (DERBY-6006)), and wonder (having 
looked at the stack trace that was posted) if the 'conglomerate' error 
at the top of the stack is related to a problem I experienced.


My problem can be recreated as follows

> Create a table in your db (any structure will do)
> programatically take one of your fields and change its data type 
(from int to float for example).


   When you do this programatically the only way to do it is to...
> create a new 'temp' field
> copy the values from the original into the new
> drop the original table
> rename the 'temp' field so as you can use your table in your
   previously created routines etc...

> the problem this creates is that the new 'temp' field, although for 
all intents is the 'same' as the original has a different value in the 
conglomerates tables.


Result:
If you have use an external process that inserts data into the 
table from a select * the order of the fields has changed, and so the 
insert fails as the original fields have been 'shifted' to the left.


EG: Original table field order.
field1:field2:changeTypeOfThisfield:field3:field4:field5

new field after the modification.

field1:field2:field3:field4:field5:changedTypeOfThisField

Solution:

Programatically capture the names of the fields to ensure they stay in a 
'predefined' order.


The problem seen by Harm-Jan may have an similar solution, the problem 
being of course that it is now neccessary to programatically do the 
insert select (rather then being able to do it directly in ij), which 
seems a bit brutal.


So the reflection for Knut is: Is it possible to that internally the 
engine is creating a temp / shadow table and making a mess of these 
conglomerates during that process, and doing something like I have 
encountered (and how to test if the conglomerates are changing in this way)


If so my problem, which I have been considering calling a 'documentation 
bug' on, may be less benign and require a more involved solution.


Of course I may be off the mark, it was seeing the 'conglomerates error' 
that made me connect the 2 in my mind.


David.

Re: NullPointerException in Derby 10.9.1.0

[Knut Anders Hatlen]

Zorro  writes:

> Dear All,
>
> When doing in ij a bulk Insert into a table of my Derby database I do
> get a NullPointerException.

Hi Harm-Jan,

It looks like you've come across a bug. I managed to reproduce the
NullPointerException in my environment, so I filed a bug report and
posted the steps I followed in order to reproduce it there:
https://issues.apache.org/jira/browse/DERBY-6006

Thanks for reporting the problem,

-- 
Knut Anders

RE: NullPointerException in Derby driver (from at least 10.2.2.0)

[Eric Floehr]

Jim,

Yes, I would say that is a reasonable work-around.  In our case, we
built the networking code, so we saw where the interrupt was being
handled but the flag not reset, so we were able to fix it at the source.
But barring that, resetting it prior to a derby write/commit should
work.

Regards,
Eric


> -Original Message-
> From: Jim Newsham [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 13, 2008 4:54 PM
> To: 'Derby Discussion'
> Subject: RE: NullPointerException in Derby driver (from at least
> 10.2.2.0)
> 
> 
> Thanks for the advice Eric.  It seems from DERBY-151 that calling
> Thread.interrupted() before calling commit() is a reasonable
workaround
> until the problem is fixed.  Is this your assessment?
> 
> Might also be desirable to save the result and re-interrupt afterwards
> if
> interrupt status must be preserved (which it generally should).
Though
> perhaps the same problem might be manifested in other parts of the
> driver.
> 
> Thanks,
> Jim
> 
> > -Original Message-
> > From: Eric Floehr [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, February 13, 2008 11:39 AM
> > To: Derby Discussion
> > Subject: RE: NullPointerException in Derby driver (from at least
> 10.2.2.0)
> >
> > Jim,
> >
> > That's definitely what we are seeing, and our only option was to
> restart
> > the app as well.  You should really check the interrupt, because it
> > wasn't so much that InterruptedException was thrown at your code in
> the
> > thread for us.  What was happening is the interrupt flag was getting
> set
> > down in the network layer, the interrupt was successfully handled
> there,
> > but the interrupt flag was not getting cleared.  So then, next time
> > there was a commit on the database (in a totally separate part of
the
> > code) on that thread, we had the problem.
> >
> > -Eric
> >
> > > -Original Message-
> > > From: Jim Newsham [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, February 13, 2008 2:30 PM
> > > To: 'Derby Discussion'
> > > Subject: RE: NullPointerException in Derby driver (from at least
> > > 10.2.2.0)
> > >
> > >
> > > I have been seeing this same problem (very) intermittently as
> well...
> > > just
> > > have been way too busy with other things at the time to look into
> it.
> > > When
> > > it occurs, I generally see a NullPointerException on commit, and
> > > subsequent
> > > usage of the (statement? connection? data source? not sure
exactly)
> > > gives
> > > "No current connection" errors.  Our application needs to be
> restarted
> > > to
> > > recover, so I think the data source is no longer usable.
> > >
> > > This is with embedded 10.3.2.1.  Not sure if the thread is being
> > > interrupted
> > > in this case.  I think not, but could be wrong.
> > >
> > > Jim
> > >
> > > > -Original Message-
> > > > From: Daniel Noll [mailto:[EMAIL PROTECTED]
> > > > Sent: Tuesday, February 05, 2008 6:17 PM
> > > > To: Derby Discussion
> > > > Subject: Re: NullPointerException in Derby driver (from at least
> > > 10.2.2.0)
> > > >
> > > > On Wednesday 06 February 2008 04:00:26 Eric Floehr wrote:
> > > > > All,
> > > > > I'm experiencing a NullPointerException (somewhat random)
> > > apparently
> > > > > within the Derby JDBC driver (stack trace below), and am
> wondering
> > > if
> > > > > anyone has any suggestions on finding the root cause.  I am
> using
> > > Derby
> > > > > 10.3.2.1 (though the problem also occurred on 10.2.2.0) with
an
> > > IBATIS
> > > > > front-end (version 2.3.1.700, though it also occurred with
> 2.2),
> > > using
> > > > > Derby in single-user mode (direct not via server).
> > > >
> > > > Interesting, I found exactly the same problem.  I'm not sure
> whether
> > > I
> > > > posted
> > > > about it to the list or whether I stayed quiet.
> > > >
> > > > Do you have another warning earlier in the log about the
> connection
> > > having
> > > > been closed?  The few times I've seen this, the connection has
> > > "closed
> > > > itself" (despite being embedded, and thus having no good reason
> > > to...) and
> > > > then I've seen these errors for all operations directly
> afterwards.
> > > >
> > > > Daniel
> > >
> > >
> >
> 
> 

RE: NullPointerException in Derby driver (from at least 10.2.2.0)

[Jim Newsham]

Thanks for the advice Eric.  It seems from DERBY-151 that calling
Thread.interrupted() before calling commit() is a reasonable workaround
until the problem is fixed.  Is this your assessment?

Might also be desirable to save the result and re-interrupt afterwards if
interrupt status must be preserved (which it generally should).  Though
perhaps the same problem might be manifested in other parts of the driver.

Thanks,
Jim

> -Original Message-
> From: Eric Floehr [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 13, 2008 11:39 AM
> To: Derby Discussion
> Subject: RE: NullPointerException in Derby driver (from at least 10.2.2.0)
> 
> Jim,
> 
> That's definitely what we are seeing, and our only option was to restart
> the app as well.  You should really check the interrupt, because it
> wasn't so much that InterruptedException was thrown at your code in the
> thread for us.  What was happening is the interrupt flag was getting set
> down in the network layer, the interrupt was successfully handled there,
> but the interrupt flag was not getting cleared.  So then, next time
> there was a commit on the database (in a totally separate part of the
> code) on that thread, we had the problem.
> 
> -Eric
> 
> > -Original Message-
> > From: Jim Newsham [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, February 13, 2008 2:30 PM
> > To: 'Derby Discussion'
> > Subject: RE: NullPointerException in Derby driver (from at least
> > 10.2.2.0)
> >
> >
> > I have been seeing this same problem (very) intermittently as well...
> > just
> > have been way too busy with other things at the time to look into it.
> > When
> > it occurs, I generally see a NullPointerException on commit, and
> > subsequent
> > usage of the (statement? connection? data source? not sure exactly)
> > gives
> > "No current connection" errors.  Our application needs to be restarted
> > to
> > recover, so I think the data source is no longer usable.
> >
> > This is with embedded 10.3.2.1.  Not sure if the thread is being
> > interrupted
> > in this case.  I think not, but could be wrong.
> >
> > Jim
> >
> > > -Original Message-
> > > From: Daniel Noll [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, February 05, 2008 6:17 PM
> > > To: Derby Discussion
> > > Subject: Re: NullPointerException in Derby driver (from at least
> > 10.2.2.0)
> > >
> > > On Wednesday 06 February 2008 04:00:26 Eric Floehr wrote:
> > > > All,
> > > > I'm experiencing a NullPointerException (somewhat random)
> > apparently
> > > > within the Derby JDBC driver (stack trace below), and am wondering
> > if
> > > > anyone has any suggestions on finding the root cause.  I am using
> > Derby
> > > > 10.3.2.1 (though the problem also occurred on 10.2.2.0) with an
> > IBATIS
> > > > front-end (version 2.3.1.700, though it also occurred with 2.2),
> > using
> > > > Derby in single-user mode (direct not via server).
> > >
> > > Interesting, I found exactly the same problem.  I'm not sure whether
> > I
> > > posted
> > > about it to the list or whether I stayed quiet.
> > >
> > > Do you have another warning earlier in the log about the connection
> > having
> > > been closed?  The few times I've seen this, the connection has
> > "closed
> > > itself" (despite being embedded, and thus having no good reason
> > to...) and
> > > then I've seen these errors for all operations directly afterwards.
> > >
> > > Daniel
> >
> >
> 

RE: NullPointerException in Derby driver (from at least 10.2.2.0)

[Eric Floehr]

Jim,

That's definitely what we are seeing, and our only option was to restart
the app as well.  You should really check the interrupt, because it
wasn't so much that InterruptedException was thrown at your code in the
thread for us.  What was happening is the interrupt flag was getting set
down in the network layer, the interrupt was successfully handled there,
but the interrupt flag was not getting cleared.  So then, next time
there was a commit on the database (in a totally separate part of the
code) on that thread, we had the problem.

-Eric

> -Original Message-
> From: Jim Newsham [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 13, 2008 2:30 PM
> To: 'Derby Discussion'
> Subject: RE: NullPointerException in Derby driver (from at least
> 10.2.2.0)
> 
> 
> I have been seeing this same problem (very) intermittently as well...
> just
> have been way too busy with other things at the time to look into it.
> When
> it occurs, I generally see a NullPointerException on commit, and
> subsequent
> usage of the (statement? connection? data source? not sure exactly)
> gives
> "No current connection" errors.  Our application needs to be restarted
> to
> recover, so I think the data source is no longer usable.
> 
> This is with embedded 10.3.2.1.  Not sure if the thread is being
> interrupted
> in this case.  I think not, but could be wrong.
> 
> Jim
> 
> > -Original Message-
> > From: Daniel Noll [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, February 05, 2008 6:17 PM
> > To: Derby Discussion
> > Subject: Re: NullPointerException in Derby driver (from at least
> 10.2.2.0)
> >
> > On Wednesday 06 February 2008 04:00:26 Eric Floehr wrote:
> > > All,
> > > I'm experiencing a NullPointerException (somewhat random)
> apparently
> > > within the Derby JDBC driver (stack trace below), and am wondering
> if
> > > anyone has any suggestions on finding the root cause.  I am using
> Derby
> > > 10.3.2.1 (though the problem also occurred on 10.2.2.0) with an
> IBATIS
> > > front-end (version 2.3.1.700, though it also occurred with 2.2),
> using
> > > Derby in single-user mode (direct not via server).
> >
> > Interesting, I found exactly the same problem.  I'm not sure whether
> I
> > posted
> > about it to the list or whether I stayed quiet.
> >
> > Do you have another warning earlier in the log about the connection
> having
> > been closed?  The few times I've seen this, the connection has
> "closed
> > itself" (despite being embedded, and thus having no good reason
> to...) and
> > then I've seen these errors for all operations directly afterwards.
> >
> > Daniel
> 
> 

RE: NullPointerException in Derby driver (from at least 10.2.2.0)

[Jim Newsham]

I have been seeing this same problem (very) intermittently as well... just
have been way too busy with other things at the time to look into it.  When
it occurs, I generally see a NullPointerException on commit, and subsequent
usage of the (statement? connection? data source? not sure exactly) gives
"No current connection" errors.  Our application needs to be restarted to
recover, so I think the data source is no longer usable.

This is with embedded 10.3.2.1.  Not sure if the thread is being interrupted
in this case.  I think not, but could be wrong.

Jim

> -Original Message-
> From: Daniel Noll [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 05, 2008 6:17 PM
> To: Derby Discussion
> Subject: Re: NullPointerException in Derby driver (from at least 10.2.2.0)
> 
> On Wednesday 06 February 2008 04:00:26 Eric Floehr wrote:
> > All,
> > I'm experiencing a NullPointerException (somewhat random) apparently
> > within the Derby JDBC driver (stack trace below), and am wondering if
> > anyone has any suggestions on finding the root cause.  I am using Derby
> > 10.3.2.1 (though the problem also occurred on 10.2.2.0) with an IBATIS
> > front-end (version 2.3.1.700, though it also occurred with 2.2), using
> > Derby in single-user mode (direct not via server).
> 
> Interesting, I found exactly the same problem.  I'm not sure whether I
> posted
> about it to the list or whether I stayed quiet.
> 
> Do you have another warning earlier in the log about the connection having
> been closed?  The few times I've seen this, the connection has "closed
> itself" (despite being embedded, and thus having no good reason to...) and
> then I've seen these errors for all operations directly afterwards.
> 
> Daniel

RE: NullPointerException in Derby driver (from at least 10.2.2.0)

[Eric Floehr]

Dyre,

We have done some more investigation and the issue appears triggered
when Derby does a page write on a commit on a thread which has the
interrupt flag set.  We believe that existing bug 151 is the likely root
of the issue, and we have posted our comments there.  Let me know what
you think.

https://issues.apache.org/jira/browse/DERBY-151

-Eric


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 12, 2008 6:56 AM
> To: Derby Discussion
> Subject: Re: NullPointerException in Derby driver (from at least
> 10.2.2.0)
> 
> Eric Floehr <[EMAIL PROTECTED]> writes:
> 
> > Daniel,
> >
> > Yes, we see that as well, but not always.  Following is the stack
> trace of that.  Did you ever find the solution to the problem?  Thanks
> so much!
> >
> > SQL Error code: 4
> > SQL State: 08003
> > java.sql.SQLNonTransientConnectionException: No current connection.
> > at
>
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknow
> n Source)
> > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown
> Source)
> > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown
> Source)
> > at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Unknown
> Source)
> > at
> org.apache.derby.impl.jdbc.EmbedConnection.checkIfClosed(Unknown
> Source)
> > at
> org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack(Unknown
> Source)
> > at org.apache.derby.impl.jdbc.EmbedConnection.rollback(Unknown
> Source)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source)
> > at java.lang.reflect.Method.invoke(Unknown Source)
> > at
>
com.ibatis.common.jdbc.SimpleDataSource$SimplePooledConnection.invoke(S
> impleDataSource.java:958)
> > at $Proxy5.rollback(Unknown Source)
> > at
>
com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransaction.rollback(Jdbc
> Transaction.java:72)
> > at
>
com.ibatis.sqlmap.engine.transaction.TransactionManager.end(Transaction
> Manager.java:87)
> > at
>
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.endTransaction(Sql
> MapExecutorDelegate.java:724)
> > at
>
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.endTransaction(SqlMapSe
> ssionImpl.java:176)
> > at
>
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.endTransaction(SqlMapCli
> entImpl.java:153)
> > at
>
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.autoEndTransaction
> (SqlMapExecutorDelegate.java:825)
> > at
>
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.insert(SqlMapExecu
> torDelegate.java:400)
> > at
>
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.insert(SqlMapSessionImp
> l.java:82)
> > at
>
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.insert(SqlMapClientImpl.
> java:58)
> > at com.
> > at com.
> > at com.
> > at java.lang.Thread.run(Unknown Source)
> > Caused by: java.sql.SQLException: No current connection.
> > at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
> Source)
> > at
>
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAc
> rossDRDA(Unknown Source)
> > ... 26 more
> >
> 
> Seems like a bug to me. Unless someone can point to an existing Jira
> for
> this I think it would be good to create one.
> 
> --
> dt

Re: NullPointerException in Derby driver (from at least 10.2.2.0)

[Dyre . Tjeldvoll]

Eric Floehr <[EMAIL PROTECTED]> writes:

> Daniel,
>
> Yes, we see that as well, but not always.  Following is the stack trace of 
> that.  Did you ever find the solution to the problem?  Thanks so much!
>
> SQL Error code: 4
> SQL State: 08003
> java.sql.SQLNonTransientConnectionException: No current connection.
>   at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown 
> Source)
>   at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
>   at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
>   at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Unknown Source)
>   at org.apache.derby.impl.jdbc.EmbedConnection.checkIfClosed(Unknown 
> Source)
>   at org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack(Unknown 
> Source)
>   at org.apache.derby.impl.jdbc.EmbedConnection.rollback(Unknown Source)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>   at java.lang.reflect.Method.invoke(Unknown Source)
>   at 
> com.ibatis.common.jdbc.SimpleDataSource$SimplePooledConnection.invoke(SimpleDataSource.java:958)
>   at $Proxy5.rollback(Unknown Source)
>   at 
> com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransaction.rollback(JdbcTransaction.java:72)
>   at 
> com.ibatis.sqlmap.engine.transaction.TransactionManager.end(TransactionManager.java:87)
>   at 
> com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.endTransaction(SqlMapExecutorDelegate.java:724)
>   at 
> com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.endTransaction(SqlMapSessionImpl.java:176)
>   at 
> com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.endTransaction(SqlMapClientImpl.java:153)
>   at 
> com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.autoEndTransaction(SqlMapExecutorDelegate.java:825)
>   at 
> com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.insert(SqlMapExecutorDelegate.java:400)
>   at 
> com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.insert(SqlMapSessionImpl.java:82)
>   at 
> com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.insert(SqlMapClientImpl.java:58)
>   at com.
>   at com.
>   at com.
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.sql.SQLException: No current connection.
>   at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
>   at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
>  Source)
>   ... 26 more
>

Seems like a bug to me. Unless someone can point to an existing Jira for
this I think it would be good to create one.

-- 
dt

RE: NullPointerException in Derby driver (from at least 10.2.2.0)

[Eric Floehr]

Daniel,

Yes, we see that as well, but not always.  Following is the stack trace of 
that.  Did you ever find the solution to the problem?  Thanks so much!

SQL Error code: 4
SQL State: 08003
java.sql.SQLNonTransientConnectionException: No current connection.
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.checkIfClosed(Unknown 
Source)
at org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack(Unknown 
Source)
at org.apache.derby.impl.jdbc.EmbedConnection.rollback(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
com.ibatis.common.jdbc.SimpleDataSource$SimplePooledConnection.invoke(SimpleDataSource.java:958)
at $Proxy5.rollback(Unknown Source)
at 
com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransaction.rollback(JdbcTransaction.java:72)
at 
com.ibatis.sqlmap.engine.transaction.TransactionManager.end(TransactionManager.java:87)
at 
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.endTransaction(SqlMapExecutorDelegate.java:724)
at 
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.endTransaction(SqlMapSessionImpl.java:176)
at 
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.endTransaction(SqlMapClientImpl.java:153)
at 
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.autoEndTransaction(SqlMapExecutorDelegate.java:825)
at 
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.insert(SqlMapExecutorDelegate.java:400)
at 
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.insert(SqlMapSessionImpl.java:82)
at 
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.insert(SqlMapClientImpl.java:58)
at com.
at com.
at com.
at java.lang.Thread.run(Unknown Source)
Caused by: java.sql.SQLException: No current connection.
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
 Source)
... 26 more


-Eric


> -Original Message-
> From: Daniel Noll [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 05, 2008 11:17 PM
> To: Derby Discussion
> Subject: Re: NullPointerException in Derby driver (from at least
> 10.2.2.0)
> 
> Interesting, I found exactly the same problem.  I'm not sure whether I
> posted
> about it to the list or whether I stayed quiet.
> 
> Do you have another warning earlier in the log about the connection
> having
> been closed?  The few times I've seen this, the connection has "closed
> itself" (despite being embedded, and thus having no good reason to...)
> and
> then I've seen these errors for all operations directly afterwards.
> 
> Daniel

Re: NullPointerException in Derby driver (from at least 10.2.2.0)

[Daniel Noll]

On Wednesday 06 February 2008 04:00:26 Eric Floehr wrote:
> All,
> I'm experiencing a NullPointerException (somewhat random) apparently
> within the Derby JDBC driver (stack trace below), and am wondering if
> anyone has any suggestions on finding the root cause.  I am using Derby
> 10.3.2.1 (though the problem also occurred on 10.2.2.0) with an IBATIS
> front-end (version 2.3.1.700, though it also occurred with 2.2), using
> Derby in single-user mode (direct not via server).

Interesting, I found exactly the same problem.  I'm not sure whether I posted 
about it to the list or whether I stayed quiet.

Do you have another warning earlier in the log about the connection having 
been closed?  The few times I've seen this, the connection has "closed 
itself" (despite being embedded, and thus having no good reason to...) and 
then I've seen these errors for all operations directly afterwards.

Daniel

Re: NullPointerException in Derby driver (from at least 10.2.2.0)

[Stanley Bradbury]

Eric Floehr wrote:


All,

I’m experiencing a NullPointerException (somewhat random) apparently 
within the Derby JDBC driver (stack trace below), and am wondering if 
anyone has any suggestions on finding the root cause. I am using Derby 
10.3.2.1 (though the problem also occurred on 10.2.2.0) with an IBATIS 
front-end (version 2.3.1.700, though it also occurred with 2.2), using 
Derby in single-user mode (direct not via server).


Here is the root stack trace:

Caused by: java.sql.SQLException: Java exception: ': 
java.lang.NullPointerException'.


at 
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown 
Source)


at 
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown 
Source)


... 21 more

Caused by: java.lang.NullPointerException

at 
org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown 
Source)


at 
org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown 
Source)


at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Unknown Source)

at org.apache.derby.impl.store.access.btree.OpenBTree.init(Unknown Source)

at org.apache.derby.impl.store.access.btree.BTreeScan.init(Unknown Source)

at 
org.apache.derby.impl.store.access.btree.index.B2IForwardScan.init(Unknown 
Source)


at org.apache.derby.impl.store.access.btree.index.B2I.openScan(Unknown 
Source)


at org.apache.derby.impl.store.access.RAMTransaction.openScan(Unknown 
Source)


at 
org.apache.derby.impl.store.access.RAMTransaction.openCompiledScan(Unknown 
Source)


at 
org.apache.derby.impl.sql.execute.TableScanResultSet.openScanController(Unknown 
Source)


at 
org.apache.derby.impl.sql.execute.TableScanResultSet.openScanController(Unknown 
Source)


at 
org.apache.derby.impl.sql.execute.TableScanResultSet.openCore(Unknown 
Source)


at 
org.apache.derby.impl.sql.execute.IndexRowToBaseRowResultSet.openCore(Unknown 
Source)


at 
org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown 
Source)


at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown 
Source)


... 14 more

I appreciate any help or pointers you can provide!

Thanks much!

Eric


Hi Eric -
Is there any additional information provided in the derby.log file like 
the SQL that was being processed?

Does the failure happen at the same point when it does happen?
What JVM are you using? If it is not a JVM that was platform tested 
would it be possible for you to test with one that was? You can find a 
list on this page: 
http://wiki.apache.org/db-derby/TenThreeTwoPlatformTesting

Re: NullPointerException in Derby client

[Robert Enyedi]

I filed the bug report http://issues.apache.org/jira/browse/DERBY-1774 
with detailed information on how to reproduce this right from inside ij.


Any suggestions on how to avoid this bug would be warmly welcome.

Regards,
Robert

Daniel John Debrunner wrote:

Craig L Russell wrote:

  

Hi Robert,

Please file a bug report in the Derby JIRA. Include the stack trace 
along with an ij script that creates the tables and a simple jdbc 
program that issues the query that causes the NPE.


Someone on the Derby dev team will follow up.



There is no "Derby team", Derby is an open-source community where anyone
can get involved and work on improving Derby in many ways including
fixing bugs. People work on what interests them: "fry their own fish" or
"scratch their own itch". Entering a bug may catch the interest of
someone already active in the community, but it may not, there is no
"will" about it. One sure way to get a bug fixed is to work in the
community on fixing it.

Here's an explanation of how development at Apache works:

http://db.apache.org/derby/derby_comm.html#Understand+How+Development+Works+at+Apache

The community is always ready to welcome new people.

http://wiki.apache.org/db-derby/DerbyDev

Dan.




  

Re: NullPointerException in Derby client

[Craig L Russell]

On Aug 28, 2006, at 7:17 AM, Daniel John Debrunner wrote:


Craig L Russell wrote:


Hi Robert,

Please file a bug report in the Derby JIRA. Include the stack trace
along with an ij script that creates the tables and a simple jdbc
program that issues the query that causes the NPE.

Someone on the Derby dev team will follow up.


There is no "Derby team", Derby is an open-source community where  
anyone

can get involved and work on improving Derby in many ways including
fixing bugs.


Of course, Dan has it right. What I meant by "Derby team" is the  
community of Derby contributors and developers who work on Derby. And  
if someone looks into the NPE and contributes a patch, then a Derby  
committer will have to actually apply the patch...


Craig


People work on what interests them: "fry their own fish" or
"scratch their own itch". Entering a bug may catch the interest of
someone already active in the community, but it may not, there is no
"will" about it. One sure way to get a bug fixed is to work in the
community on fixing it.

Here's an explanation of how development at Apache works:

http://db.apache.org/derby/derby_comm.html#Understand+How 
+Development+Works+at+Apache


The community is always ready to welcome new people.

http://wiki.apache.org/db-derby/DerbyDev

Dan.





Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



smime.p7s
Description: S/MIME cryptographic signature

Re: NullPointerException in Derby client

[Daniel John Debrunner]

Craig L Russell wrote:

> Hi Robert,
> 
> Please file a bug report in the Derby JIRA. Include the stack trace 
> along with an ij script that creates the tables and a simple jdbc 
> program that issues the query that causes the NPE.
>
> Someone on the Derby dev team will follow up.

There is no "Derby team", Derby is an open-source community where anyone
can get involved and work on improving Derby in many ways including
fixing bugs. People work on what interests them: "fry their own fish" or
"scratch their own itch". Entering a bug may catch the interest of
someone already active in the community, but it may not, there is no
"will" about it. One sure way to get a bug fixed is to work in the
community on fixing it.

Here's an explanation of how development at Apache works:

http://db.apache.org/derby/derby_comm.html#Understand+How+Development+Works+at+Apache

The community is always ready to welcome new people.

http://wiki.apache.org/db-derby/DerbyDev

Dan.

Re: NullPointerException in Derby client

[Craig L Russell]

Hi Robert,

Please file a bug report in the Derby JIRA. Include the stack trace  
along with an ij script that creates the tables and a simple jdbc  
program that issues the query that causes the NPE.


Someone on the Derby dev team will follow up.

Thanks,

Craig

On Aug 28, 2006, at 4:56 AM, Robert Enyedi wrote:


Hi,

I receive a NullPointerException in the Derby client when trying to  
execute a prepared statement from iBATIS. This is the stack trace:


org.apache.derby.client.am.SqlException: The exception  
'java.lang.NullPointerException' was thrown while evaluating an  
expression. SQLSTATE: XJ001: Java exception: ':  
java.lang.NullPointerException'.
   at org.apache.derby.client.am.Statement.completeSqlca 
(Statement.java:1371)
   at org.apache.derby.client.am.Statement.completeOpenQuery 
(Statement.java:1042)
   at  
org.apache.derby.client.net.NetStatementReply.parseOpenQueryFailure 
(NetStatementReply.java:503)
   at org.apache.derby.client.net.NetStatementReply.parseOPNQRYreply 
(NetStatementReply.java:226)
   at org.apache.derby.client.net.NetStatementReply.readOpenQuery 
(NetStatementReply.java:56)
   at org.apache.derby.client.net.StatementReply.readOpenQuery 
(StatementReply.java:49)
   at org.apache.derby.client.net.NetStatement.readOpenQuery_ 
(NetStatement.java:151)
   at org.apache.derby.client.am.Statement.readOpenQuery 
(Statement.java:1038)
   at org.apache.derby.client.am.PreparedStatement.flowExecute 
(PreparedStatement.java:1396)
   at org.apache.derby.client.am.PreparedStatement.executeX 
(PreparedStatement.java:893)
   at org.apache.derby.client.am.PreparedStatement.execute 
(PreparedStatement.java:884)

   at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at  
com.ibatis.common.jdbc.logging.PreparedStatementLogProxy.invoke 
(PreparedStatementLogProxy.java:62)

   at $Proxy1.execute(Unknown Source)
   at com.ibatis.sqlmap.engine.execution.SqlExecutor.executeQuery 
(SqlExecutor.java:180)
   at  
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.sqlExecute 
Query(GeneralStatement.java:205)
   at  
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQue 
ryWithCallback(GeneralStatement.java:173)
   at  
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQue 
ryForObject(GeneralStatement.java:104)
   at  
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject 
(SqlMapExecutorDelegate.java:561)
   at  
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject 
(SqlMapExecutorDelegate.java:536)
   at com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForObject 
(SqlMapSessionImpl.java:93)
   at com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryForObject 
(SqlMapClientImpl.java:70)


The SQL I'm running contains two inner joins, a WHERE and ORDER BY  
clause and two parameters. Both the parameters are in the WHERE  
clause.


I did a short test with the 10.2.1.1 beta release too, but the  
error is the same.


Any ideas on how I should deal with this internal server error?

Thanks,
Robert


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



smime.p7s
Description: S/MIME cryptographic signature

Re: NullPointerException in derby

[Dyre . Tjeldvoll]

Peter Nabbefeld <[EMAIL PROTECTED]> writes:

[snip]


> That's bad - it means, that I've to manage data, which I don't
> need. Any idea, when this bug will be fixed?

Well, I have looked at it. That's how I recognized your problem :) But
I'm afraid I'm a Derby novice, so although I have an idea about
what's going on, I can't promise a fix... :(

-- 
dt

Re: NullPointerException in derby

[Peter Nabbefeld]

[EMAIL PROTECTED] schrieb:


Peter Nabbefeld <[EMAIL PROTECTED]> writes:



Hello,

I've got the following NPE:

java.lang.NullPointerException
at
org.apache.derby.impl.sql.catalog.SYSSTATEMENTSRowFactory.makeSYSSTATEMENTSrow(Unknown
Source)
at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addSPSDescriptor(Unknown
Source)
at
org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(Unknown
Source)
at
org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(Unknown
Source)
at
org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source)
at
org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
Source)
...

My SQL statement is:
CREATE TRIGGER APPBUT_USER.EMRSZDEL AFTER DELETE ON
APPBUT_USER.EMPLOYERS FOR EACH STATEMENT MODE DB2SQL
VALUES(APPBUT_USER.TRIGGER_RESIZE('APPBUT_USER','EMPLOYERS'))

Could anybody please tell me, what's wrong with that? I'm using derby
10.0.2.2.



Looks like you are experiencing
http://issues.apache.org/jira/browse/DERBY-85



Yes, this seems to be the problem - the issue describes exactly, what I 
did :-(




I don't think this has been fixed yet, but if this is your problem you
can work around it by having a non-empty table in the default
schema. 



Looks like the oid for the default schema is null until a row is
inserted in a table in the default schema. This oid is referenced when
creating a trigger, even if that trigger doesn't touch the default schema


At least that worked for me when trying the example in
DERBY-85:

s.execute("create table itko.t1 (i int)");
// Workaround   
s.execute("create table def (i int)");

s.execute("insert into def values (0), (1), (2)");

// Example from DERBY-85
s.execute("create trigger ikto.trig1 after update on itko.t1 for each row mode 
db2sql select * from sys.systables");

[snip]



That's bad - it means, that I've to manage data, which I don't need. Any 
idea, when this bug will be fixed?


Kind regards

Peter Nabbefeld

Re: NullPointerException in derby

[Mamta Satoor]

Hi Peter,
 
I wondered if you got a chance to try what Tyre suggested in his posting. May be what you are encountering is 
http://issues.apache.org/jira/browse/DERBY-85
 
thanks,
Mamta 
On 6/6/05, Peter Nabbefeld <[EMAIL PROTECTED]> wrote:
Mamta Satoor schrieb:> Hello Peter,>> NPE is never a good news. Can you please provide a reproducible case
> which someone can use in their own environment to see the NPE? It will> make it easier to investigate the problem by others.>Hmm, I don't know, if I will be able to isolate a special test case. Is
it possible to browse the cvs? There is something missing, probably itwould give a hint to look what is the missing object.Basically, I've done the following:1. Create a database, a table, and a stored function (a reference to a
static java method).2. Create a trigger, which calls the stored functionKind regardsPeter Nabbefeld> thanks,> Mamta>>> On 6/5/05, *Peter Nabbefeld*> <
[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:>>> Hello,>> I've got the following NPE:
>> java.lang.NullPointerException> at> org.apache.derby.impl.sql.catalog.SYSSTATEMENTSRowFactory.makeSYSSTATEMENTSrow> (Unknown> Source)> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addSPSDescriptor(Unknown> Source)> at> org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(Unknown
>> Source)> at> org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(Unknown> Source)> at org.apache.derby.impl.sql.execute.MiscResultSet.open
(Unknown> Source)> at> org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown> Source)> at> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement
(Unknown> Source)> at org.apache.derby.impl.jdbc.EmbedStatement.execute (Unknown> Source)> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown> Source)
>...>> My SQL statement is:> CREATE TRIGGER APPBUT_USER.EMRSZDEL AFTER DELETE ON> APPBUT_USER.EMPLOYERS FOR EACH STATEMENT MODE DB2SQL> VALUES(APPBUT_USER.TRIGGER_RESIZE('APPBUT_USER','EMPLOYERS'))
>> Could anybody please tell me, what's wrong with that? I'm using derby> 10.0.2.2 .>> BTW: Please provide source bundles, too. It's not a good idea, if a
> user> has to install svn just to get sources for a release version (most> current version is okay, as most people who want this would most likely> also want to work actively with the source code and probably contribute
> their changes).>> Kind regards>> Peter Nabbefeld>>

Re: NullPointerException in derby

[Peter Nabbefeld]

Mamta Satoor schrieb:


Hello Peter,
 
NPE is never a good news. Can you please provide a reproducible case 
which someone can use in their own environment to see the NPE? It will 
make it easier to investigate the problem by others.
 
Hmm, I don't know, if I will be able to isolate a special test case. Is 
it possible to browse the cvs? There is something missing, probably it 
would give a hint to look what is the missing object.


Basically, I've done the following:
1. Create a database, a table, and a stored function (a reference to a 
static java method).

2. Create a trigger, which calls the stored function

Kind regards

Peter Nabbefeld



thanks,
Mamta

 
On 6/5/05, *Peter Nabbefeld* 
<[EMAIL PROTECTED] 
> wrote:



Hello,

I've got the following NPE:

java.lang.NullPointerException
at

org.apache.derby.impl.sql.catalog.SYSSTATEMENTSRowFactory.makeSYSSTATEMENTSrow
(Unknown
Source)
at

org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addSPSDescriptor(Unknown
Source)
at

org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(Unknown

Source)
at

org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(Unknown
Source)
at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown
Source)
at
org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.execute (Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
Source)
   ...

My SQL statement is:
CREATE TRIGGER APPBUT_USER.EMRSZDEL AFTER DELETE ON
APPBUT_USER.EMPLOYERS FOR EACH STATEMENT MODE DB2SQL
VALUES(APPBUT_USER.TRIGGER_RESIZE('APPBUT_USER','EMPLOYERS'))

Could anybody please tell me, what's wrong with that? I'm using derby
10.0.2.2 .

BTW: Please provide source bundles, too. It's not a good idea, if a
user
has to install svn just to get sources for a release version (most
current version is okay, as most people who want this would most likely
also want to work actively with the source code and probably contribute
their changes).

Kind regards

Peter Nabbefeld

Re: NullPointerException in derby

[Dyre . Tjeldvoll]

Peter Nabbefeld <[EMAIL PROTECTED]> writes:

> Hello,
>
> I've got the following NPE:
>
> java.lang.NullPointerException
>  at
> org.apache.derby.impl.sql.catalog.SYSSTATEMENTSRowFactory.makeSYSSTATEMENTSrow(Unknown
> Source)
>  at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addSPSDescriptor(Unknown
> Source)
>  at
> org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(Unknown
> Source)
>  at
> org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(Unknown
> Source)
>  at
> org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source)
>  at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> Source)
>  at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
>  at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
> Source)
>  at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
> Source)
>   ...
>
> My SQL statement is:
> CREATE TRIGGER APPBUT_USER.EMRSZDEL AFTER DELETE ON
> APPBUT_USER.EMPLOYERS FOR EACH STATEMENT MODE DB2SQL
> VALUES(APPBUT_USER.TRIGGER_RESIZE('APPBUT_USER','EMPLOYERS'))
>
> Could anybody please tell me, what's wrong with that? I'm using derby
> 10.0.2.2.

Looks like you are experiencing
http://issues.apache.org/jira/browse/DERBY-85

I don't think this has been fixed yet, but if this is your problem you
can work around it by having a non-empty table in the default
schema. 


Looks like the oid for the default schema is null until a row is
inserted in a table in the default schema. This oid is referenced when
creating a trigger, even if that trigger doesn't touch the default schema


At least that worked for me when trying the example in
DERBY-85:

s.execute("create table itko.t1 (i int)");
// Workaround   
s.execute("create table def (i int)");
s.execute("insert into def values (0), (1), (2)");

// Example from DERBY-85
s.execute("create trigger ikto.trig1 after update on itko.t1 for each row mode 
db2sql select * from sys.systables");

[snip]

-- 
dt

However, experience shows that for many people and many applications a
dose of paranoia is reasonable - Bjarne Stroustrup

Re: NullPointerException in derby

[Mamta Satoor]

Hello Peter,
 
NPE is never a good news. Can you please provide a reproducible case which someone can use in their own environment to see the NPE? It will make it easier to investigate the problem by others.
 
thanks,
Mamta 
On 6/5/05, Peter Nabbefeld <[EMAIL PROTECTED]> wrote:
Hello,I've got the following NPE:java.lang.NullPointerExceptionatorg.apache.derby.impl.sql.catalog.SYSSTATEMENTSRowFactory.makeSYSSTATEMENTSrow
(UnknownSource)atorg.apache.derby.impl.sql.catalog.DataDictionaryImpl.addSPSDescriptor(UnknownSource)atorg.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(Unknown
Source)atorg.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(UnknownSource)at org.apache.derby.impl.sql.execute.MiscResultSet.open(UnknownSource)
atorg.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)atorg.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)at org.apache.derby.impl.jdbc.EmbedStatement.execute
(UnknownSource)at org.apache.derby.impl.jdbc.EmbedStatement.execute(UnknownSource)   ...My SQL statement is:CREATE TRIGGER APPBUT_USER.EMRSZDEL AFTER DELETE ONAPPBUT_USER.EMPLOYERS FOR EACH STATEMENT MODE DB2SQL
VALUES(APPBUT_USER.TRIGGER_RESIZE('APPBUT_USER','EMPLOYERS'))Could anybody please tell me, what's wrong with that? I'm using derby10.0.2.2.BTW: Please provide source bundles, too. It's not a good idea, if a user
has to install svn just to get sources for a release version (mostcurrent version is okay, as most people who want this would most likelyalso want to work actively with the source code and probably contribute
their changes).Kind regardsPeter Nabbefeld