Hi Rick,
Okay that helped .. YAYY!! I've been intending to swap to PreparedStatements
in my code but never really found the need to do so cos up until now the
performance of Statements has been pretty good. I guess I've found a reason
now ... :)
I guess I am going to read up a bit more about Pre
Hi Jay,
One issue which you may be seeing is that Derby incurs a noticeable burp
the first time that you compile a given SQL statement. If you use ?
parameters, then you will not see that burp the second time you try to
run that statement text. This is because Derby uses the statement text
as
Rick Hillegas-2 wrote:
> Hi Jay,
>
> You may be able to get the behavior you want by adding a DELETE trigger
> to child_info or to progeny. The trigger would fire a Java PROCEDURE to
> keep your tables in sync. For more information, please see the "CREATE
> TRIGGER statement" section of the
Iwud H8u wrote:
Hi Rick,
That is a good suggestion. I had originally envisaged a new row for each
child in the parent_info table. Your schema suggestion looks good expect,
when deleting a child record, I will now have to delete the parent from
parent_info after checking no other child has the sa
Hi Rick,
That is a good suggestion. I had originally envisaged a new row for each
child in the parent_info table. Your schema suggestion looks good expect,
when deleting a child record, I will now have to delete the parent from
parent_info after checking no other child has the same parent!
I am
Hi Jay,
I have a couple comments about your schema:
1) You don't need to create ChildIdIndex. This is because Derby creates
backing indexes for UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints.
For more information, please see the section titled "CONSTRAINT clause"
in the Derby Reference Guid
Michael Segel wrote:
>
> Since you're a bit cryptic..
>
> Hmm sorry I wasn't intending to be cryptic ... was trying not to be
> verbose!
>
> You are right about the column IDs ... lemme post the actual SQL
> statements for creating the tables themselves... nothing confidential in
> them I gu
Since you're a bit cryptic..
On Table A, you show Col_x_ID, but in your foreign key, you show Col_x. I'm
going to assume that you meant Col_x_ID.
On Table A, do you have an index on Col_x_ID? Is Col_x_ID a unique ID? If
so, is this the primary key for the table?
That would be the first
