db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: Derby ClientDriver versus EmbeddedDriver and a question about the Eclipse plugin
Date Mon, 22 Aug 2005 22:58:26 GMT
Hi, Piet.  It's really quite easy to work with JIRA, just go to


And click on "Create a new issue in project Derby".  The fields should 
be pretty self-explanatory or have good defaults.



Piet Blok wrote:

> David,
> Thanks for your reply,
> From an earlier reply with links to already filed issues (Bernt M 
> Johnson) I found that my observation number two (different SQLStates) 
> has been noticed already. The other two I am not sure if they are 
> documented yet. The first one (Properties not being used by connect() 
> method) is in my opinion certainly a bug,. The third one I am not sure 
> of: it is certainly a strange sequence of actions (however, derby 
> embedded does not mind).
> I am certainly willing to create a Jira issue, but first I have to 
> find out exactly how to do this (sorry, I am not an experienced Open 
> Source Contributor, so certainly not this evening). If someone else, 
> more experienced than I, would do it, I appreciate it greatly. If 
> anyone wants me to send the java code that demontrates the behaviour, 
> no problem at all, I will send it right away.
> The question about the derby plugins has, to my great relief, been 
> answered quite satisfactory by Susan Cline. Thanks.
> Piet Blok
> ----- Original Message ----- From: "David Van Couvering" 
> <David.Vancouvering@Sun.COM>
> To: "Derby Discussion" <derby-user@db.apache.org>
> Sent: Monday, August 22, 2005 6:39 PM
> Subject: Re: Derby ClientDriver versus EmbeddedDriver and a 
> question about the Eclipse plugin
>> Hi, Piet.  We are working on recording and slowly resolving the
>> differences between the two drivers.  It would be *very* useful for you
>> to log these issues in JIRA.  Are you amenable to that?
>> Thanks,
>> David
>> Piet Blok wrote:
>>> Hi,
>>> I noticed some different behaviour between Derby EmbeddedDriver and
>>> ClientDriver. This was a disappointment, because I wanted to develop a
>>> Derby application that may switch between the two drivers.
>>> Differences I noticed are:
>>> 1) EmbeddedDriver accepts and uses a Properties object as the second
>>> parameter on the connect method. ClientDriver accepts, but does NOT
>>> USE the Properties object. A bug?
>>> 2) When an attempt is made to connect to a non-existing database (no
>>> attribute create=true) EmbeddedDerby throws an SQLException with
>>> SQLState "XJ004", ClientDriver "08004" (connection refused with
>>> additional text database does not exist). A bug?
>>> 3) ResultSet behaviour: When I execute, in this order,
>>> ResultSet.getMetaData(), then execute ResultSet. next() until it
>>> returns false, and then again execute ResultSet.getMetaData(),
>>> EmbeddedDriver does as requested, however, ClientDriver throws an
>>> SQLException at the last getMetaData() saying that the ResultSet has
>>> been closed. A bug or should this be expected?
>>>  (The reason for this strange sequence is the following: I wanted
>>> to create a JTable as follows: new JTable(createColumnData(resultset),
>>> createHeaderData(resultset)). Apparently this was processed by java
>>> from left to right. For EmbeddedDriver no problem.)
>>> I prepared a small (175 lines) piece of java code that
>>> demonstrates all three differences. If you wish I can send it.
>>> (I use the official release of derby:, JRE 1.5.0_04, and use
>>> Eclipse 3.1 to compile my classes. I have all the derby jar files in
>>> the EXT directory of the JRE)
>>> A question about the Eclipse plugins: I read the warning that these
>>> plugins can only be used in Eclipse 3.1 up to Milestone 6. Is there
>>> any chance that in the near future an official release of these
>>> plugins will be available for the official Eclipse 3.1 release? Yes, I
>>> also read the prescriptions on how to alter the plugins so they can be
>>> used with the official release but, having no experience at all with
>>> SubVersion, Ant, Plugin development and whatever needed to perform
>>> this alteration other than things working out opposite as expected, I
>>> decided to live without the plugin and wait.
>>> Piet Blok

View raw message