Derby eating up disk space + how to trigger ReclaimSpace elegantly

2011-08-08 Thread De Meyer Tim
Hi,

We're working on a java webapp and using a derby database (v10.5) in embedded 
mode.
The first version of the application went live about 2 months ago.
The application gets used for making invoices and we also store the XML of an 
invoice document in the derby DB (input data for generating a PDF against a 
template).
Today, the database is about 1,7GB on disk.

During these 2 months, we've released some minor upgrades, including database 
migration scripts (like extra tables for new functionality).
Now we've noticed that, when we ran our latest upgrade, the database has 
suddenly shrunk to a size of 600MB.
This latest upgrade contained a migration script that dropped a no longer 
needed timestamp column on practically every table.
It's after executing this script that the shrink happened.
You can see about practically every .dat file getting touched (or rebuilt) and 
this shrinks the seg0 folder.
We did some debugging and hit suspend when the disk size started shrinking, it 
lead us to a Derby class called "ReclaimSpace".

We're afraid the database will start using up unnecessary space again soon, and 
of course, we're not going to have a similar migration script in every upgrade.
Why is derby so greedy with disk space (in our configuration)?
I'm also not sure what made the database grow in the first place. Was is just 
using the DB or was it the migration scripts from the previous releases, I 
don't know.
Is there an elegant way to configure derby to do this cleaning continuously, or 
to let our webapp instruct derby to do some cleaning?
We're launching the webapp from within a small java webstart app (we launch a 
Jetty and attach our war file), so it's even OK for us to write some java code 
to do it programmatically.

We've found this, but it's on a per table basis :-(
http://db.apache.org/derby/docs/10.1/adminguide/cadminspace21579.html
http://db.apache.org/derby/docs/10.5/ref/rrefaltertablecompress.html

By the way, as a comparison, we're running about 10 of these webapps on 
different desktop PC's.
Each webapp synchronizes its data to a server running a postgresql 9 database.
This means that this postgres database accumulates all the data of these 10 
webapps (some data is shared, so it's not times ten).
The size of this postgres DB is less than 1GB, which sounds OK against the 
600MB of one of those webapps, but not against 1,7GB for one webapp.

Any help on all of this would be more than welcome.

Kind regards,

Tim De Meyer



Derby eating up disk space + how to trigger ReclaimSpace elegantly

2011-08-08 Thread De Meyer Tim
Hi,

We're working on a java webapp and using a derby database (v10.5) in embedded 
mode.
The first version of the application went live about 2 months ago.
The application is used to make invoices and we also store the XML of an 
invoice document (input data for generating a PDF against a template).
Today, the database is about 1,7GB on disk.

During these 2 months, we've released some minor upgrades, including database 
migration scripts (like extra tables for new functionality).
Now we've noticed that, when we ran our latest upgrade, the database has 
suddenly shrunk to a size of 600MB.
This latest upgrade contained a migration script that dropped a no longer 
needed column on practically every table.
It's after executing this script that the shrink happened.
We did some debugging and hit suspend when the disk size started shrinking, it 
lead us to a Derby class called "ReclaimSpace".

The shrink was a bliss, because the customer was already complaining about the 
large size on disk :-)
We're afraid the database will start using up unnecessary space again soon, and 
of course, we're not going to have a similar migration script in every upgrade.
Is there an elegant way to configure derby to do this cleaning continuously, or 
to let our webapp instruct derby to do some cleaning?
We're launching the webapp from within a small java webstart app (we launch a 
Jetty and attach our war file), so it's even OK for us to write some java code 
to do it programmatically.

We've found this, but it's on a per table basis.
http://db.apache.org/derby/docs/10.1/adminguide/cadminspace21579.html
http://db.apache.org/derby/docs/10.5/ref/rrefaltertablecompress.html

By the way, we're running about 10 of these webapps on different desktop PC's.
Each webapp synchronizes its data to a server running a postgresql 9 database.
This means that this postgres database accumulates all the data of these 10 
webapps (some data is shared, so it's not times ten).
The size of this postgres DB is less than 1GB, which we think is surprisingly 
small compared to the derby DB for one webapp.

Any help on all of this would be more than welcome.

Kind regards,

Tim De Meyer



Re: ClassNotFoundException when deploying with apache tomcat => where to put the jar?

2011-08-08 Thread Spezifikum

Am 07.08.2011 22:25, schrieb Spezifikum:

Hi
i am using apache derby with netbeans succesfully. Local applications 
run as excpeted, but when i try to create a servlet i always get the 
error that the driver could not be loaded together with a 
ClassNotFoundException, which afaik means that the library could not 
be found.

I tried to put it in:
tomcat-7.0.19/lib, webapps/MyApp, webapps/MyApp/WEB-INF/lib, 
webapps/MyApp/WEB-INF/classes

with no success.
What am i doing wrong? Could anybody please help me?

Thanks a lot
Malte



Aaargh!

After many trials with different tomcats and lots of reading, i just 
checked once more the jar i use. I included the wrong file i.e. 
derbynet. When I instead use derby.jar everything works just fine.

This might help others who are just as - well ok, you know what i mean.

Malte


Re: Derby eating up disk space + how to trigger ReclaimSpace elegantly

2011-08-08 Thread Phil Bradley

Hi,

For what it's worth, I had an approximately similar experience
with approximately similar volumes of data on a desktop app using
Derby embedded. I introduced a daily compress of all tables using
the following command (for each table):

call SYSCS_UTIL.SYSCS_COMPRESS_TABLE('MYSCHEMA', 'MYTABLE', 0)

The schedule for this was handled at the application level rather
than the derby level. Specifically, we used quartz to do the
scheduling.

Also, as you mention, this is on a per table basis. I don't
believe there is a single command that you can use to compress
the whole database so we just use the database metadata to list
all tables and apply the procedure to each.

Regards,
Phil





On Fri, 05 Aug 2011 16:35 +0200, "De Meyer Tim"
 wrote:

  Hi,
  We're working on a java webapp and using a derby database
  (v10.5) in embedded mode.
  The first version of the application went live about 2 months
  ago.
  The application is used to make invoices and we also store the
  XML of an invoice document (input data for generating a PDF
  against a template).
  Today, the database is about 1,7GB on disk.
  During these 2 months, we've released some minor upgrades,
  including database migration scripts (like extra tables for
  new functionality).
  Now we've noticed that, when we ran our latest upgrade, the
  database has suddenly shrunk to a size of 600MB.
  This latest upgrade contained a migration script that dropped
  a no longer needed column on practically every table.
  It's after executing this script that the shrink happened.
  We did some debugging and hit suspend when the disk size
  started shrinking, it lead us to a Derby class called
  "ReclaimSpace".
  The shrink was a bliss, because the customer was already
  complaining about the large size on disk :-)
  We're afraid the database will start using up unnecessary
  space again soon, and of course, we're not going to have a
  similar migration script in every upgrade.
  Is there an elegant way to configure derby to do this cleaning
  continuously, or to let our webapp instruct derby to do some
  cleaning?
  We're launching the webapp from within a small java webstart
  app (we launch a Jetty and attach our war file), so it's even
  OK for us to write some java code to do it programmatically.
  We've found this, but it's on a per table basis.
  [1]http://db.apache.org/derby/docs/10.1/adminguide/cadminspace
  21579.html
  [2]http://db.apache.org/derby/docs/10.5/ref/rrefaltertablecomp
  ress.html
  By the way, we're running about 10 of these webapps on
  different desktop PC's.
  Each webapp synchronizes its data to a server running a
  postgresql 9 database.
  This means that this postgres database accumulates all the
  data of these 10 webapps (some data is shared, so it's not
  times ten).
  The size of this postgres DB is less than 1GB, which we think
  is surprisingly small compared to the derby DB for one webapp.
  Any help on all of this would be more than welcome.
  Kind regards,
  Tim De Meyer

