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 Peter Nabbefeld <Pe...@gmx.de> on 2005/06/06 08:18:49 UTC
NullPointerException in derby
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
Posted by Peter Nabbefeld <Pe...@gmx.de>.
I've just begun to use derby, so I don't currently know how to check for
the user of a table. What I'd like to know is: When I'm using a database
without default schema, just creating a schema in a different schema and
inserting a row - who's the owner? Just to make it clear, assume the
username is "user", the schema is "xuser" - will the owner be "user" or
"xuser"?
Regards,
Peter
Dyre.Tjeldvoll@Sun.COM schrieb:
> [...]
>
Re: NullPointerException in derby
Posted by Peter Nabbefeld <Pe...@gmx.de>.
Dyre.Tjeldvoll@Sun.COM schrieb:
> Peter Nabbefeld <Pe...@gmx.de> writes:
> [snip]
>
>>Just some thoughts (without knowing the source):
>>- Table creation isn't affected by the issue, while trigger creation
>>is, so both seem to get the oid from different algorithms.
>>- I guess, that the original implementation used the oid from the
>>default schema, while it has been changed later to be stored into and
>>used from the system tables.
>>- Thus, it would probably help to (1) add a method like "getOID()" to
>>the "UserObject" (don't know the class name used in derby, but there
>>should be an object representing the user); (2) use this method
>>instead of a direct access to schema or system tables.
>
>
> Well, actually Derby has something called
> LanguageConnectionContext. This class has a getDefaultSchema() method
> that returns a SchemaDescriptor. A SchemaDescriptor has getUUid()
> method that is an accessor for its oid attribute.
>
> I THINK that when creating a trigger, the code needs a "compile schema" and it
> assumes that it is safe to use the default schema, which it isn't in
> this case.
>
> So I guess you could attack this problem in (at least) two ways:
> 1) Make the trigger code use a schema that is known to be ok
> 2) Ensure that the default schema always is valid.
>
>
>>Just a guess, just because it seems to already take some time to fix
>>the bug. From my point of view, it should be easy for a derby
>>developer to fix this (but probably that is the cause for it to still
>>exist ;-) ).
>
>
> Well, I will update DERBY-85 with the info that I have.
> Perhaps the Derby experts have some ideas about this :)
>
That will at least be a first step - hopefully not the last - to fix a
half-year-old bug ;-)
Regards
Peter
Re: NullPointerException in derby
Posted by Dy...@Sun.COM.
Peter Nabbefeld <Pe...@gmx.de> writes:
[snip]
> Just some thoughts (without knowing the source):
> - Table creation isn't affected by the issue, while trigger creation
> is, so both seem to get the oid from different algorithms.
> - I guess, that the original implementation used the oid from the
> default schema, while it has been changed later to be stored into and
> used from the system tables.
> - Thus, it would probably help to (1) add a method like "getOID()" to
> the "UserObject" (don't know the class name used in derby, but there
> should be an object representing the user); (2) use this method
> instead of a direct access to schema or system tables.
Well, actually Derby has something called
LanguageConnectionContext. This class has a getDefaultSchema() method
that returns a SchemaDescriptor. A SchemaDescriptor has getUUid()
method that is an accessor for its oid attribute.
I THINK that when creating a trigger, the code needs a "compile schema" and it
assumes that it is safe to use the default schema, which it isn't in
this case.
So I guess you could attack this problem in (at least) two ways:
1) Make the trigger code use a schema that is known to be ok
2) Ensure that the default schema always is valid.
> Just a guess, just because it seems to already take some time to fix
> the bug. From my point of view, it should be easy for a derby
> developer to fix this (but probably that is the cause for it to still
> exist ;-) ).
Well, I will update DERBY-85 with the info that I have.
Perhaps the Derby experts have some ideas about this :)
--
dt
However, experience shows that for many people and many applications a
dose of paranoia is reasonable - Bjarne Stroustrup
Re: NullPointerException in derby
Posted by Peter Nabbefeld <Pe...@gmx.de>.
Peter Nabbefeld schrieb:
> Dyre.Tjeldvoll@Sun.COM schrieb:
>
>> Peter Nabbefeld <Pe...@gmx.de> 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, [...]
Just some thoughts (without knowing the source):
- Table creation isn't affected by the issue, while trigger creation is,
so both seem to get the oid from different algorithms.
- I guess, that the original implementation used the oid from the
default schema, while it has been changed later to be stored into and
used from the system tables.
- Thus, it would probably help to (1) add a method like "getOID()" to
the "UserObject" (don't know the class name used in derby, but there
should be an object representing the user); (2) use this method instead
of a direct access to schema or system tables.
Just a guess, just because it seems to already take some time to fix the
bug. From my point of view, it should be easy for a derby developer to
fix this (but probably that is the cause for it to still exist ;-) ).
Kind regards
Peter Nabbefeld
Re: NullPointerException in derby
Posted by Dy...@Sun.COM.
Peter Nabbefeld <Pe...@gmx.de> 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
Posted by Peter Nabbefeld <Pe...@gmx.de>.
Dyre.Tjeldvoll@Sun.COM schrieb:
> Peter Nabbefeld <Pe...@gmx.de> 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.
>
> <details>
> 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
> </details>
>
> 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
Posted by Peter Nabbefeld <Pe...@gmx.de>.
Dyre.Tjeldvoll@Sun.COM schrieb:
> Peter Nabbefeld <Pe...@gmx.de> 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.
>
> <details>
> 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
> </details>
>
> 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
Posted by Dy...@Sun.COM.
Peter Nabbefeld <Pe...@gmx.de> 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.
<details>
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
</details>
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
Posted by Dy...@Sun.COM.
Peter Nabbefeld <Pe...@gmx.de> 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.
<details>
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
</details>
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
Posted by Mamta Satoor <ms...@gmail.com>.
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 <Pe...@gmx.de> 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 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*
> > <Peter.Nabbefeld@gmx.de
> > <ma...@gmx.de>> 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 <http://10.0.2.2> <http://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
Posted by Peter Nabbefeld <Pe...@gmx.de>.
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*
> <Peter.Nabbefeld@gmx.de
> <ma...@gmx.de>> 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 <http://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
Posted by Mamta Satoor <ms...@gmail.com>.
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 <Pe...@gmx.de> 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 <http://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
>
>