Re: hello

2015-11-04 Thread Rick Hillegas

On 11/1/15 2:37 PM, בבנייה בבנייה wrote:
I trying to leran derby for a project that include it. I want to say 
that it's very not full , there is much misunderstand for who that not 
familiar with all issues like class path, start server and more. I 
think that should at least be a quick and friendly guide for get some 
order with all the mess.


good day,,,
Please consult the Getting Started Guide here: 
http://db.apache.org/derby/docs/10.12/getstart/index.html


Thanks,
-Rick


Re: hello

2015-11-03 Thread Dyre Tjeldvoll

On 11/01/2015 11:37 PM, בבנייה בבנייה wrote:

I trying to leran derby for a project that include it. I want to say
that it's very not full , there is much misunderstand for who that not
familiar with all issues like class path, start server and more. I think
that should at least be a quick and friendly guide for get some order
with all the mess.

good day,,,


Please see http://www.catb.org/esr/faqs/smart-questions.html

--
Regards,

Dyre


RE: hello

2012-05-28 Thread Carlos de Luna Saenz
Try the followin quotation:
C:\Program Files\Apache\db-derby-10.8.1.2-bin\lib\derby.jar;C:\Program 
Files\Apache\db-derby-10.8.1.2-bin\LIB\derbytools.jar;

That is the complete path of the jar and no only the directory with the space.
Greetings

-Mensaje original-
De: Bryan Pendleton [mailto:bpendleton.de...@gmail.com] 
Enviado el: viernes, 25 de mayo de 2012 08:03 p.m.
Para: Derby Discussion
Asunto: Re: hello

 C:\java org.apache.derby.tools.sysinfo
 Error: Could not find or load main class 
 org.apache.derby.tools.sysinfo

 C:\echo %CLASSPATH%
 C:\Program Files\Apache\db-derby-10.8.1.2-bin\lib\derby.jar;C:\Program 
 Files
 \Apache\db-derby-10.8.1.2-bin\LIB\derbytools.jar;

Sometimes it is hard to get the quotation marks correct when you have spaces in 
file names. Why don't you try putting the Derby installation into a different 
directory, without spaces in the names, for example c:\derby10.8, and see if 
setting your classpath to point to that directory makes things easier.

thanks,

bryan


Re: hello

2012-05-25 Thread Bryan Pendleton

C:\java org.apache.derby.tools.sysinfo
Error: Could not find or load main class org.apache.derby.tools.sysinfo

C:\echo %CLASSPATH%
C:\Program Files\Apache\db-derby-10.8.1.2-bin\lib\derby.jar;C:\Program Files
\Apache\db-derby-10.8.1.2-bin\LIB\derbytools.jar;


Sometimes it is hard to get the quotation marks correct when you have spaces
in file names. Why don't you try putting the Derby installation into a
different directory, without spaces in the names, for example c:\derby10.8,
and see if setting your classpath to point to that directory makes things
easier.

thanks,

bryan


Re: Hello

2009-12-01 Thread Bryan Pendleton

When I try to run WwdEmbedded.java there is an error that looks like this:
---
C:\Documents and Settings\Zoran\Desktop\DERBYTUTORjava WwdEmbedded
Exception in thread main java.lang.NoClassDefFoundError: WwdEmbedded


I suspect this is because you didn't set your CLASSPATH environment variable
carefully, to include . in the classpath. See step (1) of the instructions at:
http://db.apache.org/derby/docs/dev/getstart/twwdactivity3_Setup.html
and ensure that you have done:

  set CLASSPATH=%DERBY_HOME%\lib\derby.jar;.

thanks,

bryan





Re: Hello

2009-12-01 Thread Kim Haase
This error can happen if you do not have the current directory in your 
classpath. Did you follow all the instructions in the Setting up your 
environment section, including Manually setting the CLASSPATH 
environment variable?


Kim Haase

On 12/01/09 12:51, velimzo wrote:
I am new in Derby. 