References

1. http://db.apache.org/derby/docs/10.1/adminguide/cadminspace21579.html
2. http://db.apache.org/derby/docs/10.5/ref/rrefaltertablecompress.html


Re: Can't Load Embedded Driver

2011-08-08 Thread Rick Hillegas

On 8/7/11 9:54 AM, roy.mi...@comcast.net wrote:


I have been happily using Derby for two years within IntelliJ Idea, 
but have now hit a wall trying to deploy the application I developed.  
I have tried setting the path to derby.jar on the command line and/or 
in the CLASSPATH environment variable to no avail.  The embedded 
driver doesn't load; the error message is, "No suitable driver found 
for jdbc:derby:EMDatabase;create=true".  I'm under Windows XP Pro.  
Any help would be appreciated.


Roy Minet



Hi Roy,

This is almost always a CLASSPATH problem. With the same CLASSPATH, try 
the following experiment:


java org.apache.derby.jdbc.EmbeddedDriver

If the CLASSPATH is good, you should see this error:

Exception in thread "main" java.lang.NoSuchMethodError: main

Hope this helps,
-Rick


Re: Derby eating up disk space + how to trigger ReclaimSpace elegantly

2011-08-08 Thread Dag H. Wanvik

On 05.08.2011 16:35, De Meyer Tim wrote:


Hi,

We're working on a java webapp and using a derby database (v10.5) in 
embedded mode.

The first version of the application went live about 2 months ago.
The application is used to make invoices and we also store the XML of 
an invoice document (input data for generating a PDF against a template).

Today, the database is about 1,7GB on disk.

During these 2 months, we've released some minor upgrades, including 
database migration scripts (like extra tables for new functionality).
Now we've noticed that, when we ran our latest upgrade, the database 
has suddenly shrunk to a size of 600MB.
This latest upgrade contained a migration script that dropped a no 
longer needed column on practically every table.

It's after executing this script that the shrink happened.
We did some debugging and hit suspend when the disk size started 
shrinking, it lead us to a Derby class called "ReclaimSpace".


The shrink was a bliss, because the customer was already complaining 
about the large size on disk :-)
We're afraid the database will start using up unnecessary space again 
soon, and of course, we're not going to have a similar migration 
script in every upgrade.
Is there an elegant way to configure derby to do this cleaning 
continuously, or to let our webapp instruct derby to do some cleaning?
We're launching the webapp from within a small java webstart app (we 
launch a Jetty and attach our war file), so it's even OK for us to 
write some java code to do it programmatically.


We've found this, but it's on a per table basis.
http://db.apache.org/derby/docs/10.1/adminguide/cadminspace21579.html
http://db.apache.org/derby/docs/10.5/ref/rrefaltertablecompress.htm 



The SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE and 
SYSCS_UTIL.SYSCS_COMPRESS_TABLE are the normal two way to reclaim space 
in Derby. The latter will also return space to the operating system, but 
requires a table level lock. The fact that they procedures opererates on 
a table at a time should't pose any big problem, you can use metadata to 
iterate over the tables of interest.


Some users have apps that can't afford to wait for the cleaning and opt 
for partitioning tables, say, one per month of data, and then dropping 
the tables that are older than a certain threshold. Views and/or table 
functions can be used to allows viewing the data as a whole in queries.


Thanks,
Dag






By the way, we're running about 10 of these webapps on different 
desktop PC's.
Each webapp synchronizes its data to a server running a postgresql 9 
database.
This means that this postgres database accumulates all the data of 
these 10 webapps (some data is shared, so it's not times ten).
The size of this postgres DB is less than 1GB, which we think is 
surprisingly small compared to the derby DB for one webapp.


Any help on all of this would be more than welcome.

Kind regards,

Tim De Meyer





Re: Can't Load Embedded Driver

2011-08-08 Thread Roy . Minet


Rick, 



Thank you very much for offering your help.  Apparently my CLASSPATH is good.  
I typed in "java org.apache.derby.jdbc.EmbeddedDriver" and did indeed get 
exactly the expected "Exception in thread "main" java.lang.NoSuchMethodError: 
main" error message.  What else could be causing  my problem? 



Roy 





- Original Message -


From: "Rick Hillegas"  
To: "Derby Discussion"  
Sent: Monday, August 8, 2011 9:00:58 AM 
Subject: Re: Can't Load Embedded Driver 

On 8/7/11 9:54 AM, roy.mi...@comcast.net wrote: 
> 
> I have been happily using Derby for two years within IntelliJ Idea, 
> but have now hit a wall trying to deploy the application I developed.   
> I have tried setting the path to derby.jar on the command line and/or 
> in the CLASSPATH environment variable to no avail.  The embedded 
> driver doesn't load; the error message is, "No suitable driver found 
> for jdbc:derby:EMDatabase;create=true".  I'm under Windows XP Pro.   
> Any help would be appreciated. 
> 
> Roy Minet 
> 
> 
Hi Roy, 

This is almost always a CLASSPATH problem. With the same CLASSPATH, try 
the following experiment: 

java org.apache.derby.jdbc.EmbeddedDriver 

If the CLASSPATH is good, you should see this error: 

Exception in thread "main" java.lang.NoSuchMethodError: main 

Hope this helps, 
-Rick 


Re: Can't Load Embedded Driver

2011-08-08 Thread Dag H. Wanvik

On 07.08.2011 18:54, roy.mi...@comcast.net wrote:


I have been happily using Derby for two years within IntelliJ Idea, 
but have now hit a wall trying to deploy the application I developed.  
I have tried setting the path to derby.jar on the command line and/or 
in the CLASSPATH environment variable to no avail.  The embedded 
driver doesn't load; the error message is, "No suitable driver found 
for jdbc:derby:EMDatabase;create=true".  I'm under Windows XP Pro.  
Any help would be appreciated.


Roy Minet


YOu can try to add Class.forName("org.apache.derby.jdbc.EmbeddedDriver") 
in the app before trying to connect, unless you have a recent Derby 
version in which case it shoul dnot be needed. Autoloading of the driver 
was introduced in Derby 10.2.
If you have a Derby version newer that 10.2, it sounds like a CLASSPATH 
issue.


If you run this command with the same classpath as you app, what do you see?

> java org.apache.derby.tools.sysinfo

It should the jar versions found on the classpath.

Dag



Re: Can't Load Embedded Driver

2011-08-08 Thread Raymond Kroeker
Can you try specifying the driver as a fqcn? If that doesn't solve the issue
please paste relevant code around how you load the driver and obtain a
connection.

Raymond
On Aug 8, 2011 6:55 AM,  wrote:
>
>
> Rick,
>
>
>
> Thank you very much for offering your help.  Apparently my CLASSPATH is
good.  I typed in "java org.apache.derby.jdbc.EmbeddedDriver" and did indeed
get exactly the expected "Exception in thread "main"
java.lang.NoSuchMethodError: main" error message.  What else could be
causing  my problem?
>
>
>
> Roy
>
>
>
>
>
> - Original Message -
>
>
> From: "Rick Hillegas" 
> To: "Derby Discussion" 
> Sent: Monday, August 8, 2011 9:00:58 AM
> Subject: Re: Can't Load Embedded Driver
>
> On 8/7/11 9:54 AM, roy.mi...@comcast.net wrote:
>>
>> I have been happily using Derby for two years within IntelliJ Idea,
>> but have now hit a wall trying to deploy the application I developed.
>> I have tried setting the path to derby.jar on the command line and/or
>> in the CLASSPATH environment variable to no avail.  The embedded
>> driver doesn't load; the error message is, "No suitable driver found
>> for jdbc:derby:EMDatabase;create=true".  I'm under Windows XP Pro.
>> Any help would be appreciated.
>>
>> Roy Minet
>>
>>
> Hi Roy,
>
> This is almost always a CLASSPATH problem. With the same CLASSPATH, try
> the following experiment:
>
> java org.apache.derby.jdbc.EmbeddedDriver
>
> If the CLASSPATH is good, you should see this error:
>
> Exception in thread "main" java.lang.NoSuchMethodError: main
>
> Hope this helps,
> -Rick


Re: Can't Load Embedded Driver

2011-08-08 Thread Máximo Castillo
I have some experience using Apache Derby. I can't remember exactly what was
the issue I found in my project. It worked on DEV but not in PRD. I fixed it
using derby.properties file.

Do some research and take a look a derby.properties file:

http://db.apache.org/derby/docs/dev/devguide/cdevdvlp39943.html



Max

On Mon, Aug 8, 2011 at 10:58 AM, Dag H. Wanvik wrote:

> **
> On 07.08.2011 18:54, roy.mi...@comcast.net wrote:
>
>  I have been happily using Derby for two years within IntelliJ Idea, but
> have now hit a wall trying to deploy the application I developed.  I have
> tried setting the path to derby.jar on the command line and/or in the
> CLASSPATH environment variable to no avail.  The embedded driver doesn't
> load; the error message is, "No suitable driver found for
> jdbc:derby:EMDatabase;create=true".  I'm under Windows XP Pro.  Any help
> would be appreciated.
>
>
>
> Roy Minet
>
>  YOu can try to add Class.forName("org.apache.derby.jdbc.EmbeddedDriver")
> in the app before trying to connect, unless you have a recent Derby version
> in which case it shoul dnot be needed. Autoloading of the driver was
> introduced in Derby 10.2.
> If you have a Derby version newer that 10.2, it sounds like a CLASSPATH
> issue.
>
> If you run this command with the same classpath as you app, what do you
> see?
>
> > java org.apache.derby.tools.sysinfo
>
> It should the jar versions found on the classpath.
>
> Dag
>
>


Re: Table exists in same JVM after Derby is shutdown

2011-08-08 Thread Pavel Bortnovskiy
Thank you, Dag.

It looks like in order to get this to work, I had to make two calls to 
DriverManager.getConnection.
Combining "shutdown=true;drop=true" didn't work.
So, is this the correct implementation (if in-line image doesn't work, 
please see attachment):






From:
dag.wan...@oracle.com (Dag H. Wanvik)
To:
"Derby Discussion" 
Date:
08/05/2011 06:36 PM
Subject:
Re: Table exists in same JVM after Derby is shutdown



Pavel Bortnovskiy  writes:

> 1) I create an in-memory database and then a table in it.
> Then the database is shut down.
> I would expect that the shutdown effectively cleans everything up.
> Is it not so?

