Kathey Marsden wrote:
Mike Matrigali wrote:
I would rather wait for an approved standard so that we don't later
get caught with apps depending on a non-standard behavior that we
might want to change in the future to meet a standard.
From the provided info it does not even look like there is
Rick Hillegas wrote:
I think that this discussion has gotten seriously off-track. It is the
intent of the standard that the offset and window length values be
parameterized. This is clear from the standard language and I
confirmed this with the SQL committee in May. For the record, Lance
Hi Rick,
JSR 169, removes some interfaces and methods on interfaces (example
Array and ResultSet.getArray(), Connection.getTypeMap())
Rick Hillegas wrote:
I am trying to figure out what is the difference between jsr169 and
jdbc3 which requires that we use the small platform jars in order to
+1
Dyre Tjeldvoll wrote:
Rick Hillegas wrote:
Please vote on whether we should make V. Narayanan a Derby committer.
The polls close at 5:00 pm San Francisco time on Thursday April 10.
For several years, Narayanan has contributed valuable features and
fixes to Derby, starting with JDBC4 and
Yes, it was an EG decision to correct the javadocs for setFetchSize()
as if there is no limit specified via setMaxRows(), getMaxRows()
returns 0 thus using:
0 = |rows| = |this.getMaxRows()|
can be problematic depending on implementations.
Also setFetchSize is a hint and can be ignored
+1
Manjula Kutty wrote:
+1
Manjula
On 3/26/08, *Knut Anders Hatlen* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Daniel John Debrunner [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] writes:
John is actively involved on both the derby-dev and derby-user lists
and fully
+1
Rick Hillegas wrote:
Rick Hillegas wrote:
Please vote on whether we should make Kim Haase a committer. The vote
will close at 5:00 pm San Francisco time on Monday March 10.
Kim has made an outstanding contribution to Derby's documentation
effort. With commit privileges, she will be even
Perhaps this is an indication that we need to revisit the layout of the
manuals to make them easier to use and put this as a high priority for
things to address going forward. If the documentation is difficult to
navigate, this can be a turnoff to users.
Regards
lance
John Embretsen wrote:
Kathey Marsden wrote:
Lance J. Andersen wrote:
Kathey Marsden wrote:
There was a discussion started in DERBY-401 on this but I thought I
would submit it as a separate thread. The JDBC 4.0 spec says in
section 8.5.1..
A NonTransient SQLException must extend the class
Kathey Marsden wrote:
Lance J. Andersen wrote:
Kathey Marsden wrote:
There was a discussion started in DERBY-401 on this but I thought I
would submit it as a separate thread. The JDBC 4.0 spec says in
section 8.5.1..
A NonTransient SQLException must extend the class
Kathey Marsden wrote:
There was a discussion started in DERBY-401 on this but I thought I
would submit it as a separate thread. The JDBC 4.0 spec says in
section 8.5.1..
A NonTransient SQLException must extend the class
SQLNonTransientException. A NonTransient SQLException would be thrown
, but for now i would just return a SQLException.
Daniel John Debrunner wrote:
Kathey Marsden wrote:
Lance J. Andersen wrote:
perhaps it is worth going back to DRDA and asking them where/how
they came up with that class value?
I put a query into the one DRDA contact I have but unfortunately he
+1
Rick Hillegas wrote:
+1
Rick Hillegas wrote:
Please vote on whether we should make Dyre Tjeldvoll a committer. The
vote will close at 5:00 pm San Francisco time on Monday September 17.
Since 2005 Dyre has submitted many patches and fielded questions on
the mailing lists. His
fwiw,
for JDBC.next i am looking at adding support for time and timestamp with TZ.
-lance
Daniel John Debrunner (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DERBY-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523890 ]
Daniel John Debrunner
+1
Knut Anders Hatlen wrote:
Rick Hillegas [EMAIL PROTECTED] writes:
Please vote on whether we should make Øystein Grøvlen a committer. The
vote will close at 5:00 pm San Francisco time on Tuesday August 28.
+1
Perhaps you are looking for:
http://db.apache.org/derby/integrate/index.html
http://wiki.apache.org/db-derby/
http://db.apache.org/derby/manuals/index.html
Julius Stroffek wrote:
Hi All,
I think there used to be a papers section somewhere on Apache Derby
website. However, I am not able
i can probably assist if needed.
Rick Hillegas wrote:
Hi Derby dev folks,
At this year's Java One, Derby will have some slots in the .orgZone.
I've included a schedule below. This is in addition to the related
presence of Java DB and Cloudscape in the Sun and IBM booths.
I'm looking for
Kim,
I would leave out a reference to
An alternative to the DriverManager facility, a DataSource object is the
preferred means of getting a connection.
This is old crud that i did not get a cycle to remove based on when i
was allowed to do putbacks to the javadocs.
-lance
Kim Haase
Kim Haase wrote:
Lance J. Andersen wrote:
Kim,
I would leave out a reference to
An alternative to the DriverManager facility, a DataSource object is
the preferred means of getting a connection.
This is old crud that i did not get a cycle to remove based on when i
was allowed to do
There is nothing magic about Derby's implementation of a DataSource.
If i could suggest making a quick scan of DataSource overview in the
JDBC spec as this will give you an overview of how a DataSource is used
in conjunction with JNDI.
Laura Stewart (JIRA) wrote:
[
The comment WRT borrowing is to review the wording and paraphrase from it.
You are right, you cannot take it verbatim... sorry if that was not clear.
Daniel John Debrunner (JIRA) wrote:
[
+1
Knut Anders Hatlen wrote:
Rick Hillegas [EMAIL PROTECTED] writes:
Please vote on whether we should make Dag Wanvik a Derby
committer. The vote will close at 5:00 pm San Francisco time on Monday
March 19.
+1
i would recommend returning false as this returned result is not tied to
an updatable ResultSet but to whether you can definitively determine the
column cannot be modified. This is a JDBC 1.0 method.
Regards
Lance
Kathey Marsden wrote:
Client and embedded differ for isReadOnly. The javadoc
Does anyone have an idea as to why the gobal table cannot be found.
Here is the trace output.
Regards
lance
[TopLink Fine]:
ClientSession(12549034)--Connection(16309502)--Thread(Thread[AWT-EventQueue-0,6,main])--DECLARE
GLOBAL TEMPORARY TABLE session.TL_CMP3_EMPLOYEE (EMP_ID INTEGER NOT
.
I think it will be worth checking the script under embedded Derby to
rule out Network Server as the culprit.
Mamta
On 2/23/07, *Lance J. Andersen* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Does anyone have an idea as to why the gobal table cannot be found.
Here
If the JDBC spec does not indicate that the parameter accepts a pattern
for the value, then i would suggest you only support patterns where it
is required. It is possible tests could be added to do additional
validation of parameters passed into API methods in future TCKs for
conformance.
I agree with David on this that policy files are painful.
David Van Couvering wrote:
Rick Hillegas (JIRA) wrote:
2) Unfamiliar api. Oracle, DB2, Postgres, and MySQL all handle system
privileges in different ways. Picking one of these models would still
result in an api that's unfamiliar
+1
Bryan Pendleton wrote:
I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED])
as a committer for Derby.
Myrna does great work.
+1
bryan
+1
Rick Hillegas wrote:
+1
Rick Hillegas wrote:
Please vote on whether we should make Kristian Waagan a Derby committer.
Kristian contributed significantly to the Derby JDBC4 effort. In my
opinion
1) His patches show consistently superior quality: they are well
thought out, well
If I am reading this thread correctly, I am not in favor of including an
*.exe as part of the base derby download. If you want to provide an
optional package, that is fine. Let us keep the base bundle pure Java.
Andrew McIntyre wrote:
On 10/18/06, Bryan Pendleton [EMAIL PROTECTED] wrote:
The following wording was added to the JDBC 4.0 javadocs to address
this issue:
Note: Not all databases allow for a non-typed Null to be sent to
the backend. For maximum portability, the setNull or the setObject(int
parameterIndex, Object x, int sqlType) method should be used
instead of
It is definitely a bug Dan if it has not been resolved.
If you feel the section in the spec could be clearer, please let me
know as i have a small window to clarify this area.
-lance
Daniel John Debrunner wrote:
Vemund Ostgaard wrote:
Daniel John Debrunner wrote:
Daniel John Debrunner wrote:
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
It is definitely a bug Dan if it has not been resolved.
If you feel the section in the spec could be clearer, please let me know
as i have a small window to clarify this area
2 - Regarding the Mustang and JDBC 4 issue, my general opinion is that
if Mustang is still coming out in October then it may be worth it to
continue on our current path and do a release that includes JDBC 4.
If Mustang is delayed, then I think it's just time to get 10.2 done to
get some
That is correct. Java SE ships and will continue to ship the Rowset RI.
-lance
Bernt M. Johnsen wrote:
Harri Pesonen wrote:
Since Sun is apparently removing CachedRowSetImpl from JDK (warning:
com.sun.rowset.CachedRowSetImpl is Sun proprietary API and may be
removed in a future
Daniel John Debrunner wrote:
The SQL standard says that SQL State '42' is for syntax error or access
rule violation (section 23.1).
JDBC 4.0 states in section 6.5.1 that TABLE 6-1 specifies which
NonTransientSQLException subclass must be thrown
for a a given SQLState class value: and Table
The javadoc SQLSyntaxErrorException for says:
The subclass of SQLException thrown when the SQLState class value is
'42'. This indicates that the in-progress query has violated SQL syntax
rules.
This somewhat in-conflict with the SQL Standard.
Can a JDBC driver thrown an exception with
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
Daniel John Debrunner wrote:
The SQL standard says that SQL State '42' is for "syntax error or access
rule violation" (section 23.1).
JDBC 4.0 states in section 6.5.1 that "TABLE 6-1
Knut Anders Hatlen wrote:
Sunitha Kambhampati [EMAIL PROTECTED] writes:
I was looking at the test results from last weekend (09/01) on our
test machines and I see the following failures on jdk1.6.
derbyall/derbyall.fail:jdbc4/TestQueryObject.java
perhaps it is an XP or Win95 issue?
Andrew McIntyre wrote:
On 8/24/06, Rick Hillegas [EMAIL PROTECTED] wrote:
The following line in setEmbeddedCP.bat raises errors if there are
spaces in the path identified by DERBY_HOME or DERBY_INSTALL:
@FOR %%X in (%DERBY_HOME%) DO SET DERBY_HOME=%%~sX
These changes were put back a while ago and rick made an integration
for this into the derby codeline.
There will be one more change to Types.java i believe in order to
prevent a collision for a large number of users of a specific database
due to their own types colliding with the JDBC
Hi David,
There were changes in this area to the DatabaseMetaData and it looks
like this test might not have caught up to it.
-lance
David Van Couvering wrote:
I am running with the latest drop from the jdk 1.6 site, and I have
the latest stuff from the trunk, and I am getting the following
This has been a requirement since JDBC 1.0 and at there are no plans to
change this given the complexity of the autocommit issue with various
vendors. It is expected the applications that are well behaved will
know what mode they are in and invoke the correct methods.
-lance
Daniel John
I updated the JDBC 4 spec data conversion tables for Short and Byte so
I would add support for them when u can
-lance
Markus Fuchs (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1500?page=comments#action_12424627 ]
Markus Fuchs commented on DERBY-1500:
I am not sure why java.lang.Short is not covered in the conversion
tables in the JDBC spec. Probably an oversite or just a spec bug. It
is reasonable to be supported since the other conversions are
supported.
I will discuss with the EG.
Markus Fuchs (JIRA) wrote:
[
Craig Russell (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12424673 ]
Craig Russell commented on DERBY-1516:
--
Including the discussion from the alias referenced immediately above:
Rick Hillegas wrote:
I would like to understand how the community influences the standards
which govern Derby:
1) SQL - I've been participating in Derby for a year now. Over the
past year I don't recall any discussion about a need to change the SQL
standard. We have proposed new language
Daniel John Debrunner wrote:
Rick Hillegas wrote:
I would like to understand how the community influences the standards
which govern Derby:
1) SQL - I've been participating in Derby for a year now. Over the past
year I don't recall any discussion about a need to change the SQL
Amit,
Didn't u fix this already?
Please see the attached
Daniel John Debrunner (JIRA) wrote:
JDBC 4 EoD with default QueryObjectGenerator fails with SecurityManager
Key: DERBY-1540
btw, did you try this with Beta2 of Mustang as i would be surprised if
this fails as Rick worked with Amit on this earlier.
Lance J. Andersen wrote:
Amit,
Didn't u fix this already?
Please see the attached
Daniel John Debrunner (JIRA) wrote:
JDBC 4 EoD with default QueryObjectGenerator
Daniel John Debrunner wrote:
Kristian Waagan wrote:
Hello,
I just discovered that we are having problems with the length less
overloads in the embedded driver. Before I add any Jiras, I would like
some feedback from the community. There are for sure problems in
Daniel John Debrunner wrote:
Kathey Marsden wrote:
Another similar case is DERBY-1501 where it
would be nice if Derby were more forgiving of non-portable apps. Of
course in both of those other cases we would just be adding to existing
support, not changing existing behavior
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
With 1501 the JDBC spec says the type must be known (I think it's a bug
in the *draft* spec for the type to be ignored), that's the portable
behaviour, ignoring the type not only leads to non-portable applications
i have removed the rogue sentence in its entirety from the javadocs for
setNull(int,int, String) as it is not needed and is not correct in
regards to typeCode.
-lance
Daniel John Debrunner (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1501?page=comments#action_12420620 ]
I discussed this briefly at my JDBC EG meeting yesterday.
As i expected, all of the vendors on the call indicated that they return
the same data type for key returned in the case of column defined as
identity via the getGeneratedKeys() method. The consensus was that this
is what a user would
:
Lance J. Andersen wrote:
I discussed this briefly at my JDBC EG meeting yesterday.
As i expected, all of the vendors on the call indicated that they return
the same data type for key returned in the case of column defined as
identity via the getGeneratedKeys() method. The consensus
I am not sure why the wording was added to the overloaded setNull
method which was added in JDBC 3.
i probably would expect it to not ignore the specified sql type in
order to make sure the action requested is valid. I would have to
check the SQL standard and discuss this with the EG
Kathey Marsden wrote:
Lance J. Andersen wrote:
This issue pointed out a problem in the JDBC EoD RI which made the
assumption that the value returned matched the column type in the
base table.
A Derby user encountered this issue as well, trying to use 10.2 and
JDBC EoD http
It's not entirely clear to me that Derby is not compliant.
I do not believe i indicated it was or was not compliant, my point was
is the data type is not what i would expect returned in this scenario.
The ResultSetMetaData does correctly described the number, type and
properties of the
No it is not.
Kathey Marsden wrote:
Is Derby, JavaDB or something else the JDBC reference implementation
these days?
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
1) Is this a bug? Should Statement.getGeneratedKeys() return a
ResultSet whose column has the same type as the underyling
autogenerated column?
Reading from the JDBC 3.0 and JDBC 4.0 spec it seems clear to me
that we are
To me this is a problematic issue as i would expect the return type for
the keys to match the datatype of the column.
Rick Hillegas wrote:
I would like the community's advice on whether the following Derby
behavior is a bug and, if so, whether we would be allowed to change
this behavior for
Kathey Marsden wrote:
Rick Hillegas wrote:
Hi Kathey,
My gut feeling is that changing this behavior could affect
applications like ij which make formatting decisions based on the
JDBC types of returned columns.
If you return the correct column type of the base type, then the
formatting
These seem reasonable. On the other hand, using getGeneratedKeys() to
determine the type name of a table's generated key seems very very
unlikely to me. It would require that the application/tool can insert a
row of the correct shape, if the app/tool can do that, then it probably
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
Certainly there are these changes for the ResultSet returned by
getGeneratedKeys():
o getMetaData() would correspond
July towards the middle (after the Sun shutdown)
Andrew McIntyre wrote:
On 6/30/06, Rick Hillegas [EMAIL PROTECTED] wrote:
1) Lance will publish his proposed final draft (PFD) of the JDBC4 spec
under the early access license.
Is there a rough time frame for this, considering it's the gating
Geir Magnusson Jr wrote:
Andrew McIntyre wrote:
On 6/23/06, Daniel John Debrunner [EMAIL PROTECTED] wrote:
In #2 of his proposed solution, Geir said he doesn't believe that
Derby qualifies as an implementation, and thus would not be affected
by the
Daniel John Debrunner wrote:
Andrew McIntyre wrote:
Call in the lawyers:
From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board
has executed, being a JCP Member (they've even got quotes from Geir
prominently featured on their
David Van Couvering wrote:
Lance J. Andersen wrote:
You cannot have a GA version of a JDBC 4 driver until JSR 221 goes
final.
Are you *sure* you can't *have* a GA version, e.g the bits can't exist
somewhere, as long as they're not officially declared generally
available? If we can't
hi guys
Rick Hillegas wrote:
Hi David,
I had a couple more comments on the compatibility commitments.
Cheers-Rick
- Changes to stored procedures: We will have to change column order if
we add Derby-specific columns to a metadata ResultSet and then a later
JDBC also adds more columns.
Anurag Shekhar (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1341?page=comments#action_12414483 ]
Anurag Shekhar commented on DERBY-1341:
---
I was wrong about life time of lob. It is supposed to restricted only for the transaction
this is in the javadocs for jdbc 4.0
Andrew McIntyre wrote:
On 5/24/06, Lance J. Andersen [EMAIL PROTECTED] wrote:
This is what we discussed in the EG and agreed to in this regards
consider a Clob, aClob, containing the following value for each
setString() invocation below.
ABCDEFG
This method was not added in JDBC 4, it was added in JDBC 3 (I would
have picked a more articulate name as i find the name a bit confusing as
do others)
Rick Hillegas (JIRA) wrote:
Wrong value returned by DatabaseMetaData.locatorsUpdateCopy()
Hi Rick,
All DatabaseMetaDataMethods must be implemented. Unfortunately the
previous authors of the spec did not take into account that some
backends do not support LOB so this should not have been a boolean.
I would probably return true as Derby is not locator based.
Rick Hillegas
Rick Hillegas wrote:
Hi Lance,
I agree with Knut Anders' interpretation of the javadoc for
java.sql.Statement. He is investigating how executeQuery() and
executeUpdate() should behave when the query text invokes a stored
procedure:
1) executeQuery() should raise an error if the
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
Very simple, just because it is deprecated, it does not mean it can be
ignored. Bottom line, it is required to be there.
According to which section of JDBC 3.0?
Dan.
the time to make this clearer.
If your driver or backend does not support the datatype then all
methods on the interface must throw SQLFeatureNotSupportedException for
JDBC 4 and SQLException for JDBC 3.
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
The compliance chapter has
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
The compliance chapter has seen significant clarifications for JDBC 4 to
clarify what is and is not required. If you implement and interface for
a data type such as blob/clob all methods must be implemented otherwise
you do
DJD question According to which section of JDBC 3.0?
Then this is about JDBC 4.0 compliance and not JDBC 3.0.
yes and no, the intent has always been there just not clear in print
If you feel more comfortable stating this is JDBC4 so be it, but again
the intent has always been
Just to be clear, this requirement has been part of the J2EE
specification since 1999. It is not new.
JDBC 4 is migrating the section from the J2EE spec WRT J2EE jdbc
requirements to the JDBC spec and future Java EE specs will refer to
this chapter for requirements.
-lance
Rick Hillegas
I really do not want a war of words here as it serves zero purpose.
Methods that are deprecated are never guaranteed to be removed though it
is possible they could. There are no plans to remove any methods that
are deprecated from JDBC and going forward unless there is a method that
is
Daniel John Debrunner (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1288?page=comments#action_12377843 ]
Daniel John Debrunner commented on DERBY-1288:
--
What's the required behavior when a update count or multiple result
Daniel John Debrunner (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1288?page=comments#action_12377874 ]
Daniel John Debrunner commented on DERBY-1288:
--
dan If multiple result sets are returned when should any error be
Very simple, just because it is deprecated, it does not mean it can be
ignored. Bottom line, it is required to be there.
There are no plans to remove these methods from JDBC.
Daniel John Debrunner (JIRA) wrote:
[
The compliance chapter has seen significant clarifications for JDBC 4
to clarify what is and is not required. If you implement and interface
for a data type such as blob/clob all methods must be implemented
otherwise you do not support the data type.
Daniel John Debrunner (JIRA) wrote:
If you support a data type such as Blob/Clob, you must implement all
methods on the interface, not pick and choose.
If your backend does not support the data type, then all methods should
throw SQLFeatureNotSupportedException.
This was a problem in the earlier JDBC specs as it did not
for quite some time now. Lack of support will make it
much more difficult for users to migrate from other backends which
support those data types to Derby.
[EMAIL PROTECTED] wrote:
"Lance J. Andersen" [EMAIL PROTECTED] writes:
If you support a data type such as Blob/Clob
paramName) and
setXXX( String paramName, FOO paramValue )
Is this asymmetry OK or do you think that methods in the second block
are mandatory when the corresponding methods in the first block work?
Thanks,
-Rick
Lance J. Andersen wrote:
Hi Dyre,
yes that is correct, if you are supporting
This is required.
Daniel John Debrunner (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1253?page=comments#action_12376549 ]
Daniel John Debrunner commented on DERBY-1253:
--
Is this mandatory/optional method scheme discussed in
Daniel John Debrunner (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1253?page=comments#action_12376549 ]
Daniel John Debrunner commented on DERBY-1253:
--
Is this mandatory/optional method scheme discussed in the JDBC 4.0
Hi Rick,
once the serialVerisonUID is there, you should not remove it as chaos
can break out if the IDs start to differ. IMHO would leave them alone.
One example is you have say someone using say derby version x with a an
ID of 1 and then persisted the object... now u remove the ID in derby
or b) the serialVersionUID isn't changed and
deserialization fails because the new field is missing from the
persisted stream. Hopefully we don't mean for these objects to
persist across Derby upgrades. Hard to tell from the code.
Regards,
-Rick
Lance J. Andersen wrote:
Hi Rick,
once
Knut Anders Hatlen (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-941?page=comments#action_12375102 ]
Knut Anders Hatlen commented on DERBY-941:
--
V.Narayanan commented on DERBY-941:
---
Just to be clear, the Proposed Final Draft is NOT available, to the JCP
community at this time. We are continuing to work on polishing the
specification up as we move closer to the release of mustang.
Daniel John Debrunner wrote:
David W. Van Couvering wrote:
In inspecting the
This has been clarified in the JDBC 4.0 spec.
Again and i cannot say this often enough the tutorial and reference is
not to be deemed the end-all when it comes to JDBC. The spec consists
of the JDBC API javadocs and the PDF spec.
I am trying to correct as many issues that i can for JDBC
:
Lance J. Andersen wrote:
This has been clarified in the JDBC 4.0 spec.
Great, I couldn't see anything related to this in the JDBC 4.0 proposed
final draft, do you have a section number?
Thanks,
Dan.
It is not in the spec.
However, it should be TYPE_FORWARD_ONLY, CONCUR_READ_ONLY given the
design was done during the JDBC 1.0 timeframe for DatabaseMetaData and
ResultSetMetaData.
i will look to clarify for JDBC 4
-lance
Daniel John Debrunner wrote:
I known I've seen a statement
the default holdability is always implementation defined but that seems
reasonable if that is what u do by default anyways with derby
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
It is not in the spec.
However, it should be TYPE_FORWARD_ONLY, CONCUR_READ_ONLY given
If it is deemed to be the wrong SQLState, then you should fix it.
My experience is JDBC developers are more focused on the Exception and
if they check further they often dig into the vendor error. This was a
reason we added the SQLException sub classes to help aid in better
portability.
If
David W. Van Couvering wrote:
It sounds like your vote is that the SQL States be marked Unstable,
not Stable.
David
Lance J. Andersen wrote:
If it is deemed to be the wrong SQLState, then you should fix it.
My experience is JDBC developers are more focused on the Exception
and if they check
1 - 100 of 215 matches
Mail list logo
