Here's an answer from Binod, one of our app server engineers...
Kathey Marsden wrote:
My goal is:
I want to use a specific version of Derby which I ship with my app and I
don't want to interfere with any other derby versions loaded in the
same JVM or have them interfere with me. I am creatin
Hi Kevin,
You might also try using a temporary table to split your scan up into a
series of optimzable queries. Regards-Rick
declare global temporary table session.accumulator
(
ObjectId int NOT NULL,
WordLocation int NOT NULL
)
not logged;
insert into session.accumulator
SELECT Object
Hi Kevin,
Kevin Hore wrote:
> i) Does anyone have any plans to fix this problem?
Can you file an enhancement request for this? I think Derby could
improve it's handling of OR/IN clauses. Many databases don't optimize OR
clauses as much as possible, though some do better than others. It would
be
Hi Thomas,
I got this to work using the following configuration:
Tomcat 5.5.9 with these edits to the server.xml file:
I placed the derby.jar file in
$TOMCAT_HOME/common/lib.
I added this entry to my web.xml:
jdbc/derby
javax.sql.DataSource
Container
I cr
I've described the problem in detail below, and I'd appreciate any
assistance. Specifically:
i) Does anyone have any plans to fix this problem?
I believe the real problem is that Derby doesn't have any strategy
for doing multiple scans for OR/IN clauses. This is a useful feature,
but I don
Hi Kevin,
I haven't investigated Derby-47 to know how to fix the problem but I do have an optimizer overrides patch waiting for review on the derby developer list which will let user specify their own optimizer properties to help the optimizer pick a specific plan. The JIRA entry for optimizer ov
Hi,
The error message does sound misleading in this case. Can you enter a JIRA entry to track this issue?
Mamta
On 11/11/05, Veaceslav Chicu <[EMAIL PROTECTED]> wrote:
create table acc.account(account_id integer not null,plan_id integer not null);create table
acc.trans(plan_id integer not nul
The Derby query optimizer (this is with 10.1.1.0) decides to perform an
expensive table scan in certain circumstances, when it could make use of
available indexes. The resulting poor performance is rendering Derby
useless for our application.
I believe that this behaviour might be related to D
create table acc.account
(
account_id integer not null,
plan_id integer not null
);
create table acc.trans
(
plan_id integer not null,
credit_id integer not null,
);
alter table acc.account add constraint account_pk primary key
(account_id, plan_id);
alter table acc.trans add constraint trans_cred
Hi Arieh,The situation is complicated if you run multiple statements using the same connection and don't exhaust the ResultSet before returning the connection to the pool.If all you are doing is insert/update/delete then the statements are essentially complete when they are executed. Just watch out
On 11/11/05, Susan Cline <[EMAIL PROTECTED]> wrote:
> I'm not sure I can help, but I'm wondering if there is another way to do
> what you are trying to accomplish. It sounds like you can only use the
> jdbc:derby:classpath protocol to connect to a database if it *is* contained
> in a jar file.
T
11 matches
Mail list logo