Ah, I misunderstood you Pavel. Have a look here:

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

As you can see, you need to provide the "drop=true" connection
attribute to wipe the data.

Thanks,
Dag

>
> Thanks,
> Pavel.
>
>
>
> From:
> dag.wan...@oracle.com (Dag H. Wanvik)
> To:
> "Derby Discussion" 
> Date:
> 08/05/2011 05:57 PM
> Subject:
> Re: Table exists in same JVM after Derby is shutdown
>
>
>
> Pavel Bortnovskiy  writes:
>
>> Hello, all:
>>
>> While executing a bunch of JUnit tests within the same JVM (all 
executed 
>
>> by IntelliJ IDEA) I started seeing strange and unexpected errors 
> occurring
>> .
>> Upon closer inspection, I noticed that in many of those tests tables 
> with 
>> the same names are attempted to be created.
>> Then I realized that although Derby is shutdown and then re-created, 
the 
>
>> tables remain, thus causing collisions.
>
> The "create=true" connection attribute is ignored (with a warning) if
> the database with the same name alrady exists.
>
>>
>> I've created a digest (attached) which is executed as one JUnit test to 

>> illustrate what I'm seeing.
>> The behavior I would expect is that once Derby is shutdown, no tables 
>> would remain in the JVM, and if a database (with the same name) is 
>> re-created, it would be a tabula rasa.
>
> The tables are no longer in memory (or should not be unless you found a
> bug), but they are not erased from the disk image of the database.  As
> per the above, one would need to explicitly delete it using OS file
> system tools for the data to be cleared. Some JUnit tests delete tables
> in TestCase#tearDown, others use singleUseDatabaseDecorator to isolate
> itself from the rest of the tests. The tests not necessarily very
> consistent in their patterns for this..
>
> Dag
>
>>
>> Can you please let me know whether my expectations are erroneous and 
>> whether I should find workarounds (albeit trivial to implement).
>> However, what would concern me in that case is that the tables and the 
>> data remain in the JVM, thus consuming memory
>> (and, if unused, creating memory leaks).
>>
>> Thank you,
>>
>> Pavel.
>>
>>
>>
>>
>>
>>
>> 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 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 pro

Re: Can't Load Embedded Driver

2011-08-08 Thread Roy . Minet


I do not know what an "fqcn" is.  I am running the latest Derby release, 
10.8.1.2.  The code pasted in below works great  in the dev environment 
(IntelliJ Idea), but the same code packaged in a jar cannot find the driver 
with CLASSPATH set correctly. 

   public static Connection getConnection() 
   { 
  Connection c = null; 
  try 
  { // The connectionURL is "jdbc:derby:EMDatabase;create=true 
" 
 c = DriverManager.getConnection(connectionURL); 
 c.setAutoCommit(false); 
  } 
  catch (Throwable e) 
  { 
 log(3, "Unable to connect to " + dbName + ":  " + e.getMessage()); 
 stopDBMS(); 
 System.exit(3); 
  } 
  return c; 
   } 




- Original Message -


From: "Raymond Kroeker"  
To: "Derby Discussion"  
Sent: Monday, August 8, 2011 10:08:11 AM 
Subject: Re: Can't Load Embedded Driver 



Can you try specifying the driver as a fqcn? If that doesn't solve the issue 
please paste relevant code around how you load the driver and obtain a 
connection. 

