[jira] Commented: (DERBY-1002) Check that DRDAStatement and DRDAResultSet states are reset when they are re-used
[ http://issues.apache.org/jira/browse/DERBY-1002?page=comments#action_12415957 ] Andrew McIntyre commented on DERBY-1002: This has been partially fixed in 10.1.3. I'm thinking the right thing to do is mark it affects 10.1.3, then move the FixIn for the issue out to 10.1.4 and make a note of the partial fix in the release notes. Unless anyone has any objections, that's the course I'll take when putting together the release notes. > Check that DRDAStatement and DRDAResultSet states are reset when they are > re-used > - > > Key: DERBY-1002 > URL: http://issues.apache.org/jira/browse/DERBY-1002 > Project: Derby > Type: Bug > Components: Network Server > Reporter: Deepa Remesh > Fix For: 10.2.0.0, 10.1.3.0 > Attachments: derby1002-patch1-draft1.diff, derby1002-patch1-draft1.status, > derby1002-patch1-v1.diff, derby1002-patch1-v1.status, > derby1002-patch2-v2.diff, derby1002-patch2-v2.status, derby1002.java > > Network server re-uses DRDAStatement and DRDAResultSet objects when client > sends a request with same section number. When re-using DRDAStatement, it's > close() method is called which inturn calls close() method of DRDAResultSet. > For re-use to work properly, we have to ensure the states of these objects > are reset. This is not a bug but it is an area for possible improvements like: > * The reset of all states are not in the close() methods. The states get > re-initialized at different places in the code. Fo example, in case of > DRDAResultSet, they get initialized in some other DRDAStatement methods - > like addResultSet, setRsDefaultOptions, setOPNQRYOptions, setQueryOptions > etc. It will be good to have all resets in one method. > * The method name "close" is confusing since it is also called when objects > get re-used. For clarity, it may be good to have a method named reset(). And > then have the close method call reset. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1394) Working With Derby - Introduction and prerequisites - Improvements
[ http://issues.apache.org/jira/browse/DERBY-1394?page=all ] Andrew McIntyre updated DERBY-1394: --- Fix Version: 10.2.0.0 (was: 10.1.2.4) Version: 10.2.0.0 (was: 10.1.2.4) Move this issue out to 10.2. Working With Derby is not in the 10.1 doc branch. > Working With Derby - Introduction and prerequisites - Improvements > -- > > Key: DERBY-1394 > URL: http://issues.apache.org/jira/browse/DERBY-1394 > Project: Derby > Type: Improvement > Components: Documentation > Versions: 10.2.0.0 > Environment: DITA-sourced documentation > Reporter: Halley Pacheco de Oliveira > Priority: Minor > Fix For: 10.2.0.0 > Attachments: twwdIntro.diff, twwdIntro.diff.html, twwdIntro.html > > 1) There is a gramatical error: > It's written "sections" and not "section": > "In way of introduction this sections provides a brief description of Derby." > and should be, in my opinion: > "In way of introduction this section provides a brief description of Derby." > 2) DERBY_HOME > It's written: > "Note the filesystem path to the Derby installation (referred to as > DERBY_HOME)." > but DERBY_HOME doesn't appear anywhere else in this page, so it is not > possible > to note it in this page. It only appears in the activities pages. By this > reason, > in my opinion, the sentence should be: > "Note the filesystem path to the Derby installation (referred to as > DERBY_HOME) in the activities sections." > 3) Commas could be used to make some sentences shorter: > === > - "Derby is a full featured, open source relational database engine that is > written and implemented completely in Java." > into > + "Derby is a full featured, open source, relational database engine, that is > written and implemented completely in Java." > === > - "It provides users with a small footprint, standards-based Java database > that can be tightly embedded into any Java based solution." > into > + "It provides users with a small footprint, standards-based, Java database, > that can be tightly embedded into any Java based solution." > === > - "In it's default configuration there is no separate database server to be > installed or maintained by the end user." > into > + "In it's default configuration, there is no separate database server to be > installed or maintained by the end user." > === > - "This document demonstrates but does not teach the Java, JDBC and SQL > presented so readers wishing a deeper understanding of these topics will need > additional reference materials." > into > + "This document demonstrates, but does not teach, the Java, JDBC and SQL > presented, so readers wishing a deeper understanding of these topics will > need additional reference materials. > === > - "If unsure about the Java or Derby environments installed perform the > following steps before attempting the subsequent activities:" > into > + "If unsure about the Java or Derby environments installed, perform the > following steps before attempting the subsequent activities:" > === > - "The output you see may be different from what is shown here because the > java -version command outputs vendor-specific information." > into > + "The output you see may be different from what is shown here, because the > java -version command outputs vendor-specific information." > === > - "If the command produced an error or the version listed is not 1.3 or > higher please install a Java development kit before continuing." > into > + "If the command produced an error or the version listed is not 1.3 or > higher, please install a Java development kit before continuing." > === > - "From the Downloads page use the link to the 'Latest Official Release' then > locate the bin distribution (e.g. db-derby-10.2.0-bin). Download the file and > unbundle the release." > into > + "From the Download page use the link to the 'Latest Official Release', then > locate the bin distribution (e.g. db-derby-10.2.0-bin). Download the file and > unbundle the release." > 4) Download the file and unbundle the release. > Is is not easy to understand what this sentence means. There are two files > for the binary distribution: -bin.zip and -bin.tar.gz > So the previous sentence could be changed to: > "From the Download page use the link to the 'Latest Official Release', then > locate the bin distribution (e.g. db-derby-10.1.2.1-bin.zip and > db-derby-10.1.2.1-bin.tar.gz). Download the appropriate file for your > platform, '-bin.zip' for Windows or '-bin.tar.gz' for Unix/Linux", and > unzip/untar this file. After decompressing the downloaded file, move the > directory created to the filesystem path choosed to be the root directory of > the Derby installation (e.g., move db-derby-10.1.2.1-bin C:\Derby) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contac
Re: [jira] Updated: (DERBY-959) Allow use of DRDA QRYDTA block sizes greater than 32K
Sunitha Kambhampati (JIRA) wrote: I am attaching a patch 'derby959.review.diff.txt' to get feedback on the server changes Hi Sunitha, this is great work! It's good to see that this may turn out to be a straightforward change. I didn't have time to read the traces yet, just read the notes and the diff. I'll try to look through it some more soon. Why did you pick 10 Meg as the new max value? Was that arbitrary, or does it derive from some other fundamental limit? thanks, bryan
Re: [Db-derby Wiki] Update of "MysqlDerbyMigration/RequirementDocument" by RaminMoazeni
A quick comment: I think this is great that we're gathering requirements, but before we delve down into specific functional requirements I'd like to see this described in terms of some use cases. What are the tasks that the user needs to accomplish. What will the user experience be like -- what specific steps and interactions will they have with the system? Will the user interface be command-line or GUI? What does the user need to specify prior to running the migration tool? What kinds of errors can occur? For a user-based tool such as this these types of task-based, user-oriented descriptions I think are crucial for guiding the actual functional requirements. Thanks! David Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification. The following page has been changed by RaminMoazeni: http://wiki.apache.org/db-derby/MysqlDerbyMigration/RequirementDocument -- This section describes the capability (functional) requirements of the proposed system. A capability requirement is a function that the proposed system must (be designed and implemented to) perform. All capability requirements are specified in a sufficiently concrete way that they can be implemented and tested. Table 15: Source and Target Database Management System + || Capability Requirement || '''PR-14: The conversion of data in the system from one format to another shall be reliable and accurate. ''' || + || Priority || The data migration from source DBMS to the target DBMS over network of machines or instances must not change the data and not corrupt the format. Also, the transaction must be atomic and task of the transfer of data from one end to the other must be achieved || + || Description || Must Have ||
-Dij. in doc should be -D ?
Hi, I was poking at the manual and I noticed that in the following: http://db.apache.org/derby/docs/10.1/tools/ttoolsij30600.html it is described that you can overwrite ij properties specified with the -p by using -Dij.. However, when I tried it, it looks as you need to specify -D, if you use the -Dij. nothing happens. For instance, if you create a file, myij.properties with contents: - ij.maximumDisplayWidth=5 - and then start ij with -p the Displaywidth is indeed 5 instead of the default (80, I believe, but whatever) -- java org.apache.derby.tools.ij -p myij.properties [...snip version...] ij> connect 'jdbc:db2j:bladb'; ij> select * from sys.systables where tablename like 'SYSCOLUMN%'; TABL&|TABL&|&|SCHE&|& - 8000&|SYSC&|S|8000&|R 1 row selected -- If I use -Dij.maximumDisplayWidth=15, the result is the same, but if I use -DmaximumDisplayWidth=15, the display width changes. - So... -- java org.apache.derby.tools.ij -p myij.properties [...snip version...] ij> connect 'jdbc:db2j:bladb'; ij> select * from sys.systables where tablename like 'SYSCOLUMN%'; TABLEID|TABLENAME |&|SCHEMAID |& --- 801e-00d0-&|SYSCOLUMNS |S|800d-00d0-&|R 1 row selected -- I assume this is intended behavior, and a doc bug... Can anyone confirm whether or not this is true for all ij properties by looking at the code? (Or I'll need to go an test all properties). I tried (ij.)database and (ij.)maximumDisplayWidth... Thx, Myrna
[jira] Commented: (DERBY-1326) Network server may abandon sessions when Derby system is shutdown and this causes intermittent hangs in the client
[ http://issues.apache.org/jira/browse/DERBY-1326?page=comments#action_12415929 ] Deepa Remesh commented on DERBY-1326: - Thanks again for posting a detailed description. I read through the description and patch "unify_NSImpl_instances.diff " quickly. I have few small comments/questions: * Currently, the patch does the following "Modify the DRDAServerStarter boot code so that it loads the embedded engine. " The description also mentions this: "an alternative would be to load the embedded engine in NetworkServerControlImpl.start()". I like this alternative. I am thinking of the scenario where derby.drda.startNetowrkServer property is set and we boot embedded driver. In this scenario, if we load the embedded engine in the DRDAServerStarter boot code, it will appear that we are trying to boot the embedded driver twice. However, this will not do any harm as it will be a no-op. I think it would be better to avoid doing this as it causes confusion why we are loading the driver again when we trace the path from loading embedded engine. * There is a slightly different code path when we start network server from the command line. In this case, we create an instance of NetworkServerControlImpl and then call executeWork which processes the "start" command by calling blockingStart(). There is no DRDAServerStarter involved here as we do not need to launch another thread. This is not very relevant for the current patch but just mentioning it in case we plan to re-organize the code. * It looks like the only purpose of calling DRDAServerStarter in NetworkServerControlImpl.start method is to launch a separate thread. The javadoc comment for NetworkServerControlImpl.start says: /** * Start a network server. Launches a separate thread with * DRDAServerStarter. Want to use Monitor.startModule, * so it can all get shutdown when cloudscape shuts down, but * can't get it working right now. >From current behaviour, we do not shutdown network server when we shutdown >Derby. Does anyone know if there is any plan to do as indicated by the >comment: "Want to use Monitor.startModule, so it can all get shutdown when >cloudscape shuts down, but can't get it working right now." ? > Network server may abandon sessions when Derby system is shutdown and this > causes intermittent hangs in the client > -- > > Key: DERBY-1326 > URL: http://issues.apache.org/jira/browse/DERBY-1326 > Project: Derby > Type: Bug > Components: Network Server > Reporter: Deepa Remesh > Assignee: Bryan Pendleton > Attachments: repro1326.java, resolve_DRDConnThread_conflict.diff, > sessionMgmt1.diff, sessionMgmt1_and_nosessionsforclosedthreads.diff, > unify_NSImpl_instances.diff, withNewThreadAndNoShutdownOfCurrentSession.diff > > This issue was found when working on DERBY-1219. More details can be found in > the comments at http://issues.apache.org/jira/browse/DERBY-1219 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1036) Embedded and client differ with regard to Statement.setCursor Name. client will disallow duplicate cursor names. Embedded will allow it.
[
http://issues.apache.org/jira/browse/DERBY-1036?page=comments#action_12415928 ]
Dag H. Wanvik commented on DERBY-1036:
--
The patch for DERBY-1183 may solve this issue.
> Embedded and client differ with regard to Statement.setCursor Name. client
> will disallow duplicate cursor names. Embedded will allow it.
> -
>
> Key: DERBY-1036
> URL: http://issues.apache.org/jira/browse/DERBY-1036
> Project: Derby
> Type: Sub-task
> Components: Network Client, JDBC
> Versions: 10.2.0.0, 10.1.3.0, 10.1.2.3
> Reporter: Kathey Marsden
> Assignee: Dag H. Wanvik
> Priority: Minor
>
> In looking at the checkDataSource test for DERBY-435, I hit an issue that the
> test fails with an exception for duplicate cursor name because it sets the
> cursor name for two statements to the same thing.
> Embedded seems to allow this, but it seems to me that client might be right
> here. How could embedded differentiate the two for positioned updates?
> There is risk to existing applications if embedded is changed to throw the
> error that should be considered if we decide we need to change the embedded
> behaviour.
> Below are some details from checkDataSource where I hit this. I will change
> the names for now as it does not seem relevant to what is being tested.
> PreparedStatement psruState = createFloatStatementForStateChecking(cs1,
> "select i from ru where i = ?");
> CallableStatement csruState = createFloatCallForStateChecking(cs1,
> "CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(?,?)");
> Both of these methods set the cursor name to the same thing:
> s.setCursorName("StokeNewington");
> For embedded it succeeds for client it throws the exception.
> java.sql.SQLException: Duplicate cursor names are not allowed.
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown
> Source)
> at org.apache.derby.client.am.Statement.setCursorName(Unknown Source)
> at
> org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource.createFloatStatementForStateChecking(Unknown
> Source)
> at
> org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource.runTest(Unknown
> Source)
> at
> org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource.main(Unknown
> Source)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1036) Embedded and client differ with regard to Statement.setCursor Name. client will disallow duplicate cursor names. Embedded will allow it.
[ http://issues.apache.org/jira/browse/DERBY-1036?page=all ]
Dag H. Wanvik reassigned DERBY-1036:
Assign To: Dag H. Wanvik
> Embedded and client differ with regard to Statement.setCursor Name. client
> will disallow duplicate cursor names. Embedded will allow it.
> -
>
> Key: DERBY-1036
> URL: http://issues.apache.org/jira/browse/DERBY-1036
> Project: Derby
> Type: Sub-task
> Components: Network Client, JDBC
> Versions: 10.2.0.0, 10.1.3.0, 10.1.2.3
> Reporter: Kathey Marsden
> Assignee: Dag H. Wanvik
> Priority: Minor
>
> In looking at the checkDataSource test for DERBY-435, I hit an issue that the
> test fails with an exception for duplicate cursor name because it sets the
> cursor name for two statements to the same thing.
> Embedded seems to allow this, but it seems to me that client might be right
> here. How could embedded differentiate the two for positioned updates?
> There is risk to existing applications if embedded is changed to throw the
> error that should be considered if we decide we need to change the embedded
> behaviour.
> Below are some details from checkDataSource where I hit this. I will change
> the names for now as it does not seem relevant to what is being tested.
> PreparedStatement psruState = createFloatStatementForStateChecking(cs1,
> "select i from ru where i = ?");
> CallableStatement csruState = createFloatCallForStateChecking(cs1,
> "CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(?,?)");
> Both of these methods set the cursor name to the same thing:
> s.setCursorName("StokeNewington");
> For embedded it succeeds for client it throws the exception.
> java.sql.SQLException: Duplicate cursor names are not allowed.
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown
> Source)
> at org.apache.derby.client.am.Statement.setCursorName(Unknown Source)
> at
> org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource.createFloatStatementForStateChecking(Unknown
> Source)
> at
> org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource.runTest(Unknown
> Source)
> at
> org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource.main(Unknown
> Source)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1183) Client java.sql.ResultSet.getCursorName() does not return the correct cursor name for Statements after the first execution
[ http://issues.apache.org/jira/browse/DERBY-1183?page=all ]
Dag H. Wanvik updated DERBY-1183:
-
Fix Version: 10.2.0.0
Derby Info: [Patch Available]
> Client java.sql.ResultSet.getCursorName() does not return the correct cursor
> name for Statements after the first execution
> --
>
> Key: DERBY-1183
> URL: http://issues.apache.org/jira/browse/DERBY-1183
> Project: Derby
> Type: Bug
> Components: JDBC
> Versions: 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Dag H. Wanvik
> Fix For: 10.2.0.0
> Attachments: derby-1183.diff, derby-1183.stat
>
> For client, if the cursor name is set with java.sql.Statement.setCursorName()
> the name set by the user only applies to the first execution. Subsequent
> executions use the default cursor name. To reproduce run the progam below as
> follows:
> D>java -Dframework=DerbyNetClient GetCursorName
> 10.2.0.0 alpha
> Apache Derby
> Apache Derby Network Client JDBC Driver
> rs.getCursorName():MyCursor
> rs.getCursorName():SQL_CURLH000C2
> With embedded it is ok:
> D>java GetCursorName
> 10.2.0.0 alpha
> Apache Derby
> Apache Derby Embedded JDBC Driver
> rs.getCursorName():MyCursor
> rs.getCursorName():MyCursor
> import java.sql.Connection;
> import java.sql.DatabaseMetaData;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Statement;
> import org.apache.derbyTesting.functionTests.util.TestUtil;
> class GetCursorName
> {
>
> public static void main (String args [])throws Exception
> {
> testGetCursorName();
> }
>
> public static void testGetCursorName() throws SQLException
> {
>
> Connection conn =
> TestUtil.getConnection("wombat","create=true");
> Statement stmt = null;
> ResultSet rs = null;
> DatabaseMetaData md = conn.getMetaData() ;
> System.out.println(md.getDatabaseProductVersion());
> System.out.println(md.getDatabaseProductName());
> System.out.println(md.getDriverName());
>
> stmt = conn.createStatement();
> // Setting the cursor name works for one execution ok.
> stmt.setCursorName("MyCursor");
> rs = stmt.executeQuery("select count(*) from sys.systables");
> System.out.println("rs.getCursorName():" + rs.getCursorName());
> rs.close();
> //Executing another query seems to clears the cursor name.
> // getCursorName() will print the default cursor name SQLXXX.
> rs = stmt.executeQuery("select count(*) from sys.systables");
> System.out.println("rs.getCursorName():" + rs.getCursorName());
> rs.close();
> stmt.close();
> conn.close();
> }
>
> }
> I noticed this bug when coverting the checkDataSource test for client.
> I will change that test to set the cursor name for each execution for client.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1183) Client java.sql.ResultSet.getCursorName() does not return the correct cursor name for Statements after the first execution
[ http://issues.apache.org/jira/browse/DERBY-1183?page=all ] Dag H. Wanvik updated DERBY-1183: - Attachment: derby-1183.stat derby-1183.diff This is a first patch (derby-1183.diff) to solve this issue as well as DERBY-1036; it seemed convenient to combine them. I have run derbyall, seeing only a bug in JitTest.java which is not related (diff in derby version number). Please have a look at it. Patch description: The problem underlying DERBY-1185 is the following: A Statement (and by inheritance, PreparedStatement and CallableStatement) will have a cursor name associated with result set generated by the statement. Such names are either set by the user (Statement#setCursorName) or assigned by the system (aka "canned" cursor names in the client driver). In either case, the user can get at the cursor name attached to a statement by calling Resultset#getCursorName. This string can be used to construct the SQL text of positioned update or delete statement. Currently, when a cursor name is set on a statement, the following actions are taken (Statement#setCursorName): 1. The statement's string variable cursorName_ is set to the new string. This keeps track of the user cursor name set for this statement. 2. A cache (clientCursorNameCache) of cursor names set by the user for this connection is maintained to avoid having any two identical cursor name for the same statement/result set. When the cursor name is set, the check is performed (2a) and the cache is updated with the new cursor name if all is well (2b). If the statement (only applies for PreparedStatement and CallableStatement) already has a DRDA section (ch 7.14) allocated, the following is also performed: 3. A map (cursor name -> section) is updated. 4. The section associated with this statement gets its variable clientCursorName set to the supplied cursor name. For Statement, this association (steps 3 and 4) is performed at statement execution time (inside flowExecute, just after the new section is allocated for a query). 5. Also in flowExecute (of Statement, PreparedStatement) the cursor (user set or canned) is associated with the result set (call to mapCursorNameToResultSet). The symptom of this bug is that the cursor name set for a statement seems to be lost after one execution of that statement, reverting to a canned cursor name for executions 2..n. This happens because the cursor name is actually reset as part of the next execute on a statement object: 6. Open result sets for a statement are closed when flowExecute calls readCloseResultSets. During the closing of a result set, ResultSet#markClosed calls statement_.removeClientCursorNameFromCache, which in addition to removing the user cursor name from the cache also sets the statements cursorName_ to null, causing it effectively to be forgotten. Since #5 happens *after* #6 in flowExecute, the execution still works, but with a canned cursor instead of the user named cursor (see mapCursorNameToResultSet). This "race condition" suggests deferring the setup of mappings and insertion into the name cache till execution time (*after* the closing of open result sets on this statement). When studying this I found there was already a bug filed (DERBY-1036) which advises that we defer the check of duplicates till execution time, so this patch fixes both DERBY-1183 and DERBY-1036. In the patch, Statement#setCursorName now only sets the string variable cursorName_. The patch also removes the resetting of cursorName_ in removeClientCursorNameFromCache, so it won't be forgotten. It is still removed from the cache when the result set is closed (and current maps deleted). Furthermore, it moves #2, #3 and #4 till execution time (flowExecute). Item #2a is performed at the start of flowExecute, so we can avoid starting any protocol action if it turns out that we should not start execution (duplicate name). The actions needed in Statement#flowExecute and PreparedStatement#flowExecute are similar, so I factored these out into the methods Statement# checkForDuplicateCursorName and Statement#setupCursorNameCacheAndMappings. Next, I removed code from getCursorName which redundantly performs #3 (now always handled at execute time). CAVEAT: When working on understanding what goes on here, I found that the Statement finalizer can lead to cursors being released; this is part of the client side clean-up for statements that are not explicitly closed (DERBY-210). This can sometimes lead to time variability in canned cursor names in client driver tests which do not close statements explicitly. If the canned cursor name occurs in the canon file, we can see spurious diff due to this. I think we have seen this in t
[jira] Assigned: (DERBY-1183) Client java.sql.ResultSet.getCursorName() does not return the correct cursor name for Statements after the first execution
[ http://issues.apache.org/jira/browse/DERBY-1183?page=all ]
Dag H. Wanvik reassigned DERBY-1183:
Assign To: Dag H. Wanvik
> Client java.sql.ResultSet.getCursorName() does not return the correct cursor
> name for Statements after the first execution
> --
>
> Key: DERBY-1183
> URL: http://issues.apache.org/jira/browse/DERBY-1183
> Project: Derby
> Type: Bug
> Components: JDBC
> Versions: 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Dag H. Wanvik
>
> For client, if the cursor name is set with java.sql.Statement.setCursorName()
> the name set by the user only applies to the first execution. Subsequent
> executions use the default cursor name. To reproduce run the progam below as
> follows:
> D>java -Dframework=DerbyNetClient GetCursorName
> 10.2.0.0 alpha
> Apache Derby
> Apache Derby Network Client JDBC Driver
> rs.getCursorName():MyCursor
> rs.getCursorName():SQL_CURLH000C2
> With embedded it is ok:
> D>java GetCursorName
> 10.2.0.0 alpha
> Apache Derby
> Apache Derby Embedded JDBC Driver
> rs.getCursorName():MyCursor
> rs.getCursorName():MyCursor
> import java.sql.Connection;
> import java.sql.DatabaseMetaData;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Statement;
> import org.apache.derbyTesting.functionTests.util.TestUtil;
> class GetCursorName
> {
>
> public static void main (String args [])throws Exception
> {
> testGetCursorName();
> }
>
> public static void testGetCursorName() throws SQLException
> {
>
> Connection conn =
> TestUtil.getConnection("wombat","create=true");
> Statement stmt = null;
> ResultSet rs = null;
> DatabaseMetaData md = conn.getMetaData() ;
> System.out.println(md.getDatabaseProductVersion());
> System.out.println(md.getDatabaseProductName());
> System.out.println(md.getDriverName());
>
> stmt = conn.createStatement();
> // Setting the cursor name works for one execution ok.
> stmt.setCursorName("MyCursor");
> rs = stmt.executeQuery("select count(*) from sys.systables");
> System.out.println("rs.getCursorName():" + rs.getCursorName());
> rs.close();
> //Executing another query seems to clears the cursor name.
> // getCursorName() will print the default cursor name SQLXXX.
> rs = stmt.executeQuery("select count(*) from sys.systables");
> System.out.println("rs.getCursorName():" + rs.getCursorName());
> rs.close();
> stmt.close();
> conn.close();
> }
>
> }
> I noticed this bug when coverting the checkDataSource test for client.
> I will change that test to set the cursor name for each execution for client.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-874) Solidify JUnit test infrastructure
[ http://issues.apache.org/jira/browse/DERBY-874?page=all ] Rick Hillegas reassigned DERBY-874: --- Assign To: (was: Rick Hillegas) > Solidify JUnit test infrastructure > -- > > Key: DERBY-874 > URL: http://issues.apache.org/jira/browse/DERBY-874 > Project: Derby > Type: Improvement > Components: Test > Reporter: Rick Hillegas > Attachments: bug874.diff > > Build out the JUnit test infrastructure so that developers have a clear, > standard model to follow. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-893) Build failures introduced by SQLException rototill: optional jdbc4 classes fail to build
[ http://issues.apache.org/jira/browse/DERBY-893?page=all ] Rick Hillegas closed DERBY-893: --- > Build failures introduced by SQLException rototill: optional jdbc4 classes > fail to build > > > Key: DERBY-893 > URL: http://issues.apache.org/jira/browse/DERBY-893 > Project: Derby > Type: Bug > Components: Build tools > Reporter: Rick Hillegas > Assignee: Rick Hillegas > Attachments: bug893.diff > > What it is. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-940) Add JDBC 4 Wrapper support
[ http://issues.apache.org/jira/browse/DERBY-940?page=all ] Rick Hillegas closed DERBY-940: --- > Add JDBC 4 Wrapper support > -- > > Key: DERBY-940 > URL: http://issues.apache.org/jira/browse/DERBY-940 > Project: Derby > Type: New Feature > Components: JDBC > Reporter: Rick Hillegas > Assignee: V.Narayanan > Attachments: DERBY940_embedded.html, DERBY940_v4_embedded.html, > Derby940_wrapper_Client.html, wrapper_client_v1.diff, wrapper_client_v1.stat, > wrapper_ver1_embedded.diff, wrapper_ver1_embedded.stat, > wrapper_ver2_embedded.diff, wrapper_ver2_embedded.stat, > wrapper_ver3_embedded.diff, wrapper_ver3_embedded.stat, > wrapper_ver4_embedded.diff, wrapper_ver4_embedded.stat, > wrapper_ver5_embedded.diff, wrapper_ver5_embedded.stat, > wrapper_ver6_embedded.diff, wrapper_ver6_embedded.stat > > As described in the JDBC 4 spec, sections 21 and 3.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-941) Add JDBC4 support for Statement Events
[ http://issues.apache.org/jira/browse/DERBY-941?page=all ] Rick Hillegas closed DERBY-941: --- > Add JDBC4 support for Statement Events > -- > > Key: DERBY-941 > URL: http://issues.apache.org/jira/browse/DERBY-941 > Project: Derby > Type: New Feature > Components: JDBC > Versions: 10.0.2.0 > Reporter: Rick Hillegas > Assignee: V.Narayanan > Fix For: 10.2.0.0 > Attachments: ListenerTest.java, diff_between_ver2_ver3.txt, > statementeventlisteners_client.diff, statementeventlisteners_client.html, > statementeventlisteners_client.stat, statementeventlisteners_client_v1.diff, > statementeventlisteners_client_v1.stat, > statementeventlisteners_client_v2.diff, > statementeventlisteners_client_v2.stat, > statementeventlisteners_client_v3.diff, > statementeventlisteners_client_v3.stat, > statementeventlisteners_client_v4.diff, > statementeventlisteners_client_v4.stat, > statementeventlisteners_embedded.diff, statementeventlisteners_embedded.stat, > statementeventlisteners_embedded_v2.diff, > statementeventlisteners_embedded_v2.stat, > statementeventlisteners_embedded_v3.diff, > statementeventlisteners_embedded_v3.stat, > statementeventlisteners_embedded_ver1.html > > As described in the JDBC 4 spec, sections 11.2, 11.7, and 3.1. > These are the methods which let app servers listen for connection and > statement closure and invalidation events. > Section 11.2 of the JDBC 4 spec explains connection events: Connection pool > managers which implement the ConnectionEventListener interface can register > themselves to listen for "connectionClosed" and fatal > "connectionErrorOccurred" events. App servers can use these events to help > them manage the recycling of connections back to the connection pool. > Section 11.7 of the JDBC 4 spec explains statement events: Statement pools > which implement StatementEventListener can register themselves to listen for > "statementClosed" and "statementErrorOccurred" events. Again, this helps > statement pools manage the recycling of statements back to the pool. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-942) Add JDBC4 Ease of Development Support
[ http://issues.apache.org/jira/browse/DERBY-942?page=all ] Rick Hillegas closed DERBY-942: --- > Add JDBC4 Ease of Development Support > - > > Key: DERBY-942 > URL: http://issues.apache.org/jira/browse/DERBY-942 > Project: Derby > Type: New Feature > Components: JDBC > Reporter: Rick Hillegas > Assignee: Anurag Shekhar > Fix For: 10.2.0.0 > Attachments: TestDbMetaData.diff, TestQueryObject.diff, > derby-942-connectiontest-rewrite.diff, derby-942-connectiontest-rewrite.stat, > derby-942-enable-connectionTest.diff, derby-942-enable-connectionTest.stat, > derby-942.diff, derby-942_2.diff > > As described in the JDBC 4 spec, sections 20.1, 20.2, and 3.1. > The Ease of Development extensions provide a way to create tabular DataSets > from queries and tuple signatures. The jdk ships with a factory for creating > these DataSets, which is a class which implements the QueryObjectGenerator > interface. A database can write its own custom QueryObjectGenerator, or just > ship with the default, jdk-shipped version. For this task, we will simply > wire the default jdk-shipped factory into the appropriate methods: > Connection.createQueryObject() and DataSource.createQueryObject(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-945) Miscellaneous Connection methods added by JDBC 4
[ http://issues.apache.org/jira/browse/DERBY-945?page=all ] Rick Hillegas closed DERBY-945: --- Resolution: Fixed Sub-task closed. > Miscellaneous Connection methods added by JDBC 4 > > > Key: DERBY-945 > URL: http://issues.apache.org/jira/browse/DERBY-945 > Project: Derby > Type: New Feature > Components: JDBC > Reporter: Rick Hillegas > Assignee: Olav Sandstaa > Fix For: 10.2.0.0 > > As described in the JDBC 4 spec section 3.1. > This addresses new Connection methods added by JDBC 4 which are not addressed > by the large object work (DERBY-796) and EOD work (DERBY-942). These > additional methods are getClientInfo(), setClientInfo(), and isValid(). For > the client info calls, we propose to not support the getting/setting of > client info properties for release 10.2. Support for this functionality is > optional. These properties are used for configuring session-scope, > server-side diagnostics which Derby supplies through other mechanisms. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1078) Be able to build Derby when JAVA_HOME is set 1.6
[ http://issues.apache.org/jira/browse/DERBY-1078?page=all ] Rick Hillegas closed DERBY-1078: > Be able to build Derby when JAVA_HOME is set 1.6 > > > Key: DERBY-1078 > URL: http://issues.apache.org/jira/browse/DERBY-1078 > Project: Derby > Type: Improvement > Components: Build tools > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Andrew McIntyre > Fix For: 10.2.0.0 > Attachments: derby-1078.diff, derby-1078_part2.diff, derby-1078_part3.diff > > Currently, the 1.4 compiler is used to build most of Derby. We use the 1.6 > compiler to (optionally) build the JDBC4 support. If you try to build Derby > in a shell window with a 1.6 JAVA_HOME, the 1.4 bits will fail to build. This > is because those bits do not satisfy the JDBC4 contract. In addition, even if > you could build those bits under 1.6, the 1.6 class files would fail to load > on a 1.4 vm. > We need to be able to use 1.6 as our default build environment but still > generate jar files which run on 1.4 and 1.5. There may be compiler switches > which allow this. If not, building in a 1.6 environment could fault in the > 1.4 compiler as necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-946) Miscellaneous DatabaseMetaData methods added by JDBC 4
[ http://issues.apache.org/jira/browse/DERBY-946?page=all ] Rick Hillegas closed DERBY-946: --- Resolution: Fixed Sub-issues closed. > Miscellaneous DatabaseMetaData methods added by JDBC 4 > -- > > Key: DERBY-946 > URL: http://issues.apache.org/jira/browse/DERBY-946 > Project: Derby > Type: New Feature > Components: JDBC > Reporter: Rick Hillegas > Fix For: 10.2.0.0 > > As described in the JDBC4 spec, sections 7 and 3.1. > This addresses new JDBC4 methods in DatabaseMetaData not addressed by other > JIRAs, including: > o autoCommitFailureClosesAllResultSets(). > o supportsStoredFunctionsUsingCallSyntax(). > o new getSchemas() overload -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-970) Add new metadata methods to network client driver
[ http://issues.apache.org/jira/browse/DERBY-970?page=all ] Rick Hillegas closed DERBY-970: --- > Add new metadata methods to network client driver > - > > Key: DERBY-970 > URL: http://issues.apache.org/jira/browse/DERBY-970 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: David Van Couvering > Assignee: Knut Anders Hatlen > Fix For: 10.2.0.0 > Attachments: check_server_version-v2.diff, check_server_version-v2.stat, > check_server_version.diff, check_server_version.stat, > check_server_version_report.txt, derby-970-part1-v1.diff, > derby-970-part1-v1.stat, derby-970-part2-v1.diff, derby-970-part2-v1.stat, > derby-970-part3-v1.diff, derby-970-part3-v1.stat, derby-970-part3-v2.diff, > derby-970-part3-v2.stat > > Implement new JDBC 4.0 DatabaseMetaData methods in the client driver: > - supportsStoredFunctionsUsingCallSyntax() > - autoCommitFailureClosesAllResultSets() > - getClientInfoProperties() > - providesQueryObjectGenerator() > - getSchemas() > - getRowIdLifetime() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-968) Add new metadata methods to embedded driver
[ http://issues.apache.org/jira/browse/DERBY-968?page=all ] Rick Hillegas closed DERBY-968: --- Resolution: Fixed Sub-issues have been closed. > Add new metadata methods to embedded driver > --- > > Key: DERBY-968 > URL: http://issues.apache.org/jira/browse/DERBY-968 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: David Van Couvering > Assignee: Rick Hillegas > Priority: Minor > Fix For: 10.2.0.0 > > Sub-task to create the new JDBC 4 metadata methods to the embedded driver. > This does *not* cover the changes to existing methods. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-925) Implement new JDBC 4 metadata API getFunctionParameters()
[ http://issues.apache.org/jira/browse/DERBY-925?page=all ] Rick Hillegas closed DERBY-925: --- > Implement new JDBC 4 metadata API getFunctionParameters() > - > > Key: DERBY-925 > URL: http://issues.apache.org/jira/browse/DERBY-925 > Project: Derby > Type: New Feature > Components: JDBC > Versions: 10.2.0.0 > Environment: JDK 1.6 > Reporter: David Van Couvering > Assignee: Dyre Tjeldvoll > Fix For: 10.2.0.0 > Attachments: TypePrinter.java, derby-925.v1.diff, derby-925.v1.stat, > derbyall_report.txt > > I am currently implementing this to return an empty result set so at least > we're compliant, but we should be able to provide real metadata here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-924) new JDBC4 metadata API getFunctions() needs to be implemented
[ http://issues.apache.org/jira/browse/DERBY-924?page=all ] Rick Hillegas closed DERBY-924: --- > new JDBC4 metadata API getFunctions() needs to be implemented > - > > Key: DERBY-924 > URL: http://issues.apache.org/jira/browse/DERBY-924 > Project: Derby > Type: New Feature > Components: JDBC > Versions: 10.2.0.0 > Environment: JDK 1.6 > Reporter: David Van Couvering > Assignee: Dyre Tjeldvoll > Fix For: 10.2.0.0 > Attachments: derby-924.v1.diff, derby-924.v1.stat, derby-924.v2.diff, > derby-924.v2.stat, derby-924.v3.diff, derby-924.v3.report.txt, > derby-924.v3.stat, derbyall_report.txt, derbyall_report.v1.txt > > For now I am implementing this to return empty result set so at least we're > compliant, but we should be able to implement this one -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-947) Miscellaneous PreparedStatement methods added by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-947?page=all ] Rick Hillegas closed DERBY-947: --- > Miscellaneous PreparedStatement methods added by JDBC4 > -- > > Key: DERBY-947 > URL: http://issues.apache.org/jira/browse/DERBY-947 > Project: Derby > Type: New Feature > Components: JDBC > Reporter: Rick Hillegas > Assignee: Francois Orsini > Fix For: 10.2.0.0 > Attachments: DERBY-947-v1.diff, DERBY-947-v1.stat, DERBY-947-v2.diff, > DERBY-947-v2.stat > > As described in the JDBC 4 spec sections 13.2 and 3.1. > This involves building support for JDBC4 methods added to PreparedStatement > and not addressed by other JIRAs: isPoolable() and setPoolable(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-948) Miscellaneous ResultSet methods added by JDBC 4
[ http://issues.apache.org/jira/browse/DERBY-948?page=all ] Rick Hillegas closed DERBY-948: --- > Miscellaneous ResultSet methods added by JDBC 4 > --- > > Key: DERBY-948 > URL: http://issues.apache.org/jira/browse/DERBY-948 > Project: Derby > Type: New Feature > Components: JDBC > Reporter: Rick Hillegas > Assignee: Knut Anders Hatlen > Fix For: 10.2.0.0 > Attachments: DERBY-948-v1.diff, DERBY-948-v1.stat, DERBY-948-v2.diff, > DERBY-948-v2.stat, DERBY-948-v3.diff, DERBY-948-v3.stat > > As described in the JDBC 4 spec sections 16 and 3.1. > This provides support for new ResultSet methods added by JDBC4 and not > addressed by other JIRAs: getHoldability() and isClosed(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1133) Split jdbc4 tests so that the suite can be run independently under the embedded and DerbyNetClients like other Derby test suites
[ http://issues.apache.org/jira/browse/DERBY-1133?page=all ] Rick Hillegas closed DERBY-1133: > Split jdbc4 tests so that the suite can be run independently under the > embedded and DerbyNetClients like other Derby test suites > > > Key: DERBY-1133 > URL: http://issues.apache.org/jira/browse/DERBY-1133 > Project: Derby > Type: Improvement > Components: Test > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Rick Hillegas > Attachments: bug1133.diff, bug1133_3_cruft.diff, bug1133_rev2.diff > > Right now the jdbc4 suite runs under the DerbyNetClient. However, under the > covers, the tests also run themselves against the embedded client. We should > fix these tests so that the whole suite can run just under DerbyNetClient or > just under the embedded client. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1133) Split jdbc4 tests so that the suite can be run independently under the embedded and DerbyNetClients like other Derby test suites
[ http://issues.apache.org/jira/browse/DERBY-1133?page=all ] Rick Hillegas resolved DERBY-1133: -- Resolution: Fixed > Split jdbc4 tests so that the suite can be run independently under the > embedded and DerbyNetClients like other Derby test suites > > > Key: DERBY-1133 > URL: http://issues.apache.org/jira/browse/DERBY-1133 > Project: Derby > Type: Improvement > Components: Test > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Rick Hillegas > Attachments: bug1133.diff, bug1133_3_cruft.diff, bug1133_rev2.diff > > Right now the jdbc4 suite runs under the DerbyNetClient. However, under the > covers, the tests also run themselves against the embedded client. We should > fix these tests so that the whole suite can run just under DerbyNetClient or > just under the embedded client. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1145) Large Objects need to implement the free() method introduced by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-1145?page=all ] Rick Hillegas closed DERBY-1145: Resolution: Fixed Closed as duplicate. > Large Objects need to implement the free() method introduced by JDBC4 > - > > Key: DERBY-1145 > URL: http://issues.apache.org/jira/browse/DERBY-1145 > Project: Derby > Type: Bug > Components: JDBC > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Fix For: 10.2.0.0 > > java.sql.Blob.free() and java.sql.Clob.free() need to be implemented for > JDBC4. These methods seem to have been overlooked because the Blob and Clob > implementations compile cleanly under jdk1.4 without this method and, unless > we compile a class under jdk1.6, no checking is done to verify the 1.6 > signatures. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1328) Implementing the free methods in the Clob and Blob interface
[ http://issues.apache.org/jira/browse/DERBY-1328?page=all ] Rick Hillegas closed DERBY-1328: > Implementing the free methods in the Clob and Blob interface > > > Key: DERBY-1328 > URL: http://issues.apache.org/jira/browse/DERBY-1328 > Project: Derby > Type: New Feature > Components: JDBC > Reporter: V.Narayanan > Assignee: V.Narayanan > Attachments: ClobBlob_free_v1.diff, ClobBlob_free_v1.stat > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1238) Add vacuous implementations for Connection.createStruct() and Connection.createArray()
[ http://issues.apache.org/jira/browse/DERBY-1238?page=all ] Rick Hillegas closed DERBY-1238: > Add vacuous implementations for Connection.createStruct() and > Connection.createArray() > -- > > Key: DERBY-1238 > URL: http://issues.apache.org/jira/browse/DERBY-1238 > Project: Derby > Type: New Feature > Components: JDBC > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Kristian Waagan > Fix For: 10.2.0.0 > Attachments: derby-1238-1a.diff, derby-1238-1a.stat > > An upcoming rev of jdk16 will require that we add vacuous implementations of > the following new methods in Connection. We can just raise > SQLFeatureNotSupported because Derby does not support Array or Struct types: > Array createArray() throws SQLException; > Struct createStruct() throws SQLException; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1238) Add vacuous implementations for Connection.createStruct() and Connection.createArray()
[ http://issues.apache.org/jira/browse/DERBY-1238?page=all ] Rick Hillegas resolved DERBY-1238: -- Resolution: Fixed > Add vacuous implementations for Connection.createStruct() and > Connection.createArray() > -- > > Key: DERBY-1238 > URL: http://issues.apache.org/jira/browse/DERBY-1238 > Project: Derby > Type: New Feature > Components: JDBC > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Kristian Waagan > Fix For: 10.2.0.0 > Attachments: derby-1238-1a.diff, derby-1238-1a.stat > > An upcoming rev of jdk16 will require that we add vacuous implementations of > the following new methods in Connection. We can just raise > SQLFeatureNotSupported because Derby does not support Array or Struct types: > Array createArray() throws SQLException; > Struct createStruct() throws SQLException; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1239) Assign relevant errors to late-breaking new JDBC4 SQLException subclass: SQLRecoverableException
[ http://issues.apache.org/jira/browse/DERBY-1239?page=all ] Rick Hillegas closed DERBY-1239: Resolution: Fixed The semantics of this exception are unclear. It appears that this is extra support added for Oracle. We can revisit this issue if the semantics become more clear. > Assign relevant errors to late-breaking new JDBC4 SQLException subclass: > SQLRecoverableException > > > Key: DERBY-1239 > URL: http://issues.apache.org/jira/browse/DERBY-1239 > Project: Derby > Type: New Feature > Components: JDBC > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Fix For: 10.2.0.0 > > An upcoming jdk16 release will expose another new subclass of SQLException: > SQLRecoverableException. Here is the verbiage from the draft SQLException > chapter of the next rev of the JDBC4 spec: > --- > 7.5.3 SQLRecoverableException > A SQLRecoverableException would be thrown in situations where the failed > operation might succeed if the application performs some recovery steps and > retries > the entire transaction or in the case of a distributed transaction, the > transaction > branch. At a minimum, recovery includes closing the current connection and > getting > a new one. After a SQLRecoverableException the application must assume that > the connection is no longer valid. > --- > And here is the upcoming new javadoc header for this class: > java.sql > Class SQLRecoverableException > java.lang.Object > extended by java.lang.Throwable > extended by java.lang.Exception > extended by java.sql.SQLException > extended by java.sql.SQLRecoverableException > All Implemented Interfaces: > java.io.Serializable, java.lang.Iterable > public class SQLRecoverableException > extends SQLException > The subclass of SQLException thrown in situations where a previously failed > operation might be able to succeed if the application performs some recovery > steps and retries the entire transaction or in the case of a distributed > transaction, the transaction branch. At a minimum, the recovery operation > must include closing the current connection and getting a new connection. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: New members to the DB PMC
David Van Couvering wrote: > I would like to let you all know that the DB PMC has some new additions. > > Bernt Johnsen, Bryan Pendleton, Kathey Marsden, Knut Anders Hatlen, Mike > Matrigali, Satheesh Bandaram, and Rick Hillegas were officially welcomed > to the DB PMC today. > > Congratulations to all of you! We should also mention that Andrew McIntyre was recently added. -jean
New members to the DB PMC
I would like to let you all know that the DB PMC has some new additions. Bernt Johnsen, Bryan Pendleton, Kathey Marsden, Knut Anders Hatlen, Mike Matrigali, Satheesh Bandaram, and Rick Hillegas were officially welcomed to the DB PMC today. Congratulations to all of you! David
[jira] Resolved: (DERBY-1398) Miscellaneous copy-editting problems in the user guides
[ http://issues.apache.org/jira/browse/DERBY-1398?page=all ] Rick Hillegas resolved DERBY-1398: -- Resolution: Fixed > Miscellaneous copy-editting problems in the user guides > --- > > Key: DERBY-1398 > URL: http://issues.apache.org/jira/browse/DERBY-1398 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Rick Hillegas > Fix For: 10.2.0.0 > Attachments: bug1398_miscDoc_01.diff > > We should clean up these copy-editting problems: > Admin Guide > Update Copyrights in all docs > Part One...About this guide and the Network Server documentation > "and and" -> "and" > Part One...Accessing the Network Server by using the network client driver > retrieveMessageText: Is this synchronization cruft: > "...or when starting new units of work. > Part One...XA and the Network Server > We should say that the Derby Network Client is an example > of a compliant DRDA client which you can use for distributed > transactions. > Part One...Using the Derby ij tool with the Network Server > Do you really need the DRIVER command? Doesn't ij figure this > out by itself? > Part One...Differences between the embedded client and the network client > driver > These differences between network and embedded clients may need > revisiting: > * There are no localized error messages for the network client. > * The network client driver fully materializes LOBS when retrieving a row. > * To use an encrypted user id and password, you need to have the IBM's > Java Cryptography Extension (JCE) Version 1.2.1 or later. > Developer's Guide > Upgrade > Soft Upgrade > Soft upgrade allows you TO ... > Application development overview > last sentence "to serve AS..." > Derby server-side programming > Programming trigger actions > Examples of trigger actions > insert space between "the" and "flight_history" > Triggers and exceptions > "before to the statement" -> "before the statement" > Getting Started Guide > Installing and working with Derby > Installing Derby > "This downloads page includes provides" -> > "This downloads page provides" > Reference Guide > About this guide > How this guide is organized > "Information about Derby's implementation of the JDBC interface include" > -> > "Information about Derby's implementation of the JDBC interface, > including" > JDBC Reference > java.sql.Blob and java.sql.Clob > I don't know what the following phrase means: "SQL extension over SQL" > Notes > "on the same column so could result" > -> > "on the same column could result" > Working With Derby Guide > What next with Derby > "as your next step in leaning about" > -> > "as your next step in learning about" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1398) Miscellaneous copy-editting problems in the user guides
[ http://issues.apache.org/jira/browse/DERBY-1398?page=comments#action_12415907 ] Rick Hillegas commented on DERBY-1398: -- Committed at subversion revision 413739. > Miscellaneous copy-editting problems in the user guides > --- > > Key: DERBY-1398 > URL: http://issues.apache.org/jira/browse/DERBY-1398 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Rick Hillegas > Fix For: 10.2.0.0 > Attachments: bug1398_miscDoc_01.diff > > We should clean up these copy-editting problems: > Admin Guide > Update Copyrights in all docs > Part One...About this guide and the Network Server documentation > "and and" -> "and" > Part One...Accessing the Network Server by using the network client driver > retrieveMessageText: Is this synchronization cruft: > "...or when starting new units of work. > Part One...XA and the Network Server > We should say that the Derby Network Client is an example > of a compliant DRDA client which you can use for distributed > transactions. > Part One...Using the Derby ij tool with the Network Server > Do you really need the DRIVER command? Doesn't ij figure this > out by itself? > Part One...Differences between the embedded client and the network client > driver > These differences between network and embedded clients may need > revisiting: > * There are no localized error messages for the network client. > * The network client driver fully materializes LOBS when retrieving a row. > * To use an encrypted user id and password, you need to have the IBM's > Java Cryptography Extension (JCE) Version 1.2.1 or later. > Developer's Guide > Upgrade > Soft Upgrade > Soft upgrade allows you TO ... > Application development overview > last sentence "to serve AS..." > Derby server-side programming > Programming trigger actions > Examples of trigger actions > insert space between "the" and "flight_history" > Triggers and exceptions > "before to the statement" -> "before the statement" > Getting Started Guide > Installing and working with Derby > Installing Derby > "This downloads page includes provides" -> > "This downloads page provides" > Reference Guide > About this guide > How this guide is organized > "Information about Derby's implementation of the JDBC interface include" > -> > "Information about Derby's implementation of the JDBC interface, > including" > JDBC Reference > java.sql.Blob and java.sql.Clob > I don't know what the following phrase means: "SQL extension over SQL" > Notes > "on the same column so could result" > -> > "on the same column could result" > Working With Derby Guide > What next with Derby > "as your next step in leaning about" > -> > "as your next step in learning about" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1282) Finish client info api for JDBC4. Compliance task.
[ http://issues.apache.org/jira/browse/DERBY-1282?page=all ] Rick Hillegas closed DERBY-1282: > Finish client info api for JDBC4. Compliance task. > -- > > Key: DERBY-1282 > URL: http://issues.apache.org/jira/browse/DERBY-1282 > Project: Derby > Type: Improvement > Components: JDBC > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Dyre Tjeldvoll > Fix For: 10.2.0.0 > Attachments: derby-1282.v1.diff, derby-1282.v1.stat, derbyall_report.v1.txt > > - The following java.sql.Connection methods need to be finished: > * getClientInfo() > * getClientInfo(java.lang.String) > * setClientInfo(java.lang.String,java.lang.String) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1398) Miscellaneous copy-editting problems in the user guides
[ http://issues.apache.org/jira/browse/DERBY-1398?page=all ] Rick Hillegas updated DERBY-1398: - Attachment: bug1398_miscDoc_01.diff Attaching bug1398_miscDoc_01.diff, corrections to the miscellaneous copy-editting issues listed here. Touches the following files: M src\workingwithderby\cwwdsummary.dita M src\adminguide\cadminov38650.dita M src\adminguide\cadminappsclientdiffs.dita M src\adminguide\tadminapps811302.dita M src\adminguide\cadminapps811478.dita M src\devguide\cdevspecial49460.dita M src\devguide\tdevupgradesoft.dita M src\devguide\cdevdvlp14839.dita M src\devguide\cdevspecial13670.dita M src\ref\crefmpref23947.dita M src\ref\rrefjdbc96386.dita M src\ref\crefjavbclobnot.dita M src\getstart\cgsinstallingderby.dita I've built the these changes into the html versions of the Working With Derby Guide, Admin Guide, Developer's Guide, Reference Guide, and Getting Started Guide. They look good. > Miscellaneous copy-editting problems in the user guides > --- > > Key: DERBY-1398 > URL: http://issues.apache.org/jira/browse/DERBY-1398 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Rick Hillegas > Fix For: 10.2.0.0 > Attachments: bug1398_miscDoc_01.diff > > We should clean up these copy-editting problems: > Admin Guide > Update Copyrights in all docs > Part One...About this guide and the Network Server documentation > "and and" -> "and" > Part One...Accessing the Network Server by using the network client driver > retrieveMessageText: Is this synchronization cruft: > "...or when starting new units of work. > Part One...XA and the Network Server > We should say that the Derby Network Client is an example > of a compliant DRDA client which you can use for distributed > transactions. > Part One...Using the Derby ij tool with the Network Server > Do you really need the DRIVER command? Doesn't ij figure this > out by itself? > Part One...Differences between the embedded client and the network client > driver > These differences between network and embedded clients may need > revisiting: > * There are no localized error messages for the network client. > * The network client driver fully materializes LOBS when retrieving a row. > * To use an encrypted user id and password, you need to have the IBM's > Java Cryptography Extension (JCE) Version 1.2.1 or later. > Developer's Guide > Upgrade > Soft Upgrade > Soft upgrade allows you TO ... > Application development overview > last sentence "to serve AS..." > Derby server-side programming > Programming trigger actions > Examples of trigger actions > insert space between "the" and "flight_history" > Triggers and exceptions > "before to the statement" -> "before the statement" > Getting Started Guide > Installing and working with Derby > Installing Derby > "This downloads page includes provides" -> > "This downloads page provides" > Reference Guide > About this guide > How this guide is organized > "Information about Derby's implementation of the JDBC interface include" > -> > "Information about Derby's implementation of the JDBC interface, > including" > JDBC Reference > java.sql.Blob and java.sql.Clob > I don't know what the following phrase means: "SQL extension over SQL" > Notes > "on the same column so could result" > -> > "on the same column could result" > Working With Derby Guide > What next with Derby > "as your next step in leaning about" > -> > "as your next step in learning about" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1290) Resolve test failures with JCC2.8
[ http://issues.apache.org/jira/browse/DERBY-1290?page=all ] Deepa Remesh closed DERBY-1290: --- > Resolve test failures with JCC2.8 > - > > Key: DERBY-1290 > URL: http://issues.apache.org/jira/browse/DERBY-1290 > Project: Derby > Type: Test > Components: Test > Versions: 10.2.0.0 > Reporter: Deepa Remesh > Assignee: Deepa Remesh > Priority: Minor > Fix For: 10.2.0.0 > Attachments: jcc2.8_masters.diff, jcc2.8_masters.status > > The following tests fail when run with JCC 2.8 driver: > derbynetmats/derbynetmats.fail:jdbcapi/resultset.java > derbynetmats/derbynetmats.fail:jdbcapi/LOBTest.java > derbynetmats/derbynetmats.fail:jdbcapi/parameterMapping.java > derbynetmats/derbynetmats.fail:derbynet/testSecMec.java (fails with Sun JDKs > only) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1290) Resolve test failures with JCC2.8
[ http://issues.apache.org/jira/browse/DERBY-1290?page=all ] Deepa Remesh resolved DERBY-1290: - Resolution: Fixed Verified tests pass with JCC 2.8 (46) > Resolve test failures with JCC2.8 > - > > Key: DERBY-1290 > URL: http://issues.apache.org/jira/browse/DERBY-1290 > Project: Derby > Type: Test > Components: Test > Versions: 10.2.0.0 > Reporter: Deepa Remesh > Assignee: Deepa Remesh > Priority: Minor > Fix For: 10.2.0.0 > Attachments: jcc2.8_masters.diff, jcc2.8_masters.status > > The following tests fail when run with JCC 2.8 driver: > derbynetmats/derbynetmats.fail:jdbcapi/resultset.java > derbynetmats/derbynetmats.fail:jdbcapi/LOBTest.java > derbynetmats/derbynetmats.fail:jdbcapi/parameterMapping.java > derbynetmats/derbynetmats.fail:derbynet/testSecMec.java (fails with Sun JDKs > only) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-706) Improve testing and increase code coverage for Network Server classes
[ http://issues.apache.org/jira/browse/DERBY-706?page=all ] Deepa Remesh closed DERBY-706: -- > Improve testing and increase code coverage for Network Server classes > - > > Key: DERBY-706 > URL: http://issues.apache.org/jira/browse/DERBY-706 > Project: Derby > Type: Improvement > Components: Test > Versions: 10.2.0.0 > Reporter: Deepa Remesh > Assignee: Deepa Remesh > Priority: Minor > Fix For: 10.2.0.0 > Attachments: derby-706.diff, derby-706.status, derby-706_2.status, > derby-706_2_v2.diff > > Improve testing of network server by increasing tests to cover 100% of the > classes and increase the method level coverage. The current code > coverage(class/method) for network server based on svn revision 208786 are: > org.apache.derby.drda.NetworkServercontrol.java - 100/72 > org.apache.derby.impl.drda - 97/78 > Details of code coverage from EMMA tool are available from Derby Wiki. Links > are: > http://wiki.apache.org/db-derby/CodeCoverage > http://people.apache.org/~fuzzylogic/codecoverage/208786/_files/c5.html > http://people.apache.org/~fuzzylogic/codecoverage/208786/_files/25.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-706) Improve testing and increase code coverage for Network Server classes
[ http://issues.apache.org/jira/browse/DERBY-706?page=all ] Deepa Remesh resolved DERBY-706: Fix Version: 10.2.0.0 Resolution: Fixed With svn revisions 348577 and 356553 , code coverage was increased to: * org.apache.derby.drda increase NetworkServercontrol.java - 100/72 -> 100/94 Method coverage is not 100% because 1 method (setClientLocale) is left out from automated test. It is only used by servlet. * org.apache.derby.drda.impl.drda - 97/78 -> 100->85 > Improve testing and increase code coverage for Network Server classes > - > > Key: DERBY-706 > URL: http://issues.apache.org/jira/browse/DERBY-706 > Project: Derby > Type: Improvement > Components: Test > Versions: 10.2.0.0 > Reporter: Deepa Remesh > Assignee: Deepa Remesh > Priority: Minor > Fix For: 10.2.0.0 > Attachments: derby-706.diff, derby-706.status, derby-706_2.status, > derby-706_2_v2.diff > > Improve testing of network server by increasing tests to cover 100% of the > classes and increase the method level coverage. The current code > coverage(class/method) for network server based on svn revision 208786 are: > org.apache.derby.drda.NetworkServercontrol.java - 100/72 > org.apache.derby.impl.drda - 97/78 > Details of code coverage from EMMA tool are available from Derby Wiki. Links > are: > http://wiki.apache.org/db-derby/CodeCoverage > http://people.apache.org/~fuzzylogic/codecoverage/208786/_files/c5.html > http://people.apache.org/~fuzzylogic/codecoverage/208786/_files/25.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-959) Allow use of DRDA QRYDTA block sizes greater than 32K
[ http://issues.apache.org/jira/browse/DERBY-959?page=all ] Sunitha Kambhampati updated DERBY-959: -- Attachment: odbc_rowgreaterthan64k.trace SmallRows_32kBlkSz.trace SmallRows_64kBlkSz.trace The new C client that I was testing the server with is sending a qryblksz of 65535 and I gathered server traces with it. I am attaching the trace files here . odbc_rowgreaterthan64k.trace -- using C client, trace has select of a table with 4 rows each row having more than 64k of data. The table has 341 columns of type char(200). SmallRows_32kBlkSz.trace - this server trace was gathered when running with the client driver(jdbc). query is a simple select * from tbl. where the table has rows ~ 10k each. SmallRows_64kBlkSz.trace - this server trace was gathered when running with the C client that sends a qryblksz of 65535. query is a simple select * from tbl. where the table has rows ~ 10k each. Please let me know if you need more information to understand these traces. Thanks. > Allow use of DRDA QRYDTA block sizes greater than 32K > - > > Key: DERBY-959 > URL: http://issues.apache.org/jira/browse/DERBY-959 > Project: Derby > Type: Improvement > Components: Network Client, Performance, Network Server > Versions: 10.1.1.0, 10.2.0.0, 10.1.1.1, 10.1.1.2 > Reporter: Bryan Pendleton > Priority: Minor > Attachments: 959Notes_v1.html, SmallRows_32kBlkSz.trace, > SmallRows_64kBlkSz.trace, derby959.review.diff.txt, derby959.review.stat.txt, > odbc_rowgreaterthan64k.trace > > Currently, the Network Server and Network Client use a 32K blocksize when > returning database data in QRYDTA blocks. > I came across the following statement in the DRDA spec (Volume 1, page 12): > Blocking applies only to the QRYDTA reply objects. Each > query block is a QRYDTA DSS. The maximum query block size > value allowed in the qryblksz parameter is increased from > 32K to 10M, thus accomodating the larger data volumes > required by modern, more data-intensive applications. > The importance of larger block sizes depends strong on the application > profile.. For example, many applications perform single-record selects, > and they are not influenced by the block size. > But for some applications, it seems like the ability to use a larger block > size could be quite valuable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1002) Check that DRDAStatement and DRDAResultSet states are reset when they are re-used
[ http://issues.apache.org/jira/browse/DERBY-1002?page=all ] Deepa Remesh updated DERBY-1002: Fix Version: 10.1.3.0 Patch 1 and 2 have been committed to trunk as well as 10.1 branch. > Check that DRDAStatement and DRDAResultSet states are reset when they are > re-used > - > > Key: DERBY-1002 > URL: http://issues.apache.org/jira/browse/DERBY-1002 > Project: Derby > Type: Bug > Components: Network Server > Reporter: Deepa Remesh > Fix For: 10.2.0.0, 10.1.3.0 > Attachments: derby1002-patch1-draft1.diff, derby1002-patch1-draft1.status, > derby1002-patch1-v1.diff, derby1002-patch1-v1.status, > derby1002-patch2-v2.diff, derby1002-patch2-v2.status, derby1002.java > > Network server re-uses DRDAStatement and DRDAResultSet objects when client > sends a request with same section number. When re-using DRDAStatement, it's > close() method is called which inturn calls close() method of DRDAResultSet. > For re-use to work properly, we have to ensure the states of these objects > are reset. This is not a bug but it is an area for possible improvements like: > * The reset of all states are not in the close() methods. The states get > re-initialized at different places in the code. Fo example, in case of > DRDAResultSet, they get initialized in some other DRDAStatement methods - > like addResultSet, setRsDefaultOptions, setOPNQRYOptions, setQueryOptions > etc. It will be good to have all resets in one method. > * The method name "close" is confusing since it is also called when objects > get re-used. For clarity, it may be good to have a method named reset(). And > then have the close method call reset. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-959) Allow use of DRDA QRYDTA block sizes greater than 32K
[ http://issues.apache.org/jira/browse/DERBY-959?page=all ] Sunitha Kambhampati updated DERBY-959: -- Attachment: 959Notes_v1.html derby959.review.diff.txt derby959.review.stat.txt I am attaching a patch 'derby959.review.diff.txt' to get feedback on the server changes to allow for query block size greater than 32k. From the test cases that I tried, it seems to me that the server already knows how to handle sending QRYDTA greater than 32k. Please see the attached html file 959Notes_v1.html for more notes: This is a network server only change and I ran the derbynetclientmats and derbynetmats with 1.4.2 sun jvm OK on windows. I'd appreciate your comments and feedback. Thanks. > Allow use of DRDA QRYDTA block sizes greater than 32K > - > > Key: DERBY-959 > URL: http://issues.apache.org/jira/browse/DERBY-959 > Project: Derby > Type: Improvement > Components: Network Client, Performance, Network Server > Versions: 10.2.0.0, 10.1.1.0, 10.1.1.1, 10.1.1.2 > Reporter: Bryan Pendleton > Priority: Minor > Attachments: 959Notes_v1.html, derby959.review.diff.txt, > derby959.review.stat.txt > > Currently, the Network Server and Network Client use a 32K blocksize when > returning database data in QRYDTA blocks. > I came across the following statement in the DRDA spec (Volume 1, page 12): > Blocking applies only to the QRYDTA reply objects. Each > query block is a QRYDTA DSS. The maximum query block size > value allowed in the qryblksz parameter is increased from > 32K to 10M, thus accomodating the larger data volumes > required by modern, more data-intensive applications. > The importance of larger block sizes depends strong on the application > profile.. For example, many applications perform single-record selects, > and they are not influenced by the block size. > But for some applications, it seems like the ability to use a larger block > size could be quite valuable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1377) Update copyright headers to comply with new ASF policy
[ http://issues.apache.org/jira/browse/DERBY-1377?page=comments#action_12415894 ] Jean T. Anderson commented on DERBY-1377: - Nothing is required for web site pages (at least not yet): http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL PROTECTED] > Update copyright headers to comply with new ASF policy > -- > > Key: DERBY-1377 > URL: http://issues.apache.org/jira/browse/DERBY-1377 > Project: Derby > Type: Task > Versions: 10.2.0.0 > Reporter: Jean T. Anderson > > A new copyright header policy will take effect for distributions released > starting on Aug 1, 2006. Committers will receive notification, but a heads up > with details is in the legal-discuss thread starting with > http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1377) Update copyright headers to comply with new ASF policy
[ http://issues.apache.org/jira/browse/DERBY-1377?page=comments#action_12415893 ] Jean T. Anderson commented on DERBY-1377: - So far, it look like this will be required in all source, but the final notice has not been emailed yet, so this is just an FYI: 1) Move the ASF copyright to the NOTICE file (see references [3] and [4]) 2) Header of each source gets the license header as shown in [1] 3) The html files generated by DITA doc builds need the same header, see [2], so the DITA build process needs to be tweaked. [1] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL PROTECTED] [3] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL PROTECTED] [4] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL PROTECTED] > Update copyright headers to comply with new ASF policy > -- > > Key: DERBY-1377 > URL: http://issues.apache.org/jira/browse/DERBY-1377 > Project: Derby > Type: Task > Versions: 10.2.0.0 > Reporter: Jean T. Anderson > > A new copyright header policy will take effect for distributions released > starting on Aug 1, 2006. Committers will receive notification, but a heads up > with details is in the legal-discuss thread starting with > http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: optimizer documentation
***(LS) Please post comments and responses to jira #"1397 Tuning Guide: Puzzling optimizer documentation" On 6/12/06, Laura Stewart <[EMAIL PROTECTED]> wrote: *** (LS) Sorry, accidently sent before I finished my list of questions :-) See below. On 6/12/06, Laura Stewart <[EMAIL PROTECTED] > wrote: *** (LS) Rick - I can work on updating this text... questions below. On 6/12/06, Satheesh Bandaram < [EMAIL PROTECTED] > wrote: Rick Hillegas wrote:> "If memory use is not a problem for your environment, set this> property to a high number; allowing the optimizer the maximum > flexibility in considering a join strategy queries involving large > queries leads to better performance. It can also be set to smaller> values for more limited environments.">> I can't find the name of this property on that page of the Tuning > Guide. I'm also confused about what we consider to be a "high number" > versus what we consider to be "smaller values". Would appreciate> advice here.The property it may be referring to is *derby.language.maxMemoryPerTable*. The default value is 1024 KB. Current default value is too small, so it would be a good tip fordevelopers to know and tune this property. It would be great if Derbycan configure this property value based on factors like max heap size, size of data cache and/or other parameters.If you are opening a documentation bug for other issue you found, may beyou can include this omission as well.Satheesh *** (LS) Questions - Are we sure that the name of the property is derby.language.maxMemoryPerTable ? - What is the maximum value allowed? - Is there a value that we want to recommend for users to specify? - The text says that it can be set to smaller values, what is the minimum value that we recommend? Laura Stewart -- Laura Stewart
[jira] Assigned: (DERBY-1397) Tuning Guide: Puzzling optimizer documentation
[ http://issues.apache.org/jira/browse/DERBY-1397?page=all ] Laura Stewart reassigned DERBY-1397: Assign To: Laura Stewart > Tuning Guide: Puzzling optimizer documentation > -- > > Key: DERBY-1397 > URL: http://issues.apache.org/jira/browse/DERBY-1397 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Laura Stewart > Fix For: 10.2.0.0 > > Selectivity and cardinality statistics >Working with cardinality statistics > When cardinality statistics are automatically updated >"For other operations, Derby automatically updates statistics for the > table and all indexes on the table if they are already exist. Those > operations are: >* (all indexes) When you execute SYSCS_UTIL.SYSCS_COMPRESS_TABLE. >* (index only) When you drop a column that is part of a table's index; the > statistics for the affected index are dropped, and statistics for the other > indexes on the table are updated. > " > What does the second bullet mean? Derby doesn't let you drop a column from a > table right now. > -- > Here's another puzzling piece of optimizer documentation: > I'm puzzled by the following paragraph in Tuning Guide->DML statements and > performance->Performance and optimization->Joins and performance->Join > strategies: > "If memory use is not a problem for your environment, set this property to a > high number; allowing the optimizer the maximum flexibility in considering a > join strategy queries involving large queries leads to better performance. It > can also be set to smaller values for more limited environments." > I can't find the name of this property on that page of the Tuning Guide. I'm > also confused about what we consider to be a "high number" versus what we > consider to be "smaller values". Would appreciate advice here. > Satheesh adds this: > The property it may be referring to is > *derby.language.maxMemoryPerTable*. The default value is 1024 KB. > Current default value is too small, so it would be a good tip for > developers to know and tune this property. It would be great if Derby > can configure this property value based on factors like max heap size, > size of data cache and/or other parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1271) Release documentation for JDBC4 release
[ http://issues.apache.org/jira/browse/DERBY-1271?page=all ] Rick Hillegas updated DERBY-1271: - Description: We can't check in any of this work until we understand how our release trains line up. However, the JDBC4-bearing release will need the following documentation: 1) Changes to the user guides. These need to be understood. We can analyze the scope of these changes without checking anything in yet. 2) Summary page which explains what pieces of JDBC4 we tackled and what we passed over. 3) Verbiage for the Release Notes. USER GUIDES Admin Guide Part One...How to start an embedded server from an application For JDBC4, we can omit the Class.forName() line because of Driver autoloading. Part One...Embedded server example For JDBC4, we can omit the Class.forName() line because of Driver autoloading. Part One...Network client driver examples For JDBC4, we can omit the Class.forName() line because of Driver autoloading. Part One...Accessing the Network Server by using a DataSource For JDBC4, we have different DataSources: ClientDateSource40 and ClientConnectionPoolDataSource40. Part One...Using the Derby ij tool with the Network Server In case the DRIVER command ends up being needed pre-JDBC4, we should note that you don't need it under JDBC4 because of Driver autoloading. Part One...The NsSample sample program Change NsSample to demonstrate driver autoloading under JDBC4. Part One...Overview of the SimpleNetworkServerSample program Change SimpleNetworkServerSample to demonstrate driver autoloading under JDBC4. Part One...Connecting a client to the Network Server with the SimpleNetworkClientSample program Change SimpleNetworkClientSample to demonstrate driver autoloading under JDBC4. Developer's Guide JDBC applications and Derby basics Derby embedded basics Derby JDBC driver Note that you don't need Class.forName() in JDBC4. Derby embedded basics Embedded Derby JDBC driver Note that you don't need Class.forName() in JDBC4. Starting Derby as an embedded database Note that you don't need Class.forName() or the jdbc.drivers property in JDBC4. Controlling Derby application behavior Working with Derby SQLExceptions in an application Note that with JDBC4, these are refined subclasses Example of processing SQLExceptions Say something about SQLException.getCause() Using Derby as a J2EE resource manager Classes that pertain to resource managers Mention the JDBC4 variants of these classes. Getting a DataSource Include example using JDBC4 variants of these classes. Shutting down or creating a database Include example using JDBC4 variants of these classes. Getting Started Guide No changes necessary. Reference Guide Derby exception messages and SQL states Describe SQLFeatureNotSupportedException and its SQLStates. SQLState and error message reference Mention new unimplementedFeature exceptions. What to do about new SQLStates. JDBC Reference "conforms to the JDBC 2.0 and 3.0 APIs" -> "conforms to the JDBC 2.0, 3.0, and 4.0 APIs" java.sql.Driver Amend this to note driver autoloading for JDBC4. java.sql.Connection Connection functionality not supported List unsupported Connection methods. java.sql.DatabaseMetaData Columns in the ResultSet returned by getProcedureColumns Add new columns added by JDBC4 java.sql.Statement Note that Derby does not support the execute() and executeQuery() overloads which return autogenerated keys. Prepared statements and streaming columns Note that with JDBC4, you can specify length as a long or even omit the length when setting LOB streams. java.sql.ResultSetMetaData Waiting for feedback from Dag on whether we still don't support isDefinitelyWritable(), isReadOnly(), and isWritable(). java.sql.Blob and java.sql.Clob Right now this section says that Derby supports the methods in the Blob and Clob interfaces. This is not true. We should describe the discrepancies, including any additional methods added by JDBC4. JDBC 4.0-only features Add this new section, with a subsection for each SQL interface that changed in JDBC4. The subsections should list new methods that were added. Derby API JDBC implementation classes Data Source Classes List the JDBC4 versions of these classes Tools Guide Using ij Getting started with ij Running ij scripts You don't need to specify the Derby drivers on the command line even under JDBC2. ij properties reference ij.dataSource This is the DataSource for embedded JDBC3. Note that th
Re: optimizer documentation
*** (LS) Sorry, accidently sent before I finished my list of questions :-) See below. On 6/12/06, Laura Stewart <[EMAIL PROTECTED]> wrote: *** (LS) Rick - I can work on updating this text... questions below. On 6/12/06, Satheesh Bandaram < [EMAIL PROTECTED]> wrote: Rick Hillegas wrote:> "If memory use is not a problem for your environment, set this> property to a high number; allowing the optimizer the maximum > flexibility in considering a join strategy queries involving large> queries leads to better performance. It can also be set to smaller> values for more limited environments.">> I can't find the name of this property on that page of the Tuning > Guide. I'm also confused about what we consider to be a "high number"> versus what we consider to be "smaller values". Would appreciate> advice here.The property it may be referring to is *derby.language.maxMemoryPerTable*. The default value is 1024 KB.Current default value is too small, so it would be a good tip fordevelopers to know and tune this property. It would be great if Derbycan configure this property value based on factors like max heap size, size of data cache and/or other parameters.If you are opening a documentation bug for other issue you found, may beyou can include this omission as well.Satheesh *** (LS) Questions - Are we sure that the name of the property is derby.language.maxMemoryPerTable ? - What is the maximum value allowed? - Is there a value that we want to recommend for users to specify? - The text says that it can be set to smaller values, what is the minimum value that we recommend? Laura Stewart
[jira] Commented: (DERBY-1393) PreparedStatement.setObject(Object,int,int) should throw for unsupported types
[ http://issues.apache.org/jira/browse/DERBY-1393?page=comments#action_12415888 ] Dyre Tjeldvoll commented on DERBY-1393: --- Note that with the client driver NO exception is thrown when using this method with the unsupported types. > PreparedStatement.setObject(Object,int,int) should throw for unsupported types > -- > > Key: DERBY-1393 > URL: http://issues.apache.org/jira/browse/DERBY-1393 > Project: Derby > Type: Bug > Components: JDBC, SQL > Versions: 10.2.0.0 > Environment: JDBC 4, jdk 1.6 > Reporter: Dyre Tjeldvoll > Priority: Minor > Fix For: 10.2.0.0 > > From the javadoc: > Throws: > ... > SQLFeatureNotSupportedException - if targetSqlType is a ARRAY, BLOB, > CLOB, DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, > ROWID, SQLXML or STRUCT data type and the JDBC driver does not support this > data type > Since Derby doesn't support ARRAY, DATALINK, NCHAR, NCLOB, NVARCHAR, > LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT the method should throw > SQLFeatureNotSupportedException if used with any of these types. Currently a > general type conversion exception is thrown: > >>1) > >>testSetObjectNotImplementedARRAY(org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest)SQL > >> Exception: An attempt was made to get a data value of type 'CLOB' from a > >>data value of type '2003'. > >>Caused by: SQL Exception: An attempt was made to get a data value of type > >>'CLOB' from a data value of type '2003'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: optimizer documentation
*** (LS) Rick - I can work on updating this text... questions below. On 6/12/06, Satheesh Bandaram <[EMAIL PROTECTED]> wrote: Rick Hillegas wrote:> "If memory use is not a problem for your environment, set this> property to a high number; allowing the optimizer the maximum > flexibility in considering a join strategy queries involving large> queries leads to better performance. It can also be set to smaller> values for more limited environments.">> I can't find the name of this property on that page of the Tuning > Guide. I'm also confused about what we consider to be a "high number"> versus what we consider to be "smaller values". Would appreciate> advice here.The property it may be referring to is *derby.language.maxMemoryPerTable*. The default value is 1024 KB.Current default value is too small, so it would be a good tip fordevelopers to know and tune this property. It would be great if Derbycan configure this property value based on factors like max heap size, size of data cache and/or other parameters.If you are opening a documentation bug for other issue you found, may beyou can include this omission as well.Satheesh*** (LS) Are we sure that the name of the property is derby.language.maxMemoryPerTable ? What is the maximum value allowed? "If memory use is not a problem for your environment, set this> property to a high number; allowing the optimizer the maximum> flexibility in considering a join strategy queries involving large > queries leads to better performance. It can also be set to smaller> values for more limited environments."-- Laura Stewart
[jira] Updated: (DERBY-1397) Tuning Guide: Puzzling optimizer documentation
[ http://issues.apache.org/jira/browse/DERBY-1397?page=all ] Rick Hillegas updated DERBY-1397: - Description: Selectivity and cardinality statistics Working with cardinality statistics When cardinality statistics are automatically updated "For other operations, Derby automatically updates statistics for the table and all indexes on the table if they are already exist. Those operations are: * (all indexes) When you execute SYSCS_UTIL.SYSCS_COMPRESS_TABLE. * (index only) When you drop a column that is part of a table's index; the statistics for the affected index are dropped, and statistics for the other indexes on the table are updated. " What does the second bullet mean? Derby doesn't let you drop a column from a table right now. -- Here's another puzzling piece of optimizer documentation: I'm puzzled by the following paragraph in Tuning Guide->DML statements and performance->Performance and optimization->Joins and performance->Join strategies: "If memory use is not a problem for your environment, set this property to a high number; allowing the optimizer the maximum flexibility in considering a join strategy queries involving large queries leads to better performance. It can also be set to smaller values for more limited environments." I can't find the name of this property on that page of the Tuning Guide. I'm also confused about what we consider to be a "high number" versus what we consider to be "smaller values". Would appreciate advice here. Satheesh adds this: The property it may be referring to is *derby.language.maxMemoryPerTable*. The default value is 1024 KB. Current default value is too small, so it would be a good tip for developers to know and tune this property. It would be great if Derby can configure this property value based on factors like max heap size, size of data cache and/or other parameters. was: Selectivity and cardinality statistics Working with cardinality statistics When cardinality statistics are automatically updated "For other operations, Derby automatically updates statistics for the table and all indexes on the table if they are already exist. Those operations are: * (all indexes) When you execute SYSCS_UTIL.SYSCS_COMPRESS_TABLE. * (index only) When you drop a column that is part of a table's index; the statistics for the affected index are dropped, and statistics for the other indexes on the table are updated. " What does the second bullet mean? Derby doesn't let you drop a column from a table right now. Added description of another puzzling piece of optimizer documentation--the property used to set the threshold for spilling hashtables to disk. > Tuning Guide: Puzzling optimizer documentation > -- > > Key: DERBY-1397 > URL: http://issues.apache.org/jira/browse/DERBY-1397 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Fix For: 10.2.0.0 > > Selectivity and cardinality statistics >Working with cardinality statistics > When cardinality statistics are automatically updated >"For other operations, Derby automatically updates statistics for the > table and all indexes on the table if they are already exist. Those > operations are: >* (all indexes) When you execute SYSCS_UTIL.SYSCS_COMPRESS_TABLE. >* (index only) When you drop a column that is part of a table's index; the > statistics for the affected index are dropped, and statistics for the other > indexes on the table are updated. > " > What does the second bullet mean? Derby doesn't let you drop a column from a > table right now. > -- > Here's another puzzling piece of optimizer documentation: > I'm puzzled by the following paragraph in Tuning Guide->DML statements and > performance->Performance and optimization->Joins and performance->Join > strategies: > "If memory use is not a problem for your environment, set this property to a > high number; allowing the optimizer the maximum flexibility in considering a > join strategy queries involving large queries leads to better performance. It > can also be set to smaller values for more limited environments." > I can't find the name of this property on that page of the Tuning Guide. I'm > also confused about what we consider to be a "high number" versus what we > consider to be "smaller values". Would appreciate advice here. > Satheesh adds this: > The property it may be referring to is > *derby.language.maxMemoryPerTable*. The default value is 1024 KB. > Current default value is too small, so it would be a good tip for > developers to know and tune this property. It would be great if Derby > can configure this property value based on factors like max he
[jira] Assigned: (DERBY-1395) Change the client SQLState to match that of embedded for the exception thrown on a closed statement whose connection is also closed
[ http://issues.apache.org/jira/browse/DERBY-1395?page=all ] David Van Couvering reassigned DERBY-1395: -- Assign To: David Van Couvering > Change the client SQLState to match that of embedded for the exception thrown > on a closed statement whose connection is also closed > --- > > Key: DERBY-1395 > URL: http://issues.apache.org/jira/browse/DERBY-1395 > Project: Derby > Type: Improvement > Components: Network Client > Versions: 10.2.0.0, 10.1.3.0 > Reporter: Deepa Remesh > Assignee: David Van Couvering > Priority: Trivial > > Scenario: Both connection and statement are closed and an operation is > performed on a closed statement. SQLStates are as follows: > Embedded: SQLSTATE: XJ012, Message: Statement Closed > Client before DERBY-843 fix: SQLSTATE = null, message = Statement closed > Client after DERBY-843 fix: SQLSTATE: 08003, Message: connection closed > This issue is related to the effort started in DERBY-254. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1003) store/bootLock.java fails with J2ME/CDC/FP
[ http://issues.apache.org/jira/browse/DERBY-1003?page=all ] Deepa Remesh closed DERBY-1003: --- Resolution: Cannot Reproduce This issue seemed to be a test timing problem and does not occur any more. > store/bootLock.java fails with J2ME/CDC/FP > -- > > Key: DERBY-1003 > URL: http://issues.apache.org/jira/browse/DERBY-1003 > Project: Derby > Type: Test > Components: Regression Test Failure > Versions: 10.2.0.0 > Environment: IBM WCTME 5.7 j9_foundation > Reporter: Deepa Remesh > > store/bootLock.java failed with j9_foundation VM in the weekend run. I ran > this test few times on my machine and the test does not fail. Also, there was > no exception in the weekend run failure. It seems like the second jvm which > is started to boot Derby did not start in time. > What test does: > The test starts a second jvm (by calling store/bootLock1.java) which boots > Derby. The test sleeps for some time waiting for the second jvm to start and > boot Derby. Then it tries to boot Derby again and should get an expected > exception for double-booting. From the failure, it seems like this second jvm > did not start at all. I am guessing this could be a timing issue. I'll check > if the test fails this weekend too. > If anyone else sees this test fail with j9_foundation VM and has more > information, please update this JIRA. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
OK, thanks, I'll work on this. David Andrew McIntyre wrote: On 6/8/06, David Van Couvering <[EMAIL PROTECTED]> wrote: According to I think it was Susan Cline, they have set it up so that a script I wrote a while back updates this page automatically. So it should be updated with the new client SQL States. Can anyone confirm or deny? If not, I'll go check it out. I'm not aware of any script/task/cron-job/what-have-you which is updating the documentation from the message source automatically. If so, we'd see the diffs to the doc tree coming through on derby-commits. :-) There may be a script floating out there to do it, but no one's contributed it to the list or offered any updates to rrefexcept71493.dita recently. andrew
[jira] Created: (DERBY-1398) Miscellaneous copy-editting problems in the user guides
Miscellaneous copy-editting problems in the user guides --- Key: DERBY-1398 URL: http://issues.apache.org/jira/browse/DERBY-1398 Project: Derby Type: Bug Components: Documentation Versions: 10.2.0.0 Reporter: Rick Hillegas Fix For: 10.2.0.0 We should clean up these copy-editting problems: Admin Guide Update Copyrights in all docs Part One...About this guide and the Network Server documentation "and and" -> "and" Part One...Accessing the Network Server by using the network client driver retrieveMessageText: Is this synchronization cruft: "...or when starting new units of work. Part One...XA and the Network Server We should say that the Derby Network Client is an example of a compliant DRDA client which you can use for distributed transactions. Part One...Using the Derby ij tool with the Network Server Do you really need the DRIVER command? Doesn't ij figure this out by itself? Part One...Differences between the embedded client and the network client driver These differences between network and embedded clients may need revisiting: * There are no localized error messages for the network client. * The network client driver fully materializes LOBS when retrieving a row. * To use an encrypted user id and password, you need to have the IBM's Java Cryptography Extension (JCE) Version 1.2.1 or later. Developer's Guide Upgrade Soft Upgrade Soft upgrade allows you TO ... Application development overview last sentence "to serve AS..." Derby server-side programming Programming trigger actions Examples of trigger actions insert space between "the" and "flight_history" Triggers and exceptions "before to the statement" -> "before the statement" Getting Started Guide Installing and working with Derby Installing Derby "This downloads page includes provides" -> "This downloads page provides" Reference Guide About this guide How this guide is organized "Information about Derby's implementation of the JDBC interface include" -> "Information about Derby's implementation of the JDBC interface, including" JDBC Reference java.sql.Blob and java.sql.Clob I don't know what the following phrase means: "SQL extension over SQL" Notes "on the same column so could result" -> "on the same column could result" Working With Derby Guide What next with Derby "as your next step in leaning about" -> "as your next step in learning about" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1398) Miscellaneous copy-editting problems in the user guides
[ http://issues.apache.org/jira/browse/DERBY-1398?page=all ] Rick Hillegas reassigned DERBY-1398: Assign To: Rick Hillegas > Miscellaneous copy-editting problems in the user guides > --- > > Key: DERBY-1398 > URL: http://issues.apache.org/jira/browse/DERBY-1398 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Rick Hillegas > Fix For: 10.2.0.0 > > We should clean up these copy-editting problems: > Admin Guide > Update Copyrights in all docs > Part One...About this guide and the Network Server documentation > "and and" -> "and" > Part One...Accessing the Network Server by using the network client driver > retrieveMessageText: Is this synchronization cruft: > "...or when starting new units of work. > Part One...XA and the Network Server > We should say that the Derby Network Client is an example > of a compliant DRDA client which you can use for distributed > transactions. > Part One...Using the Derby ij tool with the Network Server > Do you really need the DRIVER command? Doesn't ij figure this > out by itself? > Part One...Differences between the embedded client and the network client > driver > These differences between network and embedded clients may need > revisiting: > * There are no localized error messages for the network client. > * The network client driver fully materializes LOBS when retrieving a row. > * To use an encrypted user id and password, you need to have the IBM's > Java Cryptography Extension (JCE) Version 1.2.1 or later. > Developer's Guide > Upgrade > Soft Upgrade > Soft upgrade allows you TO ... > Application development overview > last sentence "to serve AS..." > Derby server-side programming > Programming trigger actions > Examples of trigger actions > insert space between "the" and "flight_history" > Triggers and exceptions > "before to the statement" -> "before the statement" > Getting Started Guide > Installing and working with Derby > Installing Derby > "This downloads page includes provides" -> > "This downloads page provides" > Reference Guide > About this guide > How this guide is organized > "Information about Derby's implementation of the JDBC interface include" > -> > "Information about Derby's implementation of the JDBC interface, > including" > JDBC Reference > java.sql.Blob and java.sql.Clob > I don't know what the following phrase means: "SQL extension over SQL" > Notes > "on the same column so could result" > -> > "on the same column could result" > Working With Derby Guide > What next with Derby > "as your next step in leaning about" > -> > "as your next step in learning about" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: optimizer documentation
Rick Hillegas wrote: > "If memory use is not a problem for your environment, set this > property to a high number; allowing the optimizer the maximum > flexibility in considering a join strategy queries involving large > queries leads to better performance. It can also be set to smaller > values for more limited environments." > > I can't find the name of this property on that page of the Tuning > Guide. I'm also confused about what we consider to be a "high number" > versus what we consider to be "smaller values". Would appreciate > advice here. The property it may be referring to is *derby.language.maxMemoryPerTable*. The default value is 1024 KB. Current default value is too small, so it would be a good tip for developers to know and tune this property. It would be great if Derby can configure this property value based on factors like max heap size, size of data cache and/or other parameters. If you are opening a documentation bug for other issue you found, may be you can include this omission as well. Satheesh
[jira] Created: (DERBY-1397) Tuning Guide: Puzzling optimizer documentation
Tuning Guide: Puzzling optimizer documentation -- Key: DERBY-1397 URL: http://issues.apache.org/jira/browse/DERBY-1397 Project: Derby Type: Bug Components: Documentation Versions: 10.2.0.0 Reporter: Rick Hillegas Fix For: 10.2.0.0 Selectivity and cardinality statistics Working with cardinality statistics When cardinality statistics are automatically updated "For other operations, Derby automatically updates statistics for the table and all indexes on the table if they are already exist. Those operations are: * (all indexes) When you execute SYSCS_UTIL.SYSCS_COMPRESS_TABLE. * (index only) When you drop a column that is part of a table's index; the statistics for the affected index are dropped, and statistics for the other indexes on the table are updated. " What does the second bullet mean? Derby doesn't let you drop a column from a table right now. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: another question about optimizer documentation
Rick Hillegas wrote: > hose operations are: > >* (all indexes) When you execute SYSCS_UTIL.SYSCS_COMPRESS_TABLE. >* (index only) When you drop a column that is part of a table's > index; the statistics for the affected index are dropped, and > statistics for the other indexes on the table are updated. > " > > What does the second bullet mean? Derby doesn't let you drop a column > from a table right now. > Documentation update needed here. I would file a documentation bug. Satheesh
[jira] Commented: (DERBY-1389) IS_AUTOINCREMENT column should be returned as part of the Database description returned by DatabaseMetaData.getColumns
[ http://issues.apache.org/jira/browse/DERBY-1389?page=comments#action_12415877 ] Rick Hillegas commented on DERBY-1389: -- Thanks for the update, Narayanan. IS_AUTOCREMENT_v2.diff passes derbyall now, modulo the wisconsin noise. Committed at subversion revision 413710. > IS_AUTOINCREMENT column should be returned as part of the Database > description returned by DatabaseMetaData.getColumns > -- > > Key: DERBY-1389 > URL: http://issues.apache.org/jira/browse/DERBY-1389 > Project: Derby > Type: New Feature > Components: JDBC > Reporter: V.Narayanan > Assignee: V.Narayanan > Attachments: IS_AUTOINCREMENT_v1.diff, IS_AUTOINCREMENT_v1.stat, > IS_AUTOINCREMENT_v2.diff, IS_AUTOINCREMENT_v2.stat, testonfreshworkspace.out, > testwithchanges.out > >Copied from the Javadoc for DatabaseMetaData from this location >http://download.java.net/jdk6/docs/api/java/sql/DatabaseMetaData.html >IS_AUTOINCREMENT String => Indicates whether this column is auto > incremented > * YES --- if the column is auto incremented > * NO --- if the column is not auto incremented > * empty string --- if it cannot be determined whether the column is auto > incremented parameter is unknown > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1396) ReEncodedInputStream may fail to read all of source Reader.
[ http://issues.apache.org/jira/browse/DERBY-1396?page=all ]
Tomohito Nakayama reassigned DERBY-1396:
Assign To: Tomohito Nakayama
> ReEncodedInputStream may fail to read all of source Reader.
>
>
> Key: DERBY-1396
> URL: http://issues.apache.org/jira/browse/DERBY-1396
> Project: Derby
> Type: Bug
> Reporter: Tomohito Nakayama
> Assignee: Tomohito Nakayama
>
> The class org.apache.derby.impl.drda.ReEncodedInputStream seems to have a
> bug...
> In this class, there exists next code.
> int count;
> if(( count = reader.read(decodedBuffer_, 0, BUFFERED_CHAR_LEN )) < 1 ){
> return null;
> }
> In this code, the condition of "<1" was intended to judge whether reader was
> read entirely.
> However,spec of java api says that reader returns -1 if the end of the reader
> has been reached and not 0.
> Then "<1" is not appropriate.
> Current code judges 0 as the end of reader.
> Then, if 0 was returned in the meaning that "No character was read now but
> may continue" as possible in java api,
> this code will not work correctly...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
another question about optimizer documentation
I'm also puzzled by the following explanation from the Tuning Guide: Selectivity and cardinality statistics Working with cardinality statistics When cardinality statistics are automatically updated "For other operations, Derby automatically updates statistics for the table and all indexes on the table if they are already exist. Those operations are: * (all indexes) When you execute SYSCS_UTIL.SYSCS_COMPRESS_TABLE. * (index only) When you drop a column that is part of a table's index; the statistics for the affected index are dropped, and statistics for the other indexes on the table are updated. " What does the second bullet mean? Derby doesn't let you drop a column from a table right now. Thanks, -Rick
optimizer documentation
I'm puzzled by the following paragraph in Tuning Guide->DML statements and performance->Performance and optimization->Joins and performance->Join strategies: "If memory use is not a problem for your environment, set this property to a high number; allowing the optimizer the maximum flexibility in considering a join strategy queries involving large queries leads to better performance. It can also be set to smaller values for more limited environments." I can't find the name of this property on that page of the Tuning Guide. I'm also confused about what we consider to be a "high number" versus what we consider to be "smaller values". Would appreciate advice here. Thanks, -Rick
[jira] Updated: (DERBY-1271) Release documentation for JDBC4 release
[ http://issues.apache.org/jira/browse/DERBY-1271?page=all ] Rick Hillegas updated DERBY-1271: - Description: We can't check in any of this work until we understand how our release trains line up. However, the JDBC4-bearing release will need the following documentation: 1) Changes to the user guides. These need to be understood. We can analyze the scope of these changes without checking anything in yet. 2) Summary page which explains what pieces of JDBC4 we tackled and what we passed over. 3) Verbiage for the Release Notes. USER GUIDES Admin Guide Part One...How to start an embedded server from an application For JDBC4, we can omit the Class.forName() line because of Driver autoloading. Part One...Embedded server example For JDBC4, we can omit the Class.forName() line because of Driver autoloading. Part One...Network client driver examples For JDBC4, we can omit the Class.forName() line because of Driver autoloading. Part One...Accessing the Network Server by using a DataSource For JDBC4, we have different DataSources: ClientDateSource40 and ClientConnectionPoolDataSource40. Part One...Using the Derby ij tool with the Network Server In case the DRIVER command ends up being needed pre-JDBC4, we should note that you don't need it under JDBC4 because of Driver autoloading. Part One...The NsSample sample program Change NsSample to demonstrate driver autoloading under JDBC4. Part One...Overview of the SimpleNetworkServerSample program Change SimpleNetworkServerSample to demonstrate driver autoloading under JDBC4. Part One...Connecting a client to the Network Server with the SimpleNetworkClientSample program Change SimpleNetworkClientSample to demonstrate driver autoloading under JDBC4. Developer's Guide JDBC applications and Derby basics Derby embedded basics Derby JDBC driver Note that you don't need Class.forName() in JDBC4. Derby embedded basics Embedded Derby JDBC driver Note that you don't need Class.forName() in JDBC4. Starting Derby as an embedded database Note that you don't need Class.forName() or the jdbc.drivers property in JDBC4. Controlling Derby application behavior Working with Derby SQLExceptions in an application Note that with JDBC4, these are refined subclasses Example of processing SQLExceptions Say something about SQLException.getCause() Using Derby as a J2EE resource manager Classes that pertain to resource managers Mention the JDBC4 variants of these classes. Getting a DataSource Include example using JDBC4 variants of these classes. Shutting down or creating a database Include example using JDBC4 variants of these classes. Getting Started Guide No changes necessary. Reference Guide Derby exception messages and SQL states Describe SQLFeatureNotSupportedException and its SQLStates. SQLState and error message reference Mention new unimplementedFeature exceptions. What to do about new SQLStates. JDBC Reference "conforms to the JDBC 2.0 and 3.0 APIs" -> "conforms to the JDBC 2.0, 3.0, and 4.0 APIs" java.sql.Driver Amend this to note driver autoloading for JDBC4. java.sql.Connection Connection functionality not supported List unsupported Connection methods. java.sql.DatabaseMetaData Columns in the ResultSet returned by getProcedureColumns Add new columns added by JDBC4 java.sql.Statement Note that Derby does not support the execute() and executeQuery() overloads which return autogenerated keys. Prepared statements and streaming columns Note that with JDBC4, you can specify length as a long or even omit the length when setting LOB streams. java.sql.ResultSetMetaData Waiting for feedback from Dag on whether we still don't support isDefinitelyWritable(), isReadOnly(), and isWritable(). java.sql.Blob and java.sql.Clob Right now this section says that Derby supports the methods in the Blob and Clob interfaces. This is not true. We should describe the discrepancies, including any additional methods added by JDBC4. JDBC 4.0-only features Add this new section, with a subsection for each SQL interface that changed in JDBC4. The subsections should list new methods that were added. Derby API JDBC implementation classes Data Source Classes List the JDBC4 versions of these classes Tools Guide Using ij Getting started with ij Running ij scripts You don't need to specify the Derby drivers on the command line even under JDBC2. ij properties reference ij.dataSource This is the DataSource for embedded JDBC3. Note that th
[jira] Created: (DERBY-1396) ReEncodedInputStream may fail to read all of source Reader.
ReEncodedInputStream may fail to read all of source Reader.
Key: DERBY-1396
URL: http://issues.apache.org/jira/browse/DERBY-1396
Project: Derby
Type: Bug
Reporter: Tomohito Nakayama
The class org.apache.derby.impl.drda.ReEncodedInputStream seems to have a bug...
In this class, there exists next code.
int count;
if(( count = reader.read(decodedBuffer_, 0, BUFFERED_CHAR_LEN )) < 1 ){
return null;
}
In this code, the condition of "<1" was intended to judge whether reader was
read entirely.
However,spec of java api says that reader returns -1 if the end of the reader
has been reached and not 0.
Then "<1" is not appropriate.
Current code judges 0 as the end of reader.
Then, if 0 was returned in the meaning that "No character was read now but may
continue" as possible in java api,
this code will not work correctly...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)
[ http://issues.apache.org/jira/browse/DERBY-1384?page=comments#action_12415856 ] Andreas Korneliussen commented on DERBY-1384: - > This is the case I was thinking about. I have coded my application without > specifying lengths for BLOB/CLOB. I would normally expect this to work: > > INSERT INTO tblob select * from tblob; OR > INSERT INTO tblob select * from myblobTab; > > My concern was on soft-update, it would be possible to insert larger than 1MB > and later on downgrade, same operations like above will not work as some > instances of BLOB could now be larger than 1MB. (and hence above operations > could fail on 10.1) > I do not see how this would be a problem on downgrade. If the operations worked in soft-upgrade, downgrade will not redefine the size of the blob-columns of existing tables. This issue is about changing the default max size of columns when doing "CREATE TABLE ..", so unless the scenario contains a create table somewhere, it should not be an issue. > May be this is extreme case and may not be worth protecting... but one could > look at 10.1 BLOB (without size) datatype to be between 1-1MB and is being > changed to 1-2GB. > An extreme case is that the user applications recreates some of its tables, and not other tables during soft-upgrade. This means that some of the tables may allow 1MB blob columns and other tables 2GB blob columns. This should then only be a problem if the application suddenly starts using blobs with size > 1MB, and do similar queries as you gave. These will now fail. If the applications had been running only on 10.1 it would have failed once it started inserting blobs with size >1M into the tables. I do not think this extreme case is a soft-upgrade problem, as the same problem could be constructed in a hard-upgrade scenario. Therefore, I do not think it is worth adding any logic in soft-upgrade mode. > Increase default BLOB/CLOB length to maximum supported (2G?) > > > Key: DERBY-1384 > URL: http://issues.apache.org/jira/browse/DERBY-1384 > Project: Derby > Type: Improvement > Components: SQL > Reporter: Bernt M. Johnsen > Assignee: Bernt M. Johnsen > Priority: Minor > Fix For: 10.2.0.0 > Attachments: derby-1384-code.diff, derby-1384-code.stat, > derby-1384-docs.diff, derby-1384-docs.stat > > Default BLOB/CLOB length should be the maximum length supported by Derby (2G?) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1293) Derby Server and Administration Guide - derby.drda.startNetworkServer
[ http://issues.apache.org/jira/browse/DERBY-1293?page=all ] Halley Pacheco de Oliveira closed DERBY-1293: - Hi John, I'm happy with the result. This issue is closed. Thanks, Halley > Derby Server and Administration Guide - derby.drda.startNetworkServer > - > > Key: DERBY-1293 > URL: http://issues.apache.org/jira/browse/DERBY-1293 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.1.2.3 > Environment: DITA-sourced documentation > Reporter: Halley Pacheco de Oliveira > Assignee: John H. Embretsen > Priority: Minor > Fix For: 10.2.0.0, 10.1.3.0 > Attachments: DERBY-1293_v2.diff, radminconfigstartnetworkserver.diff, > radminconfigstartnetworkserver.diff.html, > radminconfigstartnetworkserver.html, radminconfigstartnetworkserver_v2.html > > In this page is written: > When you set derby.drda.startNetworkServer, the Network Server will > automatically start when you start Derby. > but I think that > When you set derby.drda.startNetworkServer to true, the Network Server will > automatically start when you start Derby. > would be better, because "to true" should be explicit instead of implicit as > it is in the original text. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1389) IS_AUTOINCREMENT column should be returned as part of the Database description returned by DatabaseMetaData.getColumns
[ http://issues.apache.org/jira/browse/DERBY-1389?page=all ] V.Narayanan updated DERBY-1389: --- Attachment: IS_AUTOINCREMENT_v2.diff IS_AUTOINCREMENT_v2.stat Attaching patch once again with the Upgrade cannon. Thanx for the earlier reviews and comments thanx Narayanan > IS_AUTOINCREMENT column should be returned as part of the Database > description returned by DatabaseMetaData.getColumns > -- > > Key: DERBY-1389 > URL: http://issues.apache.org/jira/browse/DERBY-1389 > Project: Derby > Type: New Feature > Components: JDBC > Reporter: V.Narayanan > Assignee: V.Narayanan > Attachments: IS_AUTOINCREMENT_v1.diff, IS_AUTOINCREMENT_v1.stat, > IS_AUTOINCREMENT_v2.diff, IS_AUTOINCREMENT_v2.stat, testonfreshworkspace.out, > testwithchanges.out > >Copied from the Javadoc for DatabaseMetaData from this location >http://download.java.net/jdk6/docs/api/java/sql/DatabaseMetaData.html >IS_AUTOINCREMENT String => Indicates whether this column is auto > incremented > * YES --- if the column is auto incremented > * NO --- if the column is not auto incremented > * empty string --- if it cannot be determined whether the column is auto > incremented parameter is unknown > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Failure! - Derby 413485 - Sun DBTG
[Auto-generated mail] *Derby* 413485/2006-06-11 19:46:28 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 15712697 0 106.75% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-413485.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/413485.html *Jvm: 1.5* 4672668 2 107.72% CYGWIN_NT-5.1_i686-unknown 3672669 2 115.80% CYGWIN_NT-5.2_i686-unknown 0672672 2 113.74% Linux-2.6.14-1.1644_FC4_i686-i686 0672672 2 114.18% Linux-2.6.9-34.ELsmp_x86_64-x86_64 0672672 2 176.09% SunOS-5.10_i86pc-i386 0672672 2 137.17% SunOS-5.10_sun4u-sparc 2672670 2 108.49% SunOS-5.11_i86pc-i386 1672671 2 114.29% SunOS-5.9_sun4u-sparc Details in http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-413485.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/413485.html *Jvm: 1.4* 3666663 4 104.00% CYGWIN_NT-5.1_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 0666666 4 113.54% Linux-2.6.9-34.ELsmp_x86_64-x86_64 0666666 4 209.76% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-413485.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/413485.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/413485.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Commented: (DERBY-1293) Derby Server and Administration Guide - derby.drda.startNetworkServer
[ http://issues.apache.org/jira/browse/DERBY-1293?page=comments#action_12415828 ] John H. Embretsen commented on DERBY-1293: -- Thanks, Jean, for committing! :) Halley, please close this issue if you are happy with the result... > Derby Server and Administration Guide - derby.drda.startNetworkServer > - > > Key: DERBY-1293 > URL: http://issues.apache.org/jira/browse/DERBY-1293 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.1.2.3 > Environment: DITA-sourced documentation > Reporter: Halley Pacheco de Oliveira > Assignee: John H. Embretsen > Priority: Minor > Fix For: 10.2.0.0, 10.1.3.0 > Attachments: DERBY-1293_v2.diff, radminconfigstartnetworkserver.diff, > radminconfigstartnetworkserver.diff.html, > radminconfigstartnetworkserver.html, radminconfigstartnetworkserver_v2.html > > In this page is written: > When you set derby.drda.startNetworkServer, the Network Server will > automatically start when you start Derby. > but I think that > When you set derby.drda.startNetworkServer to true, the Network Server will > automatically start when you start Derby. > would be better, because "to true" should be explicit instead of implicit as > it is in the original text. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1395) Change the client SQLState to match that of embedded for the exception thrown on a closed statement whose connection is also closed
[ http://issues.apache.org/jira/browse/DERBY-1395?page=comments#action_12415827 ] Knut Anders Hatlen commented on DERBY-1395: --- The SQL states are different when the statement is closed and the connection still open too: Embedded: SQLSTATE = XJ012 Client before: SQLSTATE = null Client after: SQLSTATE = XCL31 > Change the client SQLState to match that of embedded for the exception thrown > on a closed statement whose connection is also closed > --- > > Key: DERBY-1395 > URL: http://issues.apache.org/jira/browse/DERBY-1395 > Project: Derby > Type: Improvement > Components: Network Client > Versions: 10.2.0.0, 10.1.3.0 > Reporter: Deepa Remesh > Priority: Trivial > > Scenario: Both connection and statement are closed and an operation is > performed on a closed statement. SQLStates are as follows: > Embedded: SQLSTATE: XJ012, Message: Statement Closed > Client before DERBY-843 fix: SQLSTATE = null, message = Statement closed > Client after DERBY-843 fix: SQLSTATE: 08003, Message: connection closed > This issue is related to the effort started in DERBY-254. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