Here is my problem:
I am following Getting Started With Java DB instructions.
Problem occures when I try to follow instructions for Run a JDBC program
using the embedded driver.
I compiled successfully WwdEmbedded.java, not following instructions but
with a command javac *.java
When I try to run WwdEmbedded.java there is an error that looks like this:
---
C:\Documents and Settings\Zoran\Desktop\DERBYTUTORjava WwdEmbedded
Exception in thread main java.lang.NoClassDefFoundError: WwdEmbedded
Caused by: java.lang.ClassNotFoundException: WwdEmbedded
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
Could not find the main class: WwdEmbedded.  Program will exit.
-
My version of Java is : Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Version of Derby is : Derby 10.5.3.0
Operating System : Windows XP sp3

I am thankful on every answer...


Re: performance, memory consumption...and a big hello :)

2009-08-10 Thread Tomi N/A
2009/7/29 Dan Armbrust daniel.armbrust.l...@gmail.com:
 Problem 1:

 select id_group, count(id)
 group by id_group

 This takes a couple of minutes,

 Is that the entire query?  No where clause?

 I don't think any database is going to use the index when you aren't
 providing a where clause... especially when you have a count and a
 group by in there... it has to read the entire table.

Well, initially, I would have agreed with you, but after having
thought about it for a while and having read a couple of threads in
various forums and mailing lists, I think it's not impossible: an
index might in fact be useful if all the information is inside it,
i.e. the table itself doesn't need to be read. Still, you might be
right: I'm not sure yet.


Re: performance, memory consumption...and a big hello :)

2009-08-10 Thread Tomi N/A
2009/7/29 Kristian Waagan kristian.waa...@sun.com:
 Hello Tomislav,

 You might want to read this:
 http://wiki.apache.org/db-derby/StmtExecutionPlan
 Especially, follow the link for the QueryPlanJoinOrder.

 ...
 A new feature has also been introduced into the development trunk, called
 the XPLAIN style runtime statistics. It may or may not be of interest to
 you, consult the Derby Tuning Guide for more information.

Thanks, Kristian. I had looked in the Derby Tuning Guide and had
gotten the distinct impression that the available tools only display
information after the query has been executed which was not really
what I was looking for.
I look forward to future improvements (the XPLAIN statement, for example).


Re: performance, memory consumption...and a big hello :)

2009-08-10 Thread Tomi N/A
2009/7/29 Rick Hillegas richard.hille...@sun.com:

 Some great work has been put into improving Derby's explain capabilities
 in the next feature release. In the meantime, you can view Derby query plans
 by using the SYSCS_UTIL.SYSCS_SET_RUNTIMESTATISTICS() system procedure.
 Please see the Derby Tuning Guide:
 http://db.apache.org/derby/docs/10.5/tuning/tuning-single.html#ctundepth13055

As I've already mentioned to Kristian, from what I understood from the
Tuning Guide, the information is all available once the query is
finished which was quite cumbersome in my case. I was interested in
testing a dozen or two combinations with different indexes setups and
if each test took a long time (because the query had to be actually
executed, rather than just it's plan displayed), it would take
forever.
I'm glad to hear there are improvements on the way as Derby remains
the DB of choice on my project.


 Have you tried

 ( id_group1, id )

 This index covers your query and is in a useful sort order. If Derby does
 not use this index on your large data set, then there may be a bug. It would
 be interesting to see the query plan which Derby follows when you have
 declared this index.

Interesting idea, Rick. At the moment I don't have the Derby instance
available, but I did try it out on postgresql. However, I've had no
lock: the column order doesn't seem to impact the execution plan: it's
invariably a seq. scan...still a nice try, though. I like your
methodical, precise analytical approach. :)


Re: performance, memory consumption...and a big hello :)

2009-07-29 Thread Tomi N/A
Thank you both for the comments.