Raymond 
On Aug 8, 2011 6:55 AM, < roy.mi...@comcast.net > wrote: 
> 
> 
> Rick, 
> 
> 
> 
> Thank you very much for offering your help.  Apparently my CLASSPATH is 
> good.  I typed in "java org.apache.derby.jdbc.EmbeddedDriver" and did indeed 
> get exactly the expected "Exception in thread "main" 
> java.lang.NoSuchMethodError: main" error message.  What else could be causing 
>  my problem? 
> 
> 
> 
> Roy 
> 
> 
> 
> 
> 
> - Original Message - 
> 
> 
> From: "Rick Hillegas" < rick.hille...@oracle.com > 
> To: "Derby Discussion" < derby-user@db.apache.org > 
> Sent: Monday, August 8, 2011 9:00:58 AM 
> Subject: Re: Can't Load Embedded Driver 
> 
> On 8/7/11 9:54 AM, roy.mi...@comcast.net wrote: 
>> 
>> I have been happily using Derby for two years within IntelliJ Idea, 
>> but have now hit a wall trying to deploy the application I developed.   
>> I have tried setting the path to derby.jar on the command line and/or 
>> in the CLASSPATH environment variable to no avail.  The embedded 
>> driver doesn't load; the error message is, "No suitable driver found 
>> for jdbc:derby:EMDatabase;create=true".  I'm under Windows XP Pro.   
>> Any help would be appreciated. 
>> 
>> Roy Minet 
>> 
>> 
> Hi Roy, 
> 
> This is almost always a CLASSPATH problem. With the same CLASSPATH, try 
> the following experiment: 
> 
> java org.apache.derby.jdbc.EmbeddedDriver 
> 
> If the CLASSPATH is good, you should see this error: 
> 
> Exception in thread "main" java.lang.NoSuchMethodError: main 
> 
> Hope this helps, 
> -Rick 


Re: Can't Load Embedded Driver

2011-08-08 Thread Raymond Kroeker
Hi Roy,

The fqcn, is the fully qualified class name of the driver.  So in your
code you're using the driver manager to grab a connection; however I
don't see a reference to loading the driver:
http://db.apache.org/derby/papers/DerbyTut/embedded_intro.html#embedded_driver

Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance();

Raymond

On Mon, Aug 8, 2011 at 11:47,   wrote:
> I do not know what an "fqcn" is.  I am running the latest Derby release,
> 10.8.1.2.  The code pasted in below works great in the dev environment
> (IntelliJ Idea), but the same code packaged in a jar cannot find the driver
> with CLASSPATH set correctly.
>
>    public static Connection getConnection()
>    {
>   Connection c = null;
>   try
>   { // The connectionURL
> is "jdbc:derby:EMDatabase;create=true"
>  c = DriverManager.getConnection(connectionURL);
>  c.setAutoCommit(false);
>   }
>   catch (Throwable e)
>   {
>  log(3, "Unable to connect to " + dbName + ":  " + e.getMessage());
>  stopDBMS();
>  System.exit(3);
>   }
>   return c;
>    }
>
>
>
> 
>
> From: "Raymond Kroeker" 
>
> To: "Derby Discussion" 
> Sent: Monday, August 8, 2011 10:08:11 AM
> Subject: Re: Can't Load Embedded Driver
>
> Can you try specifying the driver as a fqcn? If that doesn't solve the issue
> please paste relevant code around how you load the driver and obtain a
> connection.
>
> Raymond
>
> On Aug 8, 2011 6:55 AM,  wrote:
>>
>>
>> Rick,
>>
>>
>>
>> Thank you very much for offering your help.  Apparently my CLASSPATH is
>> good.  I typed in "java org.apache.derby.jdbc.EmbeddedDriver" and did indeed
>> get exactly the expected "Exception in thread "main"
>> java.lang.NoSuchMethodError: main" error message.  What else could be
>> causing  my problem?
>>
>>
>>
>> Roy
>>
>>
>>
>>
>>
>> - Original Message -
>>
>>
>> From: "Rick Hillegas" 
>> To: "Derby Discussion" 
>> Sent: Monday, August 8, 2011 9:00:58 AM
>> Subject: Re: Can't Load Embedded Driver
>>
>> On 8/7/11 9:54 AM, roy.mi...@comcast.net wrote:
>>>
>>> I have been happily using Derby for two years within IntelliJ Idea,
>>> but have now hit a wall trying to deploy the application I developed.
>>> I have tried setting the path to derby.jar on the command line and/or
>>> in the CLASSPATH environment variable to no avail.  The embedded
>>> driver doesn't load; the error message is, "No suitable driver found
>>> for jdbc:derby:EMDatabase;create=true".  I'm under Windows XP Pro.
>>> Any help would be appreciated.
>>>
>>> Roy Minet
>>>
>>>
>> Hi Roy,
>>
>> This is almost always a CLASSPATH problem. With the same CLASSPATH, try
>> the following experiment:
>>
>> java org.apache.derby.jdbc.EmbeddedDriver
>>
>> If the CLASSPATH is good, you should see this error:
>>
>> Exception in thread "main" java.lang.NoSuchMethodError: main
>>
>> Hope this helps,
>> -Rick
>



-- 
-
Raymond Kroeker


Re: Can't Load Embedded Driver

2011-08-08 Thread Rick Hillegas

Hi Roy,

Thanks for including the code snippet. As Raymond points out, you are 
not loading the driver explicitly. This should not be necessary if you 
are using Java 6 or 7. However, driver autoloading does not happen in 
Java 5 and earlier versions of Java. What version of Java are you using?


Thanks,
-Rick

On 8/8/11 11:55 AM, Raymond Kroeker wrote:

Hi Roy,

The fqcn, is the fully qualified class name of the driver.  So in your
code you're using the driver manager to grab a connection; however I
don't see a reference to loading the driver:
http://db.apache.org/derby/papers/DerbyTut/embedded_intro.html#embedded_driver

Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance();

Raymond

On Mon, Aug 8, 2011 at 11:47,  wrote:

I do not know what an "fqcn" is.  I am running the latest Derby release,
10.8.1.2.  The code pasted in below works great in the dev environment
(IntelliJ Idea), but the same code packaged in a jar cannot find the driver
with CLASSPATH set correctly.

public static Connection getConnection()
{
   Connection c = null;
   try
   { // The connectionURL
is "jdbc:derby:EMDatabase;create=true"
  c = DriverManager.getConnection(connectionURL);
  c.setAutoCommit(false);
   }
   catch (Throwable e)
   {
  log(3, "Unable to connect to " + dbName + ":  " + e.getMessage());
  stopDBMS();
  System.exit(3);
   }
   return c;
}





From: "Raymond Kroeker"

To: "Derby Discussion"
Sent: Monday, August 8, 2011 10:08:11 AM
Subject: Re: Can't Load Embedded Driver

Can you try specifying the driver as a fqcn? If that doesn't solve the issue
please paste relevant code around how you load the driver and obtain a
connection.

Raymond

On Aug 8, 2011 6:55 AM,  wrote:


Rick,



Thank you very much for offering your help.  Apparently my CLASSPATH is
good.  I typed in "java org.apache.derby.jdbc.EmbeddedDriver" and did indeed
get exactly the expected "Exception in thread "main"
java.lang.NoSuchMethodError: main" error message.  What else could be
causing  my problem?



Roy





- Original Message -


From: "Rick Hillegas"
To: "Derby Discussion"
Sent: Monday, August 8, 2011 9:00:58 AM
Subject: Re: Can't Load Embedded Driver

On 8/7/11 9:54 AM, roy.mi...@comcast.net wrote:

I have been happily using Derby for two years within IntelliJ Idea,
but have now hit a wall trying to deploy the application I developed.
I have tried setting the path to derby.jar on the command line and/or
in the CLASSPATH environment variable to no avail.  The embedded
driver doesn't load; the error message is, "No suitable driver found
for jdbc:derby:EMDatabase;create=true".  I'm under Windows XP Pro.
Any help would be appreciated.

