Thomas Hill <[email protected]> writes:
> okay - true.
> I was however wondering and wanted to test whether I could replace a
> potentially in terms of performace more costly JDBC statement definition
> and result set processing of a 'select session_user from sysibm.sysdummy1'
or you could prepare a statement as 'VALUES SESSION_USER'.
> by an assumed less costly request of a property from a connection
> object
> I have at hand anway?
> Even if this would turn out to not be better in terms of performance, I
> think I would still like to understand how this getClientInfo() works.
> When using SQuirreL I can see a lot of connection properties / metadata
> displayed under their 'metadata' tab that I would suspect they are getting
> via such mechanisms.
> In the derby docs I am afraid one hardly finds details on the subject.
Derby doesn't support getClientInfo, it appears; I found this in the
code (abbreviated by me):
/**
* <code>getClientInfo</code> always returns an empty
* <code>Properties</code> object since Derby doesn't support
* ClientInfoProperties....
*/
public Properties getClientInfo() throws SQLException{
:
return new Properties();
}
I found only one reference in the reference manual, here:
http://db.apache.org/derby/docs/10.8/ref/rrefjdbc4_0databaseMetaData.html
"Capability reports - JDBC 4.0 adds new methods for querying the
capabilities of a database. These include
autoCommitFailureClosesAllResultSets, providesQueryObjectGenerator,
getClientInfoProperties, and supportsStoredFunctionsUsingCallSyntax. "
I believe "getClientInfoProperties" is a typo for getClientInfo.
Thanks,
Dag