Jan, I've kind of taken your advice even before I saw it :), but I
tried PostgreSQL, unfortunately, with no obvious improvement.

2009/7/27 Rick Hillegas richard.hille...@sun.com:

 select id_group, count(id)
 group by id_group


 Not to be tiresome, but just to make sure we understand the query: I think
 you mean id_group1 instead of id_group.

Exactly right.

 It sounds as though you may have created an index on ( id_group1, id ). At
 first blush, I would expect that index to improve the performance. Did that
 not happen?

That is exactly what I observed.
As I told Jan, I've tried it out on PostgreSQL in the meantime because
a) I wanted to see how a different RDBMS would behave and b) because
derby (it seems) doesn't support the explain command to show the
query plan and PostgreSQL does.
I've tried the following indexes:
(id)
(id_group1)
(id, id_group1)
but postgresql announced a sequential table scan every time and, in
fact, seemed to have done exactly that when I executed the query.

Either I'm doing something obviously wrong or am assuming something
obviously impossible is possible, but I'm inclined to believe the
former, rather than the latter which is why I'm writing. :-)

Cheers,
Tomislav


Re: performance, memory consumption...and a big hello :)

2009-07-29 Thread Dan Armbrust
 Problem 1:

 select id_group, count(id)
 group by id_group

 This takes a couple of minutes,

Is that the entire query?  No where clause?

I don't think any database is going to use the index when you aren't
providing a where clause... especially when you have a count and a
group by in there... it has to read the entire table.


Re: performance, memory consumption...and a big hello :)

2009-07-29 Thread Kristian Waagan

Tomi N/A wrote:

Thank you both for the comments.

Jan, I've kind of taken your advice even before I saw it :), but I
tried PostgreSQL, unfortunately, with no obvious improvement.

2009/7/27 Rick Hillegas richard.hille...@sun.com:

  

select id_group, count(id)
group by id_group

  

Not to be tiresome, but just to make sure we understand the query: I think
you mean id_group1 instead of id_group.



Exactly right.

  

It sounds as though you may have created an index on ( id_group1, id ). At
first blush, I would expect that index to improve the performance. Did that
not happen?



That is exactly what I observed.
As I told Jan, I've tried it out on PostgreSQL in the meantime because
a) I wanted to see how a different RDBMS would behave and b) because
derby (it seems) doesn't support the explain command to show the
query plan and PostgreSQL does.
  


Hello Tomislav,

You might want to read this: 
http://wiki.apache.org/db-derby/StmtExecutionPlan

Especially, follow the link for the QueryPlanJoinOrder.

This feature of Derby isn't what I would call the most user friendly, 
but with some effort it should give you the information you need.



A new feature has also been introduced into the development trunk, 
called the XPLAIN style runtime statistics. It may or may not be of 
interest to you, consult the Derby Tuning Guide for more information.



Regards,
--
Kristian


I've tried the following indexes:
(id)
(id_group1)
(id, id_group1)
but postgresql announced a sequential table scan every time and, in
fact, seemed to have done exactly that when I executed the query.

Either I'm doing something obviously wrong or am assuming something
obviously impossible is possible, but I'm inclined to believe the
former, rather than the latter which is why I'm writing. :-)

Cheers,
Tomislav
  




Re: performance, memory consumption...and a big hello :)

2009-07-29 Thread Rick Hillegas

Hi Tomislav,

Some more comments inline...

Tomi N/A wrote:

Thank you both for the comments.

Jan, I've kind of taken your advice even before I saw it :), but I
tried PostgreSQL, unfortunately, with no obvious improvement.

2009/7/27 Rick Hillegas richard.hille...@sun.com:

  

select id_group, count(id)
group by id_group

  

Not to be tiresome, but just to make sure we understand the query: I think
you mean id_group1 instead of id_group.



Exactly right.

  

It sounds as though you may have created an index on ( id_group1, id ). At
first blush, I would expect that index to improve the performance. Did that
not happen?