Roy Minet



Hi Roy,

This is almost always a CLASSPATH problem. With the same CLASSPATH, try
the following experiment:

java org.apache.derby.jdbc.EmbeddedDriver

If the CLASSPATH is good, you should see this error:

Exception in thread "main" java.lang.NoSuchMethodError: main

Hope this helps,
-Rick







Re: Can't Load Embedded Driver

2011-08-08 Thread Roy . Minet
Using jdk1.6.0_20. 

- Original Message -
From: "Rick Hillegas"  
To: "Derby Discussion"  
Sent: Monday, August 8, 2011 3:24:09 PM 
Subject: Re: Can't Load Embedded Driver 

Hi Roy, 

Thanks for including the code snippet. As Raymond points out, you are 
not loading the driver explicitly. This should not be necessary if you 
are using Java 6 or 7. However, driver autoloading does not happen in 
Java 5 and earlier versions of Java. What version of Java are you using? 

Thanks, 
-Rick 

On 8/8/11 11:55 AM, Raymond Kroeker wrote: 
> Hi Roy, 
> 
> The fqcn, is the fully qualified class name of the driver.  So in your 
> code you're using the driver manager to grab a connection; however I 
> don't see a reference to loading the driver: 
> http://db.apache.org/derby/papers/DerbyTut/embedded_intro.html#embedded_driver
>  
> 
> Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance(); 
> 
> Raymond 
> 
> On Mon, Aug 8, 2011 at 11:47,  wrote: 
>> I do not know what an "fqcn" is.  I am running the latest Derby release, 
>> 10.8.1.2.  The code pasted in below works great in the dev environment 
>> (IntelliJ Idea), but the same code packaged in a jar cannot find the driver 
>> with CLASSPATH set correctly. 
>> 
>>     public static Connection getConnection() 
>>     { 
>>        Connection c = null; 
>>        try 
>>        {             // The connectionURL 
>> is "jdbc:derby:EMDatabase;create=true" 
>>           c = DriverManager.getConnection(connectionURL); 
>>           c.setAutoCommit(false); 
>>        } 
>>        catch (Throwable e) 
>>        { 
>>           log(3, "Unable to connect to " + dbName + ":  " + e.getMessage()); 
>>           stopDBMS(); 
>>           System.exit(3); 
>>        } 
>>        return c; 
>>     } 
>> 
>> 
>> 
>>  
>> 
>> From: "Raymond Kroeker" 
>> 
>> To: "Derby Discussion" 
>> Sent: Monday, August 8, 2011 10:08:11 AM 
>> Subject: Re: Can't Load Embedded Driver 
>> 
>> Can you try specifying the driver as a fqcn? If that doesn't solve the issue 
>> please paste relevant code around how you load the driver and obtain a 
>> connection. 
>> 
>> Raymond 
>> 
>> On Aug 8, 2011 6:55 AM,  wrote: 
>>> 
>>> Rick, 
>>> 
>>> 
>>> 
>>> Thank you very much for offering your help.  Apparently my CLASSPATH is 
>>> good.  I typed in "java org.apache.derby.jdbc.EmbeddedDriver" and did 
>>> indeed 
>>> get exactly the expected "Exception in thread "main" 
>>> java.lang.NoSuchMethodError: main" error message.  What else could be 
>>> causing  my problem? 
>>> 
>>> 
>>> 
>>> Roy 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> - Original Message - 
>>> 
>>> 
>>> From: "Rick Hillegas" 
>>> To: "Derby Discussion" 
>>> Sent: Monday, August 8, 2011 9:00:58 AM 
>>> Subject: Re: Can't Load Embedded Driver 
>>> 
>>> On 8/7/11 9:54 AM, roy.mi...@comcast.net wrote: 
 I have been happily using Derby for two years within IntelliJ Idea, 
 but have now hit a wall trying to deploy the application I developed. 
 I have tried setting the path to derby.jar on the command line and/or 
 in the CLASSPATH environment variable to no avail.  The embedded 
 driver doesn't load; the error message is, "No suitable driver found 
 for jdbc:derby:EMDatabase;create=true".  I'm under Windows XP Pro. 
 Any help would be appreciated. 
 
 Roy Minet 
 
 
>>> Hi Roy, 
>>> 
>>> This is almost always a CLASSPATH problem. With the same CLASSPATH, try 
>>> the following experiment: 
>>> 
>>> java org.apache.derby.jdbc.EmbeddedDriver 
>>> 
>>> If the CLASSPATH is good, you should see this error: 
>>> 
>>> Exception in thread "main" java.lang.NoSuchMethodError: main 
>>> 
>>> Hope this helps, 
>>> -Rick 
> 
> 



Re: Can't Load Embedded Driver

2011-08-08 Thread Roy . Minet
That bottom level plumbing has been working perfectly for two years in dev.  I 
remember thinking it was pretty cool and developer-friendly.  I had essentially 
NO trouble getting it all up and working.  I have now added the code to 
explicitly load the driver.  It works fine in dev, but not deployed in a jar 
(java.lang.ClassNotFoundException: 
org.apache.derby.jdbc.EmbeddedDriver).  CLASSPATH surely would be the usual 
suspect, but echo %CLASSPATH% yields " C:\Program 
Files\Apache\db-derby-10.8.1.2-bin\lib\derby.jar;." (derby.jar really IS in 
that location)  and  java org.apache.derby.jdbc.EmbeddedDriver yields 
"Exception in thread "main" java.lang.NoSuchMethodError: main" as Rick says it 
should.  So, WTF am I doing wrong?  In Unix, I would have double-checked rwx 
permissions (maybe Intellij Idea is running as root) , but I'm not as familiar 
with this stuff in Windows. 

- Original Message -
From: "Rick Hillegas"  
To: "Derby Discussion"  
Sent: Monday, August 8, 2011 3:24:09 PM 
Subject: Re: Can't Load Embedded Driver 

Hi Roy, 

Thanks for including the code snippet. As Raymond points out, you are 
not loading the driver explicitly. This should not be necessary if you 
are using Java 6 or 7. However, driver autoloading does not happen in 
Java 5 and earlier versions of Java. What version of Java are you using? 

Thanks, 
-Rick 

