Yes, it does sound like a bug. I'll log a JIRA
On Fri, Apr 30, 2010 at 6:50 PM, Bryan Pendleton bpendleton.de...@gmail.com
wrote:
As I mentioned to Knut, I try to issue a CREATE TABLE each time I connect,
and ignore the exception saying it already exists if the table is already
there.
If
what are the names of the new files after the transaction that
tried to create the existing table them commits? If they are still
c*.dat then there
is definitely something wrong. If they start with a different letter
then it could be that derby is acting as expected and just did not get
I am sorry to say I didn't save the database directory and have since worked
around the problem by checking to see if the table exists before creating
it, so I don't know the names of the files. If it's important, I'll comment
out my changes for now and recreate the problem and tell you what I'd
BTW, given that I as a user can check to see if a table already exists,
maybe the CREATE TABLE code could do the same, rather than rely on a unique
key violation?
On Mon, May 3, 2010 at 2:25 PM, Mike Matrigali mikem_...@sbcglobal.netwrote:
what are the names of the new files after the
Hi, all.
I have a thread that runs the following query every 10 seconds:
SELECT d.ITEMSET_ID, f.FILTER_INDEX, FROM FILTERS f, PENDING_DELIVERIES d
WHERE f.ITEMSET_ID = d.ITEMSET_ID AND f.FILTER_INDEX = d.FILTER_INDEX AND
d.SENT = 0 AND d.SERVER_ID = 1
The FILTERS table has about 200 rows in it,
On 30.04.10 23:38, David Van Couvering wrote:
Hi, all.
I have a thread that runs the following query every 10 seconds:
SELECT d.ITEMSET_ID, f.FILTER_INDEX, FROM FILTERS f, PENDING_DELIVERIES
d WHERE f.ITEMSET_ID = d.ITEMSET_ID AND f.FILTER_INDEX = d.FILTER_INDEX
AND d.SENT = 0 AND d.SERVER_ID
Thanks, Knut, I'd forgotten about that.
So, here are a couple of things I'm doing that may be causing problems:
- When I obtain a connection to to a database, I run a command to create the
tables, independent of whether they exist or not, and then ignore the
exception saying they already exist.
Note, however, it's when I get rid of the select statement that the database
growth stops. So it would seem that the transaction below is not the
culprit...
On Fri, Apr 30, 2010 at 3:32 PM, David Van Couvering
david.vancouver...@gmail.com wrote:
Thanks, Knut, I'd forgotten about that.
So,
On 4/30/2010 3:40 PM, David Van Couvering wrote:
Fun chatting with you guys! :)
Wonderful to see you back in the Derby community. Hope to see you back
on the dev list soon. :-)
That did it! When I added code to check to see if the table exists (using
DatabaseMetaData) before issuing the create table, the problem went away.
It appears that even though I get the exception saying the table doesn't
exist, Derby still creates hidden dat files that don't seem to get
removed.
10 matches
Mail list logo