Re: ASSERT FAILED RowChanger already open continued
Rami Ojares / PDF-Comics Oy writes: > Let me give a bit context to how this error happens > > I keep inserting rows. > > Then an exception occurs (this exception is caused by a before trigger). > So I do a rollback. > Then I continue inserting rows. > I make one insert succesfully but then the same exception ( the > constraint violation implemented by the before trigger) happens again. > Now I don't get the exception from the trigger anymore but instead the > ASSERT FAILED exception. Hi Rami, It sounds like you know exactly how to reproduce this problem. It would be great if you could file a bug report and attach a java program so that others can reproduce it too. https://issues.apache.org/jira/browse/DERBY Thanks, -- Knut Anders
debugging java stored procedures
Hi, I was wondering whether it would be possible to debug java stored procedures loaded into the database in a jar file using the eclipse debugger. Debugging of my java stub program works fine, but when trying to step into the callable statement by which the java procedure call is envoked, eclipse says 'source not found' and offers a button to edit the source lookup path. In the dialog becoming available when using this button there is an option to add a references to 'external archives' RESIDING ON A FILE SYSTEM, but when I reference the jar file (which btw is on the file system of the Linux server to which I am connected via a samba share and which) I loaded into the database the message 'source not found' keeps reappearing. So I was wondering if there is a way to debug jar files loaded into the data base or how what I am trying to achieve can be accomplished. Thanks
Re: ASSERT FAILED RowChanger already open continued
Hejsan Knut, I will try to do that. But before that here are some further observations. The assert error occurs when using a sane build (as expected). When I used an insane build I do not get that assert error anymore but the following. Note: I am inserting here altogether around 20 000 rows so all the errors I mention happen here and ther in between. The good errors are caused by a before trigger I have created to guard the correctness of data. I get 6 good exceptions in a row and after that I get an error "The heap container with container id Container(-1, 1263513312942) is closed." This happens 3 times. After that around 40 rows are inserted with no problems. Then I get a good error. And for the next row I get "Maximum depth of nested triggers was exceeded." And from here on everytime a good error occurs this maximum depth error occurs for the following row. Now I know that my trigger does not cause other triggers to go off. My trigger only makes some sql queries and returns either 0 or throws an exception. It seems at the moment that this has something to do with the rollback causing problems for the next row. And the heap container thingy is a complete mystery to me. Coming up... A reproducible test case in jira. - rami Hi Rami, It sounds like you know exactly how to reproduce this problem. It would be great if you could file a bug report and attach a java program so that others can reproduce it too. https://issues.apache.org/jira/browse/DERBY Thanks,
Re: delete from table
One observation about what makes "DELETE FROM TBL" slow. I have two tables CATEGORY that holds 10 rows. ABSTRACT_PROGRAM that holds 2 rows each pointing with a foreign key to category table where it is defined that ON DELETE SET NULL If I delete CATEGORY table first and then ABSTRACT_PROGRAM deleting the CATEGORY table (=10 rows) takes over 30 minutes. This is caused somehow because the ABSTRACT_PROGRAMs category references have to be set to null. If I do it the other way around deleting those two tables takes something like 30 SECONDS!!! It is beyond me why it takes so long to set the CATEGORY attributes to null in ABSTRACT_PROGRAM table. It becomes even more mysterious because there is another table called IMAGE that contains images. ABSTRACT_PROGRAM table also refers to that table with a foreign key constraint. But deleting IMAGE table does not take that long at all. The only difference between these relations is that Many ABSTRACT_PROGRAMs point to ONE CATEGORY whereas ONE ABSTRACT_PROGRAM points to ONE IMAGE. this might explain it. - rami
Re: *Unrecognized* procedures
On 01/14/10 19:20, Thomas wrote:
The problem was the numbering of parameters in the registerOutParameter and the
setxxx Statement:
instead of
CallableStatement cs = conn.prepareCall("{ call APPL.\"myFunction\"(?, ?)");
cs.registerOutParameter(1, java.sql.Types.VARCHAR);
cs.setString(1, parm1);
cs.setString(2, parm2);
CallableStatement cs = conn.prepareCall("{ ? = call APPL.\"myFunction\"(?, ?)");
cs.registerOutParameter(1, java.sql.Types.VARCHAR);
cs.setString(2, parm1);
cs.setString(3, parm2);
was correct/needed.
Unfortunately there was no specific hint in any documentation I read mentioning
aspects of how the numbering needs to be done.
The API documentation for the java.sql.CallableStatement interface
(http://java.sun.com/j2se/1.5.0/docs/api/java/sql/CallableStatement.html
and http://java.sun.com/javase/6/docs/api/java/sql/CallableStatement.html)
says, "Parameters are referred to sequentially, by number, with the
first parameter being 1."
The exception appears to be INOUT parameters, as described in the
Reference Manual at
http://db.apache.org/derby/docs/dev/ref/rrefjdbc75719.html, where the
same number is used for the parameter when you register it as an out
parameter and when you set its input value. If there are any errors in
the Reference Manual topics on CallableStatement it would be helpful to
know about them. The Reference Manual topics on JDBC generally focus on
Derby-specific implementation details and other areas not covered by the
API documentation.
Hope this helps --
Kim Haase
In-Memory Apache Derby Tables not visible from "outside"
Hello:
I am writing an application which is using Derby as an in-memory DB:
Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
m_connection =
DriverManager.getConnection("jdbc:derby:memory:testdb;create=true");
In that application I am also starting the NetworkServerControl:
try {
NetworkServerControl server = new
NetworkServerControl(InetAddress.getByName("localhost"), 1527);
server.start(new PrintWriter(System.out));
} catch (Exception e) {
logger.error(e);
}
My application seems to run happily, creating and populating tables. All
the tables are well visible from the inside the app, for instance after
"CREATE TABLE" called,
this returns cnt=1:
Statement statement = m_connection.createStatement();
ResultSet rset = statement.executeQuery(
"SELECT COUNT(*) FROM SYS.SYSTABLES WHERE
TABLENAME='SAMPLE_TABLE'");
int cnt = -1;
if (rset.next()) cnt = rset.getInt(1);
However, if I try to connect with another DB client (currently I am using
Aqua Data Studio and it's configured to connect to
jdbc:derby://localhost:1527/testdb;create=true), it connects, but the
tables created in memory are not visible (while SYS tables are):
So, why could it be that in-memory tables aren't seen from the "outside"
and what can be done to make them visible?
Much appreciated!
Regards,
Pavel Bortnovskiy.
Jefferies archives and monitors outgoing and incoming e-mail. The contents of
this email, including any attachments, are confidential to the ordinary user of
the email address to which it was addressed. If you are not the addressee of
this email you may not copy, forward, disclose or otherwise use it or any part
of it in any form whatsoever. This email may be produced at the request of
regulators or in connection with civil litigation. Jefferies accepts no
liability for any errors or omissions arising as a result of transmission. Use
by other than intended recipients is prohibited. In the United Kingdom,
Jefferies operates as Jefferies International Limited; registered in England:
no. 1978621; registered office: Vintners Place, 68 Upper Thames Street, London
EC4V 3BJ. Jefferies International Limited is authorised and regulated by the
Financial Services Authority.<>
Re: In-Memory Apache Derby Tables not visible from "outside"
Pavel Bortnovskiy wrote:
Hello:
I am writing an application which is using Derby as an in-memory DB:
Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
m_connection =
DriverManager.getConnection("jdbc:derby:memory:testdb;create=true");
In that application I am also starting the NetworkServerControl:
try {
NetworkServerControl server = new
NetworkServerControl(InetAddress.getByName("localhost"), 1527);
server.start(new PrintWriter(System.out));
} catch (Exception e) {
logger.error(e);
}
My application seems to run happily, creating and populating tables.
All the tables are well visible from the inside the app, for instance
after "CREATE TABLE" called,
this returns cnt=1:
Statement statement = m_connection.createStatement();
ResultSet rset = statement.executeQuery(
"SELECT COUNT(*) FROM SYS.SYSTABLES WHERE
TABLENAME='SAMPLE_TABLE'");
int cnt = -1;
if (rset.next()) cnt = rset.getInt(1);
However, if I try to connect with another DB client (currently I am
using Aqua Data Studio and it's configured to connect to
jdbc:derby://localhost:1527/testdb;create=true), it connects, but the
tables created in memory are not visible (while SYS tables are):
[ snip - image ]
So, why could it be that in-memory tables aren't seen from the
"outside" and what can be done to make them visible?
Hi Pavel,
From a quick look at the code snippets you posted, it seems to me you
are not connecting to the same database.
Removing "create=true" from the client driver JDBC connection URL should
demonstrate that.
To use an in-memory database with the client driver (or a data source),
you have to use the following URL:
jdbc:derby://localhost:1527/memory:testdb (or for instance
jdbc:derby://myhost:1527/memory:/absolute/path/to/my/testdb)
I agree this isn't obvious, maybe some work can be done to improve it.
Also, there is some information about the in-memory back end at
http://wiki.apache.org/db-derby/InMemoryBackEndPrimer
Hope this helps,
--
Kristian
Much appreciated!
Regards,
Pavel Bortnovskiy.
Jefferies archives and monitors outgoing and incoming e-mail. The
contents of this email, including any attachments, are confidential to
the ordinary user of the email address to which it was addressed. If
you are not the addressee of this email you may not copy, forward,
disclose or otherwise use it or any part of it in any form whatsoever.
This email may be produced at the request of regulators or in
connection with civil litigation. Jefferies accepts no liability for
any errors or omissions arising as a result of transmission. Use by
other than intended recipients is prohibited. In the United Kingdom,
Jefferies operates as Jefferies International Limited; registered in
England: no. 1978621; registered office: Vintners Place, 68 Upper
Thames Street, London EC4V 3BJ. Jefferies International Limited is
authorised and regulated by the Financial Services Authority.
Re: In-Memory Apache Derby Tables not visible from "outside"
Hello, Kristian:
That was it. Thank you so much for your time and for your help.
The syntax is not that confusing, but I wish that the documentation be a
bit clearer about it...
May I ask one more, since I have you "online" and it's also an easy one
for you
(yet not too clear from the documentation).
What threading model needs to be used with the server?
I was under the impression that the NetworkServerControl is a separate
thread,
but if my app is sleeping or sitting on a breakpoint, the server isn't
responding
to JDBC requests.
If possible, can you please explain what would be the right way to
instantiate and start the server
from within the application. Maybe you may even have a snippet of code as
an example.
Thanks and have a good weekend (you've helped me get un-stuck! ;-D )
Kristian Waagan
Sent by: kristian.waa...@sun.com
01/15/2010 06:44 PM
Please respond to
"Derby Discussion"
To
Derby Discussion
cc
Subject
Re: In-Memory Apache Derby Tables not visible from "outside"
Pavel Bortnovskiy wrote:
>
> Hello:
>
> I am writing an application which is using Derby as an in-memory DB:
>
> Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
> m_connection =
> DriverManager.getConnection("jdbc:derby:memory:testdb;create=true");
>
> In that application I am also starting the NetworkServerControl:
>
> try {
> NetworkServerControl server = new
> NetworkServerControl(InetAddress.getByName("localhost"), 1527);
> server.start(new PrintWriter(System.out));
> } catch (Exception e) {
> logger.error(e);
> }
>
> My application seems to run happily, creating and populating tables.
> All the tables are well visible from the inside the app, for instance
> after "CREATE TABLE" called,
> this returns cnt=1:
>
> Statement statement = m_connection.createStatement();
> ResultSet rset = statement.executeQuery(
> "SELECT COUNT(*) FROM SYS.SYSTABLES WHERE
> TABLENAME='SAMPLE_TABLE'");
> int cnt = -1;
> if (rset.next()) cnt = rset.getInt(1);
>
> However, if I try to connect with another DB client (currently I am
> using Aqua Data Studio and it's configured to connect to
> jdbc:derby://localhost:1527/testdb;create=true), it connects, but the
> tables created in memory are not visible (while SYS tables are):
[ snip - image ]
> So, why could it be that in-memory tables aren't seen from the
> "outside" and what can be done to make them visible?
Hi Pavel,
From a quick look at the code snippets you posted, it seems to me you
are not connecting to the same database.
Removing "create=true" from the client driver JDBC connection URL should
demonstrate that.
To use an in-memory database with the client driver (or a data source),
you have to use the following URL:
jdbc:derby://localhost:1527/memory:testdb (or for instance
jdbc:derby://myhost:1527/memory:/absolute/path/to/my/testdb)
I agree this isn't obvious, maybe some work can be done to improve it.
Also, there is some information about the in-memory back end at
http://wiki.apache.org/db-derby/InMemoryBackEndPrimer
Hope this helps,
--
Kristian
>
> Much appreciated!
>
> Regards,
>
> Pavel Bortnovskiy.
>
>
>
> Jefferies archives and monitors outgoing and incoming e-mail. The
> contents of this email, including any attachments, are confidential to
> the ordinary user of the email address to which it was addressed. If
> you are not the addressee of this email you may not copy, forward,
> disclose or otherwise use it or any part of it in any form whatsoever.
> This email may be produced at the request of regulators or in
> connection with civil litigation. Jefferies accepts no liability for
> any errors or omissions arising as a result of transmission. Use by
> other than intended recipients is prohibited. In the United Kingdom,
> Jefferies operates as Jefferies International Limited; registered in
> England: no. 1978621; registered office: Vintners Place, 68 Upper
> Thames Street, London EC4V 3BJ. Jefferies International Limited is
> authorised and regulated by the Financial Services Authority.
Jefferies archives and monitors outgoing and incoming e-mail. The contents of
this email, including any attachments, are confidential to the ordinary user of
the email address to which it was addressed. If you are not the addressee of
this email you may not copy, forward, disclose or otherwise use it or any part
of it in any form whatsoever. This email may be produced at the request of
regulators or in connection with civil litigation. Jefferies accepts no
liability for any errors or omissions arising as a result of transmission. Use
by other than intended recipients is prohibited. In the United Kingdom,
Jefferies operates as Jefferies International Limited; registered in England:
no. 1978621; registered office: Vintners Place, 68 Upper Thames Street, London
EC4V 3BJ. Jefferies International Limited is au