That is exactly what I observed.
As I told Jan, I've tried it out on PostgreSQL in the meantime because
a) I wanted to see how a different RDBMS would behave and b) because
derby (it seems) doesn't support the explain command to show the
query plan and PostgreSQL does.
  
Some great work has been put into improving Derby's explain 
capabilities in the next feature release. In the meantime, you can view 
Derby query plans by using the SYSCS_UTIL.SYSCS_SET_RUNTIMESTATISTICS() 
system procedure. Please see the Derby Tuning Guide: 
http://db.apache.org/derby/docs/10.5/tuning/tuning-single.html#ctundepth13055

I've tried the following indexes:
  
(id)
  
This index doesn't contain the id_group1 column, so a probe of the base 
row would always be needed. A sequential scan of the heap would be 
faster than a series of probes.

(id_group1)
  

Same situation for this index.

(id, id_group1)
  
This is a covering index for the query. That is, it carries both of the 
columns you need. That eliminates the need for probes of the heap. 
However, the index is not in the order you want (sorted by the grouping 
column). So an expensive sort would be needed.

but postgresql announced a sequential table scan every time and, in
fact, seemed to have done exactly that when I executed the query.
  

Have you tried

( id_group1, id )

This index covers your query and is in a useful sort order. If Derby 
does not use this index on your large data set, then there may be a bug. 
It would be interesting to see the query plan which Derby follows when 
you have declared this index.


Hope this helps,
-Rick

Either I'm doing something obviously wrong or am assuming something
obviously impossible is possible, but I'm inclined to believe the
former, rather than the latter which is why I'm writing. :-)

Cheers,
Tomislav
  




Re: performance, memory consumption...and a big hello :)

2009-07-27 Thread Rick Hillegas

Hi Tomislav,

Some comments inline...

Tomi N/A wrote:

Hi everyone,

first of all, it's great to have a RDBMS like derby around!
Now, on to the 2 problems I'm trying to resolve...

Situation: 1 table, 15+ million rows, 4 integer values (id, id_group1,
id_group2, id_group3), 750MB size on disk, derby in network mode

Problem 1:

select id_group, count(id)
group by id_group
  
Not to be tiresome, but just to make sure we understand the query: I 
think you mean id_group1 instead of id_group.

This takes a couple of minutes, basically regardless of what I tried
with indexes. I'd like it to take 10s if possible.

Problem 2:

It seemed to me that the query triggers a sequential scan (I see a lot
of disk activity) and so I created a disk in memory and restored the
database to this disk, expecting the query to be close to
instantaneous. Better, but still horrible (80 sec).
Which brings me to the crux of the 2nd problem: this in-memory
exercise was without indexes, so I tried to create some (id_group1 and
id for a start). However, the indexes seem to be _huge_ at 300-400MB
each and spike at about 700MB before the index is completely created -
I was quite surprised to see the indexes ttake more than several dozen
MB.
So, is there a way to reduce index size? And would any kind of indexes
help the type of query I'm interested in?
  
It sounds as though you may have created an index on ( id_group1, id ). 
At first blush, I would expect that index to improve the performance. 
Did that not happen?


Thanks,
-Rick

(Machine: Ubuntu Jaunty, 1.7GHz Pentium M, 2GB RAM, 5400 rpm disk)

Thanks,
Tomislav

--
www.PanBI.org: business intelligence everywhere!
  




Re: performance, memory consumption...and a big hello :)

2009-07-26 Thread Jan Kotek
Hi Tomi,

maybe give try to H2 database. For simple usages as yours I found it better.

Jan