On 8/8/11 11:55 AM, Raymond Kroeker wrote: 
> Hi Roy, 
> 
> The fqcn, is the fully qualified class name of the driver.  So in your 
> code you're using the driver manager to grab a connection; however I 
> don't see a reference to loading the driver: 
> http://db.apache.org/derby/papers/DerbyTut/embedded_intro.html#embedded_driver
>  
> 
> Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance(); 
> 
> Raymond 
> 
> On Mon, Aug 8, 2011 at 11:47,  wrote: 
>> I do not know what an "fqcn" is.  I am running the latest Derby release, 
>> 10.8.1.2.  The code pasted in below works great in the dev environment 
>> (IntelliJ Idea), but the same code packaged in a jar cannot find the driver 
>> with CLASSPATH set correctly. 
>> 
>>     public static Connection getConnection() 
>>     { 
>>        Connection c = null; 
>>        try 
>>        {             // The connectionURL 
>> is "jdbc:derby:EMDatabase;create=true" 
>>           c = DriverManager.getConnection(connectionURL); 
>>           c.setAutoCommit(false); 
>>        } 
>>        catch (Throwable e) 
>>        { 
>>           log(3, "Unable to connect to " + dbName + ":  " + e.getMessage()); 
>>           stopDBMS(); 
>>           System.exit(3); 
>>        } 
>>        return c; 
>>     } 
>> 
>> 
>> 
>>  
>> 
>> From: "Raymond Kroeker" 
>> 
>> To: "Derby Discussion" 
>> Sent: Monday, August 8, 2011 10:08:11 AM 
>> Subject: Re: Can't Load Embedded Driver 
>> 
>> Can you try specifying the driver as a fqcn? If that doesn't solve the issue 
>> please paste relevant code around how you load the driver and obtain a 
>> connection. 
>> 
>> Raymond 
>> 
>> On Aug 8, 2011 6:55 AM,  wrote: 
>>> 
>>> Rick, 
>>> 
>>> 
>>> 
>>> Thank you very much for offering your help.  Apparently my CLASSPATH is 
>>> good.  I typed in "java org.apache.derby.jdbc.EmbeddedDriver" and did 
>>> indeed 
>>> get exactly the expected "Exception in thread "main" 
>>> java.lang.NoSuchMethodError: main" error message.  What else could be 
>>> causing  my problem? 
>>> 
>>> 
>>> 
>>> Roy 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> - Original Message - 
>>> 
>>> 
>>> From: "Rick Hillegas" 
>>> To: "Derby Discussion" 
>>> Sent: Monday, August 8, 2011 9:00:58 AM 
>>> Subject: Re: Can't Load Embedded Driver 
>>> 
>>> On 8/7/11 9:54 AM, roy.mi...@comcast.net wrote: 
 I have been happily using Derby for two years within IntelliJ Idea, 
 but have now hit a wall trying to deploy the application I developed. 
 I have tried setting the path to derby.jar on the command line and/or 
 in the CLASSPATH environment variable to no avail.  The embedded 
 driver doesn't load; the error message is, "No suitable driver found 
 for jdbc:derby:EMDatabase;create=true".  I'm under Windows XP Pro. 
 Any help would be appreciated. 
 
 Roy Minet 
 
 
>>> Hi Roy, 
>>> 
>>> This is almost always a CLASSPATH problem. With the same CLASSPATH, try 
>>> the following experiment: 
>>> 
>>> java org.apache.derby.jdbc.EmbeddedDriver 
>>> 
>>> If the CLASSPATH is good, you should see this error: 
>>> 
>>> Exception in thread "main" java.lang.NoSuchMethodError: main 
>>> 
>>> Hope this helps, 
>>> -Rick 
> 
> 



Re: Can't Load Embedded Driver

2011-08-08 Thread Myrna van Lunteren
On Mon, Aug 8, 2011 at 1:53 PM,   wrote:
> That bottom level plumbing has been working perfectly for two years in dev.
> I remember thinking it was pretty cool and developer-friendly.  I had
> essentially NO trouble getting it all up and working.  I have now added the
> code to explicitly load the driver.  It works fine in dev, but not deployed
> in a jar (java.lang.ClassNotFoundException:
> org.apache.derby.jdbc.EmbeddedDriver).  CLASSPATH surely would be the usual
> suspect, but echo %CLASSPATH% yields "C:\Program
> Files\Apache\db-derby-10.8.1.2-bin\lib\derby.jar;." (derby.jar really IS in
> that location) and  java org.apache.derby.jdbc.EmbeddedDriver yields
> "Exception in thread "main" java.lang.NoSuchMethodError: main" as Rick says
> it should.  So, WTF am I doing wrong?  In Unix, I would have double-checked
> rwx permissions (maybe Intellij Idea is running as root), but I'm not as
> familiar with this stuff in Windows.
>
> 
> From: "Rick Hillegas" 
> To: "Derby Discussion" 
> Sent: Monday, August 8, 2011 3:24:09 PM
> Subject: Re: Can't Load Embedded Driver
>
> Hi Roy,
>
> Thanks for including the code snippet. As Raymond points out, you are
> not loading the driver explicitly. This should not be necessary if you
> are using Java 6 or 7. However, driver autoloading does not happen in
> Java 5 and earlier versions of Java. What version of Java are you using?
>
> Thanks,
> -Rick
>
> On 8/8/11 11:55 AM, Raymond Kroeker wrote:
>> Hi Roy,
>>
>> The fqcn, is the fully qualified class name of the driver.  So in your
>> code you're using the driver manager to grab a connection; however I
>> don't see a reference to loading the driver:
>>
>> http://db.apache.org/derby/papers/DerbyTut/embedded_intro.html#embedded_driver
>>
>> Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance();
>>
>> Raymond
>>
>> On Mon, Aug 8, 2011 at 11:47,  wrote:
>>> I do not know what an "fqcn" is.  I am running the latest Derby release,
>>> 10.8.1.2.  The code pasted in below works great in the dev environment
>>> (IntelliJ Idea), but the same code packaged in a jar cannot find the
>>> driver
>>> with CLASSPATH set correctly.
>>>
>>>     public static Connection getConnection()
>>>     {
>>>        Connection c = null;
>>>        try
>>>        {             // The connectionURL
>>> is "jdbc:derby:EMDatabase;create=true"
>>>           c = DriverManager.getConnection(connectionURL);
>>>           c.setAutoCommit(false);
>>>        }
>>>        catch (Throwable e)
>>>        {
>>>           log(3, "Unable to connect to " + dbName + ":  " +
>>> e.getMessage());
>>>           stopDBMS();
>>>           System.exit(3);
>>>        }
>>>        return c;
>>>     }
>>>
>>>
>>>
>>> 
>>>
>>> From: "Raymond Kroeker"
>>>
>>> To: "Derby Discussion"
>>> Sent: Monday, August 8, 2011 10:08:11 AM
>>> Subject: Re: Can't Load Embedded Driver
>>>
>>> Can you try specifying the driver as a fqcn? If that doesn't solve the
>>> issue
>>> please paste relevant code around how you load the driver and obtain a
>>> connection.
>>>
>>> Raymond
>>>
>>> On Aug 8, 2011 6:55 AM,  wrote:

 Rick,



 Thank you very much for offering your help.  Apparently my CLASSPATH is
 good.  I typed in "java org.apache.derby.jdbc.EmbeddedDriver" and did
 indeed
 get exactly the expected "Exception in thread "main"
 java.lang.NoSuchMethodError: main" error message.  What else could be
 causing  my problem?



 Roy





 - Original Message -


 From: "Rick Hillegas"
 To: "Derby Discussion"
 Sent: Monday, August 8, 2011 9:00:58 AM
 Subject: Re: Can't Load Embedded Driver

 On 8/7/11 9:54 AM, roy.mi...@comcast.net wrote:
> I have been happily using Derby for two years within IntelliJ Idea,
> but have now hit a wall trying to deploy the application I developed.
> I have tried setting the path to derby.jar on the command line and/or
> in the CLASSPATH environment variable to no avail.  The embedded
> driver doesn't load; the error message is, "No suitable driver found
> for jdbc:derby:EMDatabase;create=true".  I'm under Windows XP Pro.
> Any help would be appreciated.
>
> Roy Minet
>
>
 Hi Roy,

 This is almost always a CLASSPATH problem. With the same CLASSPATH, try
 the following experiment:

 java org.apache.derby.jdbc.EmbeddedDriver

 If the CLASSPATH is good, you should see this error:

 Exception in thread "main" java.lang.NoSuchMethodError: main

 Hope this helps,
 -Rick
>>
>>
>
Looks like it should work. Perhaps derby/intelliJ Idea/the jvm has
trouble with the space in the classpath. I think with some tools I
have to use the 8 character DOS equivalent (e.g. Progra~1 instead of
Program Files) when I refer to directory names with spaces.

So, perhaps it's worth a quick try to see if it wor

Re: Can't Load Embedded Driver

2011-08-08 Thread Roy . Minet
Thanks for the suggestion, Myrna.  However, it's NOT Intellij Idea that is 
having a problem; everything has been working perfectly in dev.  It's when I 
build a jar and just run under Windows that the problem occurs.  I'm getting 
desperate, though, so I'll try  "PROGRA~1" and/or  moving the jars to somewhere 
else  with no spaces in the path. 

- Original Message -
From: "Myrna van Lunteren"  
To: "Derby Discussion"  
Sent: Monday, August 8, 2011 5:18:17 PM 
Subject: Re: Can't Load Embedded Driver 

On Mon, Aug 8, 2011 at 1:53 PM,   wrote: 
> That bottom level plumbing has been working perfectly for two years in dev. 
> I remember thinking it was pretty cool and developer-friendly.  I had 
> essentially NO trouble getting it all up and working.  I have now added the 
> code to explicitly load the driver.  It works fine in dev, but not deployed 
> in a jar (java.lang.ClassNotFoundException: 
> org.apache.derby.jdbc.EmbeddedDriver).  CLASSPATH surely would be the usual 
> suspect, but echo %CLASSPATH% yields "C:\Program 
> Files\Apache\db-derby-10.8.1.2-bin\lib\derby.jar;." (derby.jar really IS in 
> that location) and  java org.apache.derby.jdbc.EmbeddedDriver yields 
> "Exception in thread "main" java.lang.NoSuchMethodError: main" as Rick says 
> it should.  So, WTF am I doing wrong?  In Unix, I would have double-checked 
> rwx permissions (maybe Intellij Idea is running as root), but I'm not as 
> familiar with this stuff in Windows. 
> 
>  
> From: "Rick Hillegas"  
> To: "Derby Discussion"  
> Sent: Monday, August 8, 2011 3:24:09 PM 
> Subject: Re: Can't Load Embedded Driver 
> 
> Hi Roy, 
> 
> Thanks for including the code snippet. As Raymond points out, you are 
> not loading the driver explicitly. This should not be necessary if you 
> are using Java 6 or 7. However, driver autoloading does not happen in 
> Java 5 and earlier versions of Java. What version of Java are you using? 
> 
> Thanks, 
> -Rick 
> 
> On 8/8/11 11:55 AM, Raymond Kroeker wrote: 
>> Hi Roy, 
>> 
>> The fqcn, is the fully qualified class name of the driver.  So in your 
>> code you're using the driver manager to grab a connection; however I 
>> don't see a reference to loading the driver: 
>> 
>> http://db.apache.org/derby/papers/DerbyTut/embedded_intro.html#embedded_driver
>>  
>> 
>> Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance(); 
>> 
>> Raymond 
>> 
>> On Mon, Aug 8, 2011 at 11:47,  wrote: 
>>> I do not know what an "fqcn" is.  I am running the latest Derby release, 
>>> 10.8.1.2.  The code pasted in below works great in the dev environment 
>>> (IntelliJ Idea), but the same code packaged in a jar cannot find the 
>>> driver 
>>> with CLASSPATH set correctly. 
>>> 
>>>     public static Connection getConnection() 
>>>     { 
>>>        Connection c = null; 
>>>        try 
>>>        {             // The connectionURL 
>>> is "jdbc:derby:EMDatabase;create=true" 
>>>           c = DriverManager.getConnection(connectionURL); 
>>>           c.setAutoCommit(false); 
>>>        } 
>>>        catch (Throwable e) 
>>>        { 
>>>           log(3, "Unable to connect to " + dbName + ":  " + 
>>> e.getMessage()); 
>>>           stopDBMS(); 
>>>           System.exit(3); 
>>>        } 
>>>        return c; 
>>>     } 
>>> 
>>> 
>>> 
>>>  
>>> 
>>> From: "Raymond Kroeker" 
>>> 
>>> To: "Derby Discussion" 
>>> Sent: Monday, August 8, 2011 10:08:11 AM 
>>> Subject: Re: Can't Load Embedded Driver 
>>> 
>>> Can you try specifying the driver as a fqcn? If that doesn't solve the 
>>> issue 
>>> please paste relevant code around how you load the driver and obtain a 
>>> connection. 
>>> 
>>> Raymond 
>>> 
>>> On Aug 8, 2011 6:55 AM,  wrote: 
 
 Rick, 
 
 
 
 Thank you very much for offering your help.  Apparently my CLASSPATH is 
 good.  I typed in "java org.apache.derby.jdbc.EmbeddedDriver" and did 
 indeed 
 get exactly the expected "Exception in thread "main" 
 java.lang.NoSuchMethodError: main" error message.  What else could be 
 causing  my problem? 
 
 
 
 Roy 
 
 
 
 
 
 - Original Message - 
 
 
 From: "Rick Hillegas" 
 To: "Derby Discussion" 
 Sent: Monday, August 8, 2011 9:00:58 AM 
 Subject: Re: Can't Load Embedded Driver 
 
 On 8/7/11 9:54 AM, roy.mi...@comcast.net wrote: 
> I have been happily using Derby for two years within IntelliJ Idea, 
> but have now hit a wall trying to deploy the application I developed. 
> I have tried setting the path to derby.jar on the command line and/or 
> in the CLASSPATH environment variable to no avail.  The embedded 
> driver doesn't load; the error message is, "No suitable driver found 
> for jdbc:derby:EMDatabase;create=true".  I'm under Windows XP Pro. 
> Any help would be appreciated. 
> 
> Roy Minet 
> 
> 
 Hi Roy, 
 
 T

Re: Table exists in same JVM after Derby is shutdown

2011-08-08 Thread Kristian Waagan

On 08.08.11 16:41, Pavel Bortnovskiy wrote:

Thank you, Dag.

It looks like in order to get this to work, I had to make two calls to
DriverManager.getConnection.
Combining "/shutdown=true;drop=true/" didn't work.
So, is this the correct implementation (if in-line image doesn't work,
please see attachment):


Hello Pavel,

To simply drop an in-memory database, you only need the drop attribute. 
Shutdown of the specified database happens as part of the drop operation.


It is correct that you need two calls to DriverManager.getConnection if 
you want to drop a database and additionally shut down the Derby engine. 
For clarity, note that there is a difference between shutting down a 
specific database and the Derby engine/system.


Further, shutting down an in-memory database does not drop it, neither 
does shutting down the Derby engine. I don't know, maybe it would make 
sense to drop all in-memory databases when the Derby system is shut down 
- but that's not being done currently.



Hope this helps,
--
Kristian







From:   dag.wan...@oracle.com (Dag H. Wanvik)
To: "Derby Discussion" 
Date:   08/05/2011 06:36 PM
Subject:Re: Table exists in same JVM after Derby is shutdown






Pavel Bortnovskiy  writes:

 > 1) I create an in-memory database and then a table in it.
 > Then the database is shut down.
 > I would expect that the shutdown effectively cleans everything up.
 > Is it not so?

Ah, I misunderstood you Pavel. Have a look here:

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

As you can see, you need to provide the "drop=true" connection
attribute to wipe the data.

