Re: Abandoning Derby - thank you all for your support
TK, did you work on the issues with Sun Support? Or did you just rely on free resources on mailing list? Thanks. Peter On Wed, Sep 30, 2009 at 3:51 PM, T K sanokist...@yahoo.com wrote: Unfortunately, because of the unexpected growth of some tables with dead rows - due in part to unresolved bugs 691, 4054, 4055 (and even resolved ones like 4050 which we do not benefit from, i.e. we are still seeing unexpected table growth with concurrent updates) - which are hitting us very hard (e.g. estimated query costs growing into the hundreds of thousands and some in the 20+ million within days with just a dozen live rows in those tables, even when after creating otherwise-unnecessary indices for direct access), plus other issues where the compress table stored proc isn't reclaiming the dead space unless we really bring the application server down, we have to abandon Derby, and I just wanted to thank you all for your support. Regards TK
Re: Abandoning Derby - thank you all for your support
Just this list. From: Peter Ondruška peter.ondru...@gmail.com To: Derby Discussion derby-user@db.apache.org Sent: Wednesday, September 30, 2009 10:14:38 AM Subject: Re: Abandoning Derby - thank you all for your support TK, did you work on the issues with Sun Support? Or did you just rely on free resources on mailing list? Thanks. Peter On Wed, Sep 30, 2009 at 3:51 PM, T K sanokist...@yahoo.com wrote: Unfortunately, because of the unexpected growth of some tables with dead rows - due in part to unresolved bugs 691, 4054, 4055 (and even resolved ones like 4050 which we do not benefit from, i.e. we are still seeing unexpected table growth with concurrent updates) - which are hitting us very hard (e.g. estimated query costs growing into the hundreds of thousands and some in the 20+ million within days with just a dozen live rows in those tables, even when after creating otherwise-unnecessary indices for direct access), plus other issues where the compress table stored proc isn't reclaiming the dead space unless we really bring the application server down, we have to abandon Derby, and I just wanted to thank you all for your support. Regards TK
Re: SQLException: Syntax error: Encountered EOF at line 1, column 19.
I have been putting the jar file in RunProc's class path with the Eclipse
Build Path option.
Your reference in the DevGuide gives the clearest explanation of what's
going on that I have seen.
I will try to work through all of that.
Rick Hillegas-2 wrote:
One thing I notice is that the program stores the jar file in the
database but does not wire the jar file into the database classpath. If
you put the jar file on the VM's classpath, then you don't need this
step. However, if the jar file is stored in the database, then you need
to use SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY to wire the jar file into
the database classpath property derby.database.classpath. See
http://db.apache.org/derby/docs/10.5/devguide/devguide-single.html#cdevdeploy30736
Hope this helps,
-Rick
jstrunk wrote:
OK, thanks.
1. I put the parens back in ran this program to store the procedure
import java.sql.*;
public class InstallProcs {
public static void main(String args[]) {
String url =
jdbc:derby://localhost:1527/COFFEEBREAK;user=root;password=rootpw;
Connection con;
String installJar;
String createProc;
installJar = {call sqlj.install_jar( +
'file:/C:/Users/jim/DerbyWorkspace/SQLRoutines.jar',
'routines_jar', 0)};
createProc = create procedure show_suppliers()\n +
reads sql data\n +
dynamic result sets 1\n +
external name
'routines_jar:SuppliersProcs.showSuppliers'\n +
language java parameter style java;
Statement stmt;
try {
con = DriverManager.getConnection(url);
stmt = con.createStatement();
stmt.executeUpdate(installJar);
stmt.executeUpdate(createProc);
stmt.close();
con.close();
} catch(SQLException ex) {
System.err.println(SQLException: + ex.getMessage());
ex.printStackTrace();
}
}
}
2. Then I ran this program to try to execute the stored procedure
import java.sql.*;
public class RunProcs {
public static void main(String args[]) {
String url =
jdbc:derby://localhost:1527/COFFEEBREAK;user=root;password=rootpw;
Connection con;
try {
con = DriverManager.getConnection(url);
CallableStatement cstmt =con.prepareCall({call
root.show_suppliers()});
ResultSet rs = cstmt.executeQuery();
String supName = rs.getString(1);
String cofName = rs.getString(2);
System.out.println(supName + supplies + cofName);
cstmt.close();
con.close();
} catch(SQLException ex) {
System.err.println(SQLException: + ex.getMessage());
ex.printStackTrace();
}
}
}
3. RunProcs gets this error
SQLException: The class 'routines_jar:SuppliersProcs' does not exist or
is
inaccessible. This can happen if the class is not public.
java.sql.SQLSyntaxErrorException: The class 'routines_jar:SuppliersProcs'
does not exist or is inaccessible. This can happen if the class is not
public.
at
org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown
Source)
at org.apache.derby.client.am.SqlException.getSQLException(Unknown
Source)
at org.apache.derby.client.am.Connection.prepareCall(Unknown Source)
at RunProcs.main(RunProcs.java:17)
Caused by: org.apache.derby.client.am.SqlException: The class
'routines_jar:SuppliersProcs' does not exist or is inaccessible. This can
happen if the class is not public.
at org.apache.derby.client.am.Statement.completeSqlca(Unknown Source)
at
org.apache.derby.client.net.NetStatementReply.parsePrepareError(Unknown
Source)
at
org.apache.derby.client.net.NetStatementReply.parsePRPSQLSTTreply(Unknown
Source)
at org.apache.derby.client.net.NetStatementReply.readPrepare(Unknown
Source)
at org.apache.derby.client.net.StatementReply.readPrepare(Unknown
Source)
at org.apache.derby.client.net.NetStatement.readPrepare_(Unknown Source)
at org.apache.derby.client.am.Statement.readPrepare(Unknown Source)
at
org.apache.derby.client.am.PreparedStatement.readPrepareDescribeInput(Unknown
Source)
at
org.apache.derby.client.am.PreparedStatement.flowPrepareDescribeInputOutput(Unknown
Source)
at org.apache.derby.client.am.PreparedStatement.prepare(Unknown Source)
at
unsubscribe
please, unsubscribe from this list. thank you, Fabio Porto.
unsubscribe
Unsubscribe
Re: unsubscribe
To unsubscribe, you can send email to: derby-user-unsubscr...@db.apache.org Hth Myrna
unsubscribe
unsubscribe Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