On Fri, Jul 24, 2009 at 10:23 PM, Tomi N/Ahef...@gmail.com wrote:
 Hi everyone,

 first of all, it's great to have a RDBMS like derby around!
 Now, on to the 2 problems I'm trying to resolve...

 Situation: 1 table, 15+ million rows, 4 integer values (id, id_group1,
 id_group2, id_group3), 750MB size on disk, derby in network mode

 Problem 1:

 select id_group, count(id)
 group by id_group

 This takes a couple of minutes, basically regardless of what I tried
 with indexes. I'd like it to take 10s if possible.

 Problem 2:

 It seemed to me that the query triggers a sequential scan (I see a lot
 of disk activity) and so I created a disk in memory and restored the
 database to this disk, expecting the query to be close to
 instantaneous. Better, but still horrible (80 sec).
 Which brings me to the crux of the 2nd problem: this in-memory
 exercise was without indexes, so I tried to create some (id_group1 and
 id for a start). However, the indexes seem to be _huge_ at 300-400MB
 each and spike at about 700MB before the index is completely created -
 I was quite surprised to see the indexes ttake more than several dozen
 MB.
 So, is there a way to reduce index size? And would any kind of indexes
 help the type of query I'm interested in?

 (Machine: Ubuntu Jaunty, 1.7GHz Pentium M, 2GB RAM, 5400 rpm disk)

 Thanks,
 Tomislav

 --
 www.PanBI.org: business intelligence everywhere!



performance, memory consumption...and a big hello :)

2009-07-24 Thread Tomi N/A
Hi everyone,

first of all, it's great to have a RDBMS like derby around!
Now, on to the 2 problems I'm trying to resolve...

Situation: 1 table, 15+ million rows, 4 integer values (id, id_group1,
id_group2, id_group3), 750MB size on disk, derby in network mode

Problem 1:

select id_group, count(id)
group by id_group

This takes a couple of minutes, basically regardless of what I tried
with indexes. I'd like it to take 10s if possible.

Problem 2:

It seemed to me that the query triggers a sequential scan (I see a lot
of disk activity) and so I created a disk in memory and restored the
database to this disk, expecting the query to be close to
instantaneous. Better, but still horrible (80 sec).
Which brings me to the crux of the 2nd problem: this in-memory
exercise was without indexes, so I tried to create some (id_group1 and
id for a start). However, the indexes seem to be _huge_ at 300-400MB
each and spike at about 700MB before the index is completely created -
I was quite surprised to see the indexes ttake more than several dozen
MB.
So, is there a way to reduce index size? And would any kind of indexes
help the type of query I'm interested in?

(Machine: Ubuntu Jaunty, 1.7GHz Pentium M, 2GB RAM, 5400 rpm disk)

Thanks,
Tomislav

--
www.PanBI.org: business intelligence everywhere!


Re: Hello my dear Friend

2006-04-07 Thread Anders Morken
Michael Segel:
 Just out of curiosity, is anyone else getting this spam?

I got pretty much the exact same 419, yes. He used hotmail when I got
one, but apparently switched to yahoo before he sent one to you. =)

 Does Apache archive these mail groups on their site?
 Is it set up to stop robot trawlers from walking down these paths?

There are gmane archives here:
http://news.gmane.org/gmane.comp.apache.db.derby.user
And apache mod_mbox archives here:
http://mail-archives.eu.apache.org/mod_mbox/db-derby-user

The gmane archives seem to hide email addresses pretty well, but the
mod_mbox archives only hide (parts of) the email addresses in the web
view, the raw messages still contain real unchanged email addresses.

-- 
Anders Morken

My opinions may have changed, but not the fact that I am right!


Re: Hello i have some problem with database username and password can any one solve it

2005-11-15 Thread Jean T. Anderson

umakanth mandela wrote:

Hello,

I have been using derby and i want to set the password
for derby database.

it is accepting the password attribute 


but sencond time it is opening the database even if
provide the wrong password


Hi, Umakanth,

Authentication is off by default, which is why a wrong password works. 
Turn authentication on by setting this property:


   derby.connection.requireAuthentication=true

If you want to use Derby's built-in authentication, also set this:

   derby.authentication.provider=BUILTIN

Here are some references:

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

regards,

 -jean