Hi Raymond,
I'm not aware of a JDBC method which returns the information you need. I
ran your experiment on both 10.2 and the current trunk and verified your
results. The isClosed() method (which PreparedStatement inherits from
Statement and which was introduced in Java 6) returned false
Hi Gili,
Can you tell us what release of Derby is causing you problems? I built
the distributions for the following releases and I did not use Eclipse
to build any of these distributions. I believe that the release notes
for these distributions accurately reflect the environment that I used:
The version in question is 10.4.1.3.
Gili
Rick Hillegas-2 wrote:
Hi Gili,
Can you tell us what release of Derby is causing you problems? I built
the distributions for the following releases and I did not use Eclipse
to build any of these distributions. I believe that the release
Can you please refer him to this post?
Gili
Rick Hillegas-2 wrote:
Hi Gili,
I do not believe that Eclipse was used to build 10.4.1.3. However, the
definitive word would have to come from the 10.4.1.3 release manager,
Dyre Tjeldvoll.
Regards,
-Rick
cowwoc wrote:
The version
Hi Gili,
I have pinged him.
Regards,
-Rick
cowwoc wrote:
Can you please refer him to this post?
Gili
Rick Hillegas-2 wrote:
Hi Gili,
I do not believe that Eclipse was used to build 10.4.1.3. However, the
definitive word would have to come from the 10.4.1.3 release manager,
Dyre
Raymond Kroeker [EMAIL PROTECTED] writes:
My question is as follows; is there a generic (read jdbc) api I
can use to determine when a statement needs to be dumped from cache?
I think you can use ConnectionPoolDataSource in conjunction with
StatementEventListener to achieve what you want.
rigel wrote:
Hello, I would like to understand when and why is it useful to prefer
the DB2UDB jdbc driver instead DerbyClient to access a DERBY NETWORK
SERVER? Performance reasons or jdbc version implementation? Thanks for
attention, bye
Stanley Bradbury wrote:
With release 10.0 of Derby there was no open source client driver so the
DB2 driver was required to use Network Server. With Derby 10.1 the
Derby Client driver was introduced and the recommendation made everyone
use that client driver. This remains true today.
Knut,
I initially thought that might be the case as well; however there
does not appear to be a way to prevent the driver from throwing the
error to the application; which would be required.
Raymond
On Mon, Jul 28, 2008 at 14:37, Knut Anders Hatlen [EMAIL PROTECTED] wrote:
Raymond Kroeker
Alan Burlison wrote:
Stanley Bradbury wrote:
With release 10.0 of Derby there was no open source client driver so
the DB2 driver was required to use Network Server. With Derby 10.1
the Derby Client driver was introduced and the recommendation made
everyone use that client driver. This
10 matches
Mail list logo