Thanks,
Dag

 >
 > Thanks,
 > Pavel.
 >
 >
 >
 > From:
 > dag.wan...@oracle.com (Dag H. Wanvik)
 > To:
 > "Derby Discussion" 
 > Date:
 > 08/05/2011 05:57 PM
 > Subject:
 > Re: Table exists in same JVM after Derby is shutdown
 >
 >
 >
 > Pavel Bortnovskiy  writes:
 >
 >> Hello, all:
 >>
 >> While executing a bunch of JUnit tests within the same JVM (all
executed
 >
 >> by IntelliJ IDEA) I started seeing strange and unexpected errors
 > occurring
 >> .
 >> Upon closer inspection, I noticed that in many of those tests tables
 > with
 >> the same names are attempted to be created.
 >> Then I realized that although Derby is shutdown and then re-created,
the
 >
 >> tables remain, thus causing collisions.
 >
 > The "create=true" connection attribute is ignored (with a warning) if
 > the database with the same name alrady exists.
 >
 >>
 >> I've created a digest (attached) which is executed as one JUnit test to
 >> illustrate what I'm seeing.
 >> The behavior I would expect is that once Derby is shutdown, no tables
 >> would remain in the JVM, and if a database (with the same name) is
 >> re-created, it would be a tabula rasa.
 >
 > The tables are no longer in memory (or should not be unless you found a
 > bug), but they are not erased from the disk image of the database. As
 > per the above, one would need to explicitly delete it using OS file
 > system tools for the data to be cleared. Some JUnit tests delete tables
 > in TestCase#tearDown, others use singleUseDatabaseDecorator to isolate
 > itself from the rest of the tests. The tests not necessarily very
 > consistent in their patterns for this..
 >
 > Dag
 >
 >>
 >> Can you please let me know whether my expectations are erroneous and
 >> whether I should find workarounds (albeit trivial to implement).
 >> However, what would concern me in that case is that the tables and the
 >> data remain in the JVM, thus consuming memory
 >> (and, if unused, creating memory leaks).
 >>
 >> Thank you,
 >>
 >> Pavel.
 >>


< snip >



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: Can't Load Embedded Driver

2011-08-08 Thread Erik Steen Jakobsen
the call  "jdbc:derby:EMDatabase;create=true" is not a valid call to
embedded driver. It is a call to a derby server
 
correct url should be ( as far as I know) "jdbc:derby:;create=true"
 
I think that is what the docs says at least.
Erik




From: roy.mi...@comcast.net [mailto:roy.mi...@comcast.net] 
Sent: 9. august 2011 00:15
To: Derby Discussion
Subject: Re: Can't Load Embedded Driver


Thanks for the suggestion, Myrna.  However, it's NOT Intellij Idea that
is having a problem; everything has been working perfectly in dev.  It's
when I build a jar and just run under Windows that the problem occurs.
I'm getting desperate, though, so I'll try  "PROGRA~1" and/or moving the
jars to somewhere else with no spaces in the path.




From: "Myrna van Lunteren" 
To: "Derby Discussion" 
Sent: Monday, August 8, 2011 5:18:17 PM
Subject: Re: Can't Load Embedded Driver

On Mon, Aug 8, 2011 at 1:53 PM,   wrote:
> That bottom level plumbing has been working perfectly for two years in
dev.
> I remember thinking it was pretty cool and developer-friendly.  I had
> essentially NO trouble getting it all up and working.  I have now
added the
> code to explicitly load the driver.  It works fine in dev, but not
deployed
> in a jar (java.lang.ClassNotFoundException:
> org.apache.derby.jdbc.EmbeddedDriver).  CLASSPATH surely would be the
usual
> suspect, but echo %CLASSPATH% yields "C:\Program
> Files\Apache\db-derby-10.8.1.2-bin\lib\derby.jar;." (derby.jar really
IS in
> that location) and  java org.apache.derby.jdbc.EmbeddedDriver yields
> "Exception in thread "main" java.lang.NoSuchMethodError: main" as Rick
says
> it should.  So, WTF am I doing wrong?  In Unix, I would have
double-checked
> rwx permissions (maybe Intellij Idea is running as root), but I'm not
as
> familiar with this stuff in Windows.
>
> 
> From: "Rick Hillegas" 
> To: "Derby Discussion" 
> Sent: Monday, August 8, 2011 3:24:09 PM
> Subject: Re: Can't Load Embedded Driver
>
> Hi Roy,
>
> Thanks for including the code snippet. As Raymond points out, you are
> not loading the driver explicitly. This should not be necessary if you
> are using Java 6 or 7. However, driver autoloading does not happen in
> Java 5 and earlier versions of Java. What version of Java are you
using?
>
> Thanks,
> -Rick
>
> On 8/8/11 11:55 AM, Raymond Kroeker wrote:
>> Hi Roy,
>>
>> The fqcn, is the fully qualified class name of the driver.  So in
your
>> code you're using the driver manager to grab a connection; however I
>> don't see a reference to loading the driver:
>>
>>
http://db.apache.org/derby/papers/DerbyTut/embedded_intro.html#embedded_
driver
>>
>> Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance();
>>
>> Raymond
>>
>> On Mon, Aug 8, 2011 at 11:47,  wrote:
>>> I do not know what an "fqcn" is.  I am running the latest Derby
release,
>>> 10.8.1.2.  The code pasted in below works great in the dev
environment
>>> (IntelliJ Idea), but the same code packaged in a jar cannot find the
>>> driver
>>> with CLASSPATH set correctly.
>>>
>>> public static Connection getConnection()
>>> {
>>>Connection c = null;
>>>try
>>>{ // The connectionURL
>>> is "jdbc:derby:EMDatabase;create=true"
>>>   c = DriverManager.getConnection(connectionURL);
>>>   c.setAutoCommit(false);
>>>}
>>>catch (Throwable e)
>>>{
>>>   log(3, "Unable to connect to " + dbName + ":  " +
>>> e.getMessage());
>>>   stopDBMS();
>>>   System.exit(3);
>>>}
>>>return c;
>>> }
>>>
>>>
>>>
>>> 
>>>
>>> From: "Raymond Kroeker"
>>>
>>> To: "Derby Discussion"
>>> Sent: Monday, August 8, 2011 10:08:11 AM
>>> Subject: Re: Can't Load Embedded Driver
>>>
>>> Can you try specifying the driver as a fqcn? If that doesn't solve
the
>>> issue
>>> please paste relevant code around how you load the driver and obtain
a
>>> connection.
>>>
>>> Raymond
>>>
>>> On Aug 8, 2011 6:55 AM,  wrote:

 Rick,



 Thank you very much for offering your help.  Apparently my
CLASSPATH is
 good.  I typed in "java org.apache.derby.jdbc.EmbeddedDriver" and
did
 indeed
 get exactly the expected "Exception in thread "main"
 java.lang.NoSuchMethodError: main" error message.  What else could
be
 causing  my problem?



 Roy





 - Original Message -


 From: "Rick Hillegas"
 To: "Derby Discussion"
 Sent: Monday, August 8, 2011 9:00:58 AM
 Subject: Re: Can't Load Embedded Driver

 On 8/7/11 9:54 AM, roy.mi...@comcast.net wrote:
> I have been happily using Derby for two years within IntelliJ
Idea,
> but have now hit a wall trying to deploy the application I
developed.
> I have tried setting the path to derby.jar on the command line
and/or
> in the CLASSPATH e