Oracle 5.0 Reference Manual page 2086

loadBalanceEnableJMX
sessionVariables
useColumnNamesInFindColumn Prior to JDBC-4.0, the JDBC specification had a
allowNanAndInf
autoClosePStmtStreams
autoDeserialize
blobsAreStrings
capitalizeTypeNames
clobCharacterEncoding
clobberStreamingResults
compensateOnDuplicateKeyUpdateCounts
Connector/J (JDBC) Reference
The regex must follow the patterns used for the
java.util.regex package.
Enables JMX-based management of load-
balanced connection groups, including live
addition/removal of hosts from load-balancing
pool.
A comma-separated list of name/value pairs to be
sent as SET SESSION ... to the server when the
driver connects.
bug related to what could be given as a "column
name" to ResultSet methods like findColumn(),
or getters that took a String property. JDBC-4.0
clarified "column name" to mean the label,
as given in an "AS" clause and returned by
ResultSetMetaData.getColumnLabel(), and
if no AS clause, the column name. Setting
this property to "true" will give behavior
that is congruent to JDBC-3.0 and earlier
versions of the JDBC specification, but which
because of the specification bug could give
unexpected results. This property is preferred over
"useOldAliasMetadataBehavior" unless you need
the specific behavior that it provides with respect
to ResultSetMetadata.
Should the driver allow NaN or +/- INF values in
PreparedStatement.setDouble()?
Should the driver automatically call .close() on
streams/readers passed as arguments via set*()
methods?
Should the driver automatically detect and de-
serialize objects stored in BLOB fields?
Should the driver always treat BLOBs as Strings
- specifically to work around dubious metadata
returned by the server for GROUP BY clauses?
Capitalize type names in DatabaseMetaData?
(usually only useful when using WebObjects, true/
false, defaults to 'false')
The character encoding to use for sending and
retrieving TEXT, MEDIUMTEXT and LONGTEXT
values instead of the configured connection
characterEncoding
This will cause a 'streaming' ResultSet to be
automatically closed, and any outstanding data
still streaming from the server to be discarded if
another query is executed before all the data has
been read from the server.
Should the driver compensate for the update
counts of "ON DUPLICATE KEY" INSERT
statements (2 = 1, 0 = 1) when using prepared
statements?
2066
false 5.1.13
3.1.8
false 5.1.7
false 3.1.5
false 3.1.12
false 3.1.5
false 5.0.8
true 2.0.7
5.0.0
false 3.0.9
false 5.1.7