[jira] Updated: (DERBY-408) Fix formatting of manuals in PDF output
[ http://issues.apache.org/jira/browse/DERBY-408?page=all ] Jeff Levitt updated DERBY-408: -- Summary: Fix formatting of manuals in PDF output (was: Fix formatting of syntax sections in manuals) Description: 1. The syntax boxes in many of the Derby manuals seem to output with extra End-of-line feeds in the PDF's. Some syntax boxes print one word per line. For example: http://incubator.apache.org/derby/docs/tools/tools-single.html#rtoolsijpropref10135 This might be a bug with the DITA toolkit, because the DITA source files dont have these End-of-line feeds in them. This bug was originally reported in the doc reviews for version 10.1: http://issues.apache.org/jira/browse/DERBY-383 (see Myrna's comments) 2. Based on http://issues.apache.org/jira/browse/DERBY-384 comments to the doc review (see Sunitha's comments), we need to figure out how to et the table numbers to ascend. Currently, they all output as table 1. was: The syntax boxes in many of the Derby manuals seem to output with extra End-of-line feeds in the PDF's. Some syntax boxes print one word per line. For example: http://incubator.apache.org/derby/docs/tools/tools-single.html#rtoolsijpropref10135 This might be a bug with the DITA toolkit, because the DITA source files dont have these End-of-line feeds in them. This bug was originally reported in the doc reviews for version 10.1: http://issues.apache.org/jira/browse/DERBY-383 (see Myrna's comments) I am changing this bug to be more inclusive of other fixes needed for the PDF output. Fix formatting of manuals in PDF output --- Key: DERBY-408 URL: http://issues.apache.org/jira/browse/DERBY-408 Project: Derby Type: Bug Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.2.0.0 1. The syntax boxes in many of the Derby manuals seem to output with extra End-of-line feeds in the PDF's. Some syntax boxes print one word per line. For example: http://incubator.apache.org/derby/docs/tools/tools-single.html#rtoolsijpropref10135 This might be a bug with the DITA toolkit, because the DITA source files dont have these End-of-line feeds in them. This bug was originally reported in the doc reviews for version 10.1: http://issues.apache.org/jira/browse/DERBY-383 (see Myrna's comments) 2. Based on http://issues.apache.org/jira/browse/DERBY-384 comments to the doc review (see Sunitha's comments), we need to figure out how to et the table numbers to ascend. Currently, they all output as table 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] Commented: (DERBY-416) Parameter in one of the error messages is not replaced by the desired value.
[
http://issues.apache.org/jira/browse/DERBY-416?page=comments#action_12314738 ]
Mamta A. Satoor commented on DERBY-416:
---
The problem was with using ' in the error text message ie the text for XJ084 in
messages_en.properties currently looks like following
Column does not correspond to a column in the base table. Can't issue {0} on
this column
Had to remove the ' in Can't in order to for the error message to print
correctly. I changed the text for XJ084 to following
Column does not correspond to a column in the base table. Cannot issue ''{0}''
on this column.
This change required master updates for updatableResultSet.java test. I have
attached a patch to this JIRA entry to take care of it.
$ svn stat
M java\engine\org\apache\derby\loc\messages_en.properties
M
java\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.out
M
java\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatableResultSet.out
Parameter in one of the error messages is not replaced by the desired value.
Key: DERBY-416
URL: http://issues.apache.org/jira/browse/DERBY-416
Project: Derby
Type: Bug
Components: JDBC
Versions: 10.1.1.0
Reporter: Rajesh Kartha
Assignee: Mamta A. Satoor
In one of the error messages the parameter does not get replaced with the
actual value to make the message meaningful.
Here is a sample message:
=== XJ084=Column does not correspond to a column in the base table. Cant
issue {0} on this column.
More info:
Table:
ij version 10.1
ij connect 'jdbc:derby:tvtm';
ij select * from t1;
C1 |C2
1 |aa
2 |bb
3 |cc
3 rows selected
To get the above message use the following Java snippet:
private static void runTestXJ084(Connection conn){
try{
Statement stmt =
conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE);
ResultSet rs = stmt.executeQuery(SELECT 1, 2 FROM t1
FOR UPDATE);
rs.next();
rs.updateInt(1,22);
}catch (SQLException sqe){
System.out.println( === + sqe.getSQLState()+=+
sqe.getMessage());
}
}
The message obtained is:
=== XJ084=Column does not correspond to a column in the base table. Cant
issue {0} on this column.
The {0} above should have been replaced by the appropriate operation perfomed
- update in the above case.
--
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-416) Parameter in one of the error messages is not replaced by the desired value.
I have attached a patch to Derby-416 Parameter in one of the error messages is not replaced by the desired value
If the patch looks good, can a commiter please commit this?
thanks,
Mamta
On 6/29/05, Mamta A. Satoor (JIRA) derby-dev@db.apache.org wrote:
[ http://issues.apache.org/jira/browse/DERBY-416?page=comments#action_12314738
]Mamta A. Satoor commented on DERBY-416:---The problem was with using ' in the error text message ie the text for XJ084 in messages_en.properties currently looks like following
Column does not correspond to a column in the base table. Can't issue {0} on this columnHad to remove the ' in Can't in order to for the error message to print correctly. I changed the text for XJ084 to following
Column does not correspond to a column in the base table. Cannot issue ''{0}'' on this column.This change required master updates for updatableResultSet.java test. I have attached a patch to this JIRA entry to take care of it.
$ svn statMjava\engine\org\apache\derby\loc\messages_en.propertiesMjava\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.outMjava\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatableResultSet.out
Parameter in one of the error messages is not replaced by the desired value. Key: DERBY-416URL:
http://issues.apache.org/jira/browse/DERBY-416Project: Derby Type: Bug Components: JDBC Versions:
10.1.1.0 Reporter: Rajesh Kartha Assignee: Mamta A. Satoor In one of the error messages the parameter does not get replaced with the actual value to make the message meaningful.
Here is a sample message: === XJ084=Column does not correspond to a column in the base table. Cant issue {0} on this column. More info: Table: ij version 10.1 ij connect 'jdbc:derby:tvtm';
ij select * from t1; C1 |C2 1|aa 2|bb 3|cc 3 rows selected To get the above message use the following Java snippet:
private static void runTestXJ084(Connection conn){ try{ Statement stmt = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE); ResultSet rs =
stmt.executeQuery(SELECT 1, 2 FROM t1 FOR UPDATE); rs.next(); rs.updateInt(1,22); }catch (SQLException sqe){
System.out.println( === + sqe.getSQLState()+=+ sqe.getMessage()); } } The message obtained is: === XJ084=Column does not correspond to a column in the base table. Cant issue {0} on this column.
The {0} above should have been replaced by the appropriate operation perfomed - update in the above case.--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-416) Parameter in one of the error messages is not replaced by the desired value.
On Jun 29, 2005, at 11:20 PM, Mamta Satoor wrote: I have attached a patch to Derby-416 Parameter in one of the error messages is not replaced by the desired value If the patch looks good, can a commiter please commit this? thanks, Mamta This looks like a very straightforward fix. I'll take a look at committing it shortly. andrew
[jira] Resolved: (DERBY-416) Parameter in one of the error messages is not replaced by the desired value.
[ http://issues.apache.org/jira/browse/DERBY-416?page=all ]
Andrew McIntyre resolved DERBY-416:
---
Fix Version: 10.1.1.0
10.2.0.0
Resolution: Fixed
Committed, revision 202492 to trunk. Will merge to 10.1 branch before release.
Parameter in one of the error messages is not replaced by the desired value.
Key: DERBY-416
URL: http://issues.apache.org/jira/browse/DERBY-416
Project: Derby
Type: Bug
Components: JDBC
Versions: 10.1.1.0
Reporter: Rajesh Kartha
Assignee: Mamta A. Satoor
Fix For: 10.1.1.0, 10.2.0.0
Attachments: Derby416FixErrorText062905.txt
In one of the error messages the parameter does not get replaced with the
actual value to make the message meaningful.
Here is a sample message:
=== XJ084=Column does not correspond to a column in the base table. Cant
issue {0} on this column.
More info:
Table:
ij version 10.1
ij connect 'jdbc:derby:tvtm';
ij select * from t1;
C1 |C2
1 |aa
2 |bb
3 |cc
3 rows selected
To get the above message use the following Java snippet:
private static void runTestXJ084(Connection conn){
try{
Statement stmt =
conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE);
ResultSet rs = stmt.executeQuery(SELECT 1, 2 FROM t1
FOR UPDATE);
rs.next();
rs.updateInt(1,22);
}catch (SQLException sqe){
System.out.println( === + sqe.getSQLState()+=+
sqe.getMessage());
}
}
The message obtained is:
=== XJ084=Column does not correspond to a column in the base table. Cant
issue {0} on this column.
The {0} above should have been replaced by the appropriate operation perfomed
- update in the above case.
--
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] Created: (DERBY-417) Beetle6038.java store test fails on Mac OS X
Beetle6038.java store test fails on Mac OS X Key: DERBY-417 URL: http://issues.apache.org/jira/browse/DERBY-417 Project: Derby Type: Test Components: Test Versions: 10.1.1.0, 10.2.0.0 Environment: Mac OS X 10.4.1 with JDK 1.4.2 Reporter: Andrew McIntyre Priority: Trivial Fix For: 10.2.0.0 Beetle6038.java test in the storemore suite fails on Mac OS X because the test attempts to set the encryption provider for the test based on the value of the system property java.vm.vendor. It assumes that if java.vm.vendor does not start with Sun that the IBM JCE encryption provider should be used. See org.apache.derbyTesting.functionTests.tests.store.Beetle6038, lines 42-49. Since, in most cases, Derby can choose the correct encryption provider, I think the best solution to this particular issue is to not specify a particular implementation of the JCE provider, regardless of the JVM vendor. i.e. lines 42-49 can probably be wholly replaced by: dburl=jdbc:derby:Beetle6038Db;create=true;dataEncryption=true;bootPassword=Thursday;encryptionAlgorithm=DES/CBC/NoPadding; -- 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-382) Doc Review (CLOSED TO FURTHER COMMENTS): Derby Reference Manual
[ http://issues.apache.org/jira/browse/DERBY-382?page=all ] Jeff Levitt updated DERBY-382: -- Comment: was deleted Doc Review (CLOSED TO FURTHER COMMENTS): Derby Reference Manual --- Key: DERBY-382 URL: http://issues.apache.org/jira/browse/DERBY-382 Project: Derby Type: Improvement Components: Documentation Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.1.1.0 This issue tracks comments for the Derby Reference Manual. The deadline for posting comments was Tuesday, June 28, noon Pacific time. PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have additional comments, please open a JIRA issue for a fixin in a future release, as there is not enough time to incorporate additional comments. Some guidelines to follow when posting comments to this issue are: - Try to make clear and concise comments about what you want changed whenever possible. Provide concrete comments that say Please change original to modified instead of generic comments like This section needs to be rewritten. - If you're reviewing the HTML Files copy, include the URL for the page in the review comment. Obtain the URL like this: * highlight the topic in the left frame * right click * choose Properties * copy and paste the address in the pop up box. - If you're reviewing the PDF copy, in the review comment: * Include the page number for the PDF, and indicate whether the number is the PDF sheet number or the printed page number. * Include the title of the section that the problem occurs in. If it's in a subsection, try to include the hierarchy of titles. - Please don't review the HTML Book copy -- it'll be time consuming to match up that copy with the underlying DITA 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
Re: DERBY-213 Early Patch
Thanks for the tips Dan. Attached to this list is a text file outlining some of the more important points of this patch. Also in case an executive summary would be useful to anyone there are a few of main points that I tried to address with this patch (in order of importance): - Remove the call to closeX() in the nextX() method: This is probably the reason SQuirreL isn't working (See derby and squirrel sql JDBC client in the derby-user mailing list). - Change the auto-commit criteria: We only want to auto-commit if there are no other open ResultSets associated with the Statement for which the current ResultSet is attached to. For example we only wish to auto-commit ResultSet SA sttached to statement S only if ResultSets SB and SC are already closed. - Properly marking auto-committed ResultSets: I created a markAutoCommitted() method in Connection which will mark *all* open ResultSets as auto-committed post auto-commit. In terms of resolution, regrettably we have not. I acknowledge that my work on this patch is tentative and subject to change. However, hopefully my work here should make the final patch easier when we have achieved the resolution we are after. In regards to your last challenge, I am inclined to agree with your position. If we consistently follow the specs over the javadocs that is one less point for confusion. However as Kathey points out, this may mean that there are bugs in the javadocs. If we adopt this philosophy then we can simplify the advanced cases I specified in my auto-commit document. One item I would really like to see in the JDBC 4.0 spec is changing this item found in section 9.1 (in relation to closing ResultSets): if the cursor is forward only, then when invocation of its next method returns false to this if the cursor is forward only, then when invocation of its next method returns false. Further calls to next method on this ResultSet will throw an Exception. if this is what is truly meant. If this is the case then Embedded is not functioning to spec and Client (at least in part) is doing what it is suppose to (from this it follows that SQuirreL is also not following the spec). If not, the reverse is true. Let me know if anything I said here required clarification. Philip Dan Debrunner wrote: Philip Wilder wrote: I've attached an alpha patch for the DERBY-213 for anyone who is interested in the DERBY-213 issue. It should be noted that the patch is contingent upon our current interpretation of the JDBC specifications/documentation. Did we come to a resolution on your document? You asked for challenges and I challenged, but I didn't see any follow up. With a patch like this it is very useful to give an overview of what you are changing, the committers (or any other reviewers) are not mind-readers and it's hard to tell if you are fixing everything to match what is in your current interpretation or just making progress in that direction. Partial fixes are good progress, but it's useful when reviewing them to understand that the patch is only intended to address some of the issues. There have been threads on what makes a patch really useful and likely to be committed quickly, I guess these tips haven't made it to the web-site yet. :-( Dan. ## Connection ## - Change public void flowAutoCommit to public boolean flowAutoCommit In my Statement.resultSetCommitting() method I only wish to to mark the ResultSets as autoComitted if they Commit occurred properly. The boolean return value allows me to establish this. - Add public void markAutoComitted() Whenever an auto-commit is done all ResultSets associated with this Connection are auto-committed. This method will mark all ResultSets as associated with this connection as auto-committed. # Statement # - Change Criteria for what requires an auto-commit pre patch in the case of multiple ResultSets a commit was required if any of the ResultSets were not auto-committed. The isAutoCommitRequired() method checks to see if the last ResultSet being closed requires an auto-commit and that there are no other open ResultSets associated with this statement. - Change Allow the flowCloseRetrievedResultSets method to invoke an auto-commit when needed. (Change (read|write)CloseResultSets(numberOfResultSetsToClose, false) to (read|write)CloseResultSets(numberOfResultSetsToClose, true) ) -add public void resultSetCommitting() Method to auto-commit the connection -add public void markAutoCommitted() Method to mark all associated ResultSets as committed -add isAutoCommitRequired() Method to check to see if a commit is required as per the new auto-commit criteria. # ResultSet # -remove Reference to closeX() in the ResultSet We'll let auto-commit handle the closing in this instance. -change Many of the ifAutoCommitted method names were changed to enhance clarity. -change Checks to see if an auto-commit is needed now use
Re: Compile Issues
It's a bit unclear if you are still unable to compile or you are just
commenting on the build process. If you are still having problems a few
things to consider:
- Make sure the ant.properties file is actually in your user.home
directory. For me in a windows environment this is (as default)
c:\documents and settings\username
- I believe both JDK 1.4.X and JDK 1.3.X are required for successful
compilation.
- One of my favorite ways of checking to make sure all of the variables
are being used by ant is adding the following lines to the showenv
target of the main build.xml:
echo message=Additional Check/
echo message= j14lib=${j14lib} /
echo message= j13lib=${j13lib}/
echo message= JAVA_HOME=${JAVA_HOME}/
From command line you can then run ant showenv and be able to tell at
a glance whether the libraries are on your path.
Hope something here helps.
Philip
Dave Jarvis wrote:
Hi,
With ant for Java, projects should successfully compile using:
tar zxf tarball-src.tar.gz
cd src
ant
I have both J2SDK 1.4.2 and Apache Ant 1.6.5. Yet the instructions for
compiling Derby required such things as:
adding a properties file to my home directory
configuring the properties file
installing javacc
Even after following the BUILD.txt instructions, the compile failed:
compile_reference:
[javac] Compiling 9 source files to derby/10.0/classes
[javac] Fatal Error: Unable to find package java.lang in classpath
or bootclasspath
From a purely technical level, since JavaCC has a BSD license, it can
be included in the distribution. Also, a basic installation can
presume default paths (use relative names, if at all possible), and
should be able to use the environment variables already set (e.g.,
$ANT_HOME, $JAVA_HOME), without additional properties.
HSQLDB provides an excellent example of the minimal three-step
compile, and also uses whatever version of Java is installed (e.g.,
1.5 or 1.4). (Okay, it's actually four-step, but the ant command
prints out help saying how to really compile everything; slightly
suboptimal, but at least clear.)
Simple is good. =) Good luck with Derby!
Sincerely,
Dave Jarvis
Re: DERBY-213 Early Patch
Philip Wilder wrote: In regards to your last challenge, I am inclined to agree with your position. If we consistently follow the specs over the javadocs that is one less point for confusion. However as Kathey points out, this may mean that there are bugs in the javadocs. If we adopt this philosophy then we can simplify the advanced cases I specified in my auto-commit document. One item I would really like to see in the JDBC 4.0 spec is changing this item found in section 9.1 (in relation to closing ResultSets): if the cursor is forward only, then when invocation of its next method returns false to this if the cursor is forward only, then when invocation of its next method returns false. Further calls to next method on this ResultSet will throw an Exception. if this is what is truly meant. If this is the case then Embedded is not functioning to spec and Client (at least in part) is doing what it is suppose to (from this it follows that SQuirreL is also not following the spec). If not, the reverse is true. I don't think the JDBC spec (4.0 section 9.1, or 3.0 section 10.1) needs to be changed as you describe. The comment if the cursor is forward only, then when invocation of its next method returns false is describing when a ResultSet is closed. The question then becomes what should the behaviour of a ResultSet be if it is closed? For Statement and Connection objects is it required that most methods throw exceptions if they are closed. I'm not sure where this is defined, but I know Cloudscape followed it once we started running the JDBC portion of the J2EE TCK. See StmtCloseFunTest.java Dan.
Re: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
Daniel John Debrunner wrote: Daniel John Debrunner wrote: Daniel John Debrunner wrote: I had to re-run the tests because the patch messed up on one file, but now StmtCloseFunTest fails for me with this patch. *** Start: StmtCloseFunTest jdk1.4.2 derbyall:jdbc20 2005-06-28 22:08:57 *** 2a3 Statement Test failed (10) 4a6 Prepared Statement Test failed 7a10 Callable Statement Test failed Test Failed. *** End: StmtCloseFunTest jdk1.4.2 derbyall:jdbc20 2005-06-28 22:09:05 *** I'll look into it, but is anyone else seeing this failure? This is because the setQueryTimeout used to throw a not implemented exception, but now succeeds. But in this case the statement is closed so according to the JDBC spec, all such methods should throw an exception. Oyvind, do you want me to commit your current patch (I've made the copyright date changes, and performed the svn adds and propsets) and then you could fix this problem quickly? I wouldn't want to check in anything that is known to cause tests to fail, even temporarily. The fix is very simple; adding a call to checkStatus() at the very top of EmbedStatement.setQueryTimeout() fixes the problem. If you want me to, I can submit a new patch, but I think the quickest approach would be if you just inserted the 'checkStatus()' call in your own sandbox. Sorry for not catching this one myself; there was a lot of complaining about broken builds and derbyall not running cleanly at the time, and I guess I was just a bit lazy... Won't *ever* happen again. ;o) -- Øyvind Bakksjø Sun Microsystems, Web Services, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: [jira] Updated: (DERBY-414) Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level
Is this problem specific to network client? Kathey Marsden (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-414?page=all ] Kathey Marsden updated DERBY-414: - Attachment: deby414Repro.zip run repro as java TestDerbyNSXA Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level - Key: DERBY-414 URL: http://issues.apache.org/jira/browse/DERBY-414 Project: Derby Type: Bug Components: Network Client Versions: 10.1.1.0, 10.2.0.0 Reporter: Kathey Marsden Attachments: deby414Repro.zip When using v10.1.1.0 of the Apache Derby Network Client JDBC Driver and configuring the TRANSACTION_READ_UNCOMMITTED isolation level, it is unable to read changes from another transaction which haven't been committed yet. $ java TestDerbyNSXA Connection number: 2. Database product: Apache Derby Database version: 10.2.0.0 alpha Driver name: Apache Derby Network Client JDBC Driver Driver version: 10.2.0.0 alpha Thread 1: transaction started (with read committed isolation) Thread 1: row updated first time. Connection number: 3. Thread 2: transaction started (with read uncommitted isolation) Query complete on thread 2. About to do ResultSet.next()... Thread 1: row updated second time. ResultSet.next() took 19067 milliseconds. Test fails. ResultSet next under read uncommitted isolation appears to have been blocked and unable to perform a dirty read. Thread 1: transaction committed. Thread 2: transaction committed. $
[jira] Commented: (DERBY-276) ResultSet.relative(int row) cannot be called when the cursor is not positioned on a row.
[ http://issues.apache.org/jira/browse/DERBY-276?page=comments#action_12314781 ] Daniel John Debrunner commented on DERBY-276: - I'll look at committing this, it seems to have been forgotten about. :-( ResultSet.relative(int row) cannot be called when the cursor is not positioned on a row. Key: DERBY-276 URL: http://issues.apache.org/jira/browse/DERBY-276 Project: Derby Type: Improvement Components: JDBC Reporter: Bernt M. Johnsen Assignee: Bernt M. Johnsen Priority: Minor Attachments: DERBY-276-V2.diff If the cursor is not positioned on a row, calling ResultSet.relative() causes the following exception: Exception in thread main ERROR X0X87: ResultSet.relative(int row) cannot be called when the cursor is not positioned on a row. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301) at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getRelativeRow(ScrollInsensitiveResultSet.java:336) at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:366) at org.apache.derby.impl.jdbc.EmbedResultSet.relative(EmbedResultSet.java:1840) However, The 1.4.2 Javadoc says: Note: Calling the method relative(1) is identical to calling the method next() and calling the method relative(-1) is identical to calling the method previous(). (This is confirmed by the JDBC 3.0 spec, ch. 14.2.2) Since next() is valid, so should rs.relative(1) (and all other arguments, since a too large value will position the cursor after the last row, and a too low value will position it before the first). -- 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] Updated: (DERBY-414) Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level
Mike Matrigali wrote: Is this problem specific to network client? Yes. if you switch the repro to use embedded all seems to work ok.
[jira] Commented: (DERBY-405) SYNONYM should not be allowed in SESSION schema because that can confusion wih temporary tables
[ http://issues.apache.org/jira/browse/DERBY-405?page=comments#action_12314789 ] Satheesh Bandaram commented on DERBY-405: - The behavior here is same as with views. Suspect this is because of statement caching. We don't seem to recognise we have a temporary table that just overloaded an existing physical table. It would have been good to avoid permanent tables/views/synonyms in SESSION schema. Not sure what we should do now about this, though. ij create view session.st1 as select * from t; 0 rows inserted/updated/deleted ij select * from session.st1; I |J |K --- 1 |1 |NULL 2 |2 |NULL 3 |3 |NULL 4 |4 |NULL 4 rows selected ij select * from t; I |J |K --- 1 |1 |NULL 2 |2 |NULL 3 |3 |NULL 4 |4 |NULL 4 rows selected ij declare global temporary table st1(c11 int, c12 int) on commit preserve rows not logged; 0 rows inserted/updated/deleted ij select * from session.st1; I |J |K --- 1 |1 |NULL 2 |2 |NULL 3 |3 |NULL 4 |4 |NULL 4 rows selected ij select * from session.st1; This statement has an extra space between FROM and session.st1 C11|C12 --- 0 rows selected SYNONYM should not be allowed in SESSION schema because that can confusion wih temporary tables --- Key: DERBY-405 URL: http://issues.apache.org/jira/browse/DERBY-405 Project: Derby Type: Bug Components: SQL Versions: 10.2.0.0 Reporter: Mamta A. Satoor Fix For: 10.2.0.0 A user should not be able to create a synonym in SESSION schema eg create synonym session.st1 for app.t1; select * from session.st1; -- refers to app.t1 declare global temporary table st1(c11 int, c12 int) on commit preserve rows not logged; select * from session.st1; -- refers to app.t1, is that right? I think the last select * from session.st1 should goto temporary table st1 since any references to objects in SESSION schema should first find a match against a temporary table if one by that name exists. We already discourage users from defining objects other than temporary table in SESSION schema in the reference manual Using SESSION as the schema name of a physical table will not cause an error, but is discouraged. The SESSION schema name should be reserved for the temporary table schema. But, IMHO, it will be nice to enforce this wherever possible in Derby code rather than leaving it upto the users to avoid confusion. -- 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-382) Doc Review (CLOSED TO FURTHER COMMENTS): Derby Reference Manual
[ http://issues.apache.org/jira/browse/DERBY-382?page=comments#action_12314790 ] Jean T. Anderson commented on DERBY-382: I forgot to add this comment earlier, discussed with Jeff and he agreed I should go ahead and post now because it cites a general confusion of nesting of terms within the html files view of the docs. CREATE PROCEDURE http://incubator.apache.org/derby/docs/ref/rrefcreateprocedurestatement.html The online HTML files format for reading the book doesn't expand the sections for procedure-Name, ProcedureParameter, and ProcedureElement within the same page, like the PDF book does. So these references are not defined and are confusing. If there's a way to expand those subsections in the main page, that would be nice. If that isn't possible, perhaps at least move the Example from the ProcedureElement link up to this top level, so it's consistent with other CREATE commands, such as CREATE SYNONYM and CREATE TABLE. Doc Review (CLOSED TO FURTHER COMMENTS): Derby Reference Manual --- Key: DERBY-382 URL: http://issues.apache.org/jira/browse/DERBY-382 Project: Derby Type: Improvement Components: Documentation Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.1.1.0 This issue tracks comments for the Derby Reference Manual. The deadline for posting comments was Tuesday, June 28, noon Pacific time. PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have additional comments, please open a JIRA issue for a fixin in a future release, as there is not enough time to incorporate additional comments. Some guidelines to follow when posting comments to this issue are: - Try to make clear and concise comments about what you want changed whenever possible. Provide concrete comments that say Please change original to modified instead of generic comments like This section needs to be rewritten. - If you're reviewing the HTML Files copy, include the URL for the page in the review comment. Obtain the URL like this: * highlight the topic in the left frame * right click * choose Properties * copy and paste the address in the pop up box. - If you're reviewing the PDF copy, in the review comment: * Include the page number for the PDF, and indicate whether the number is the PDF sheet number or the printed page number. * Include the title of the section that the problem occurs in. If it's in a subsection, try to include the hierarchy of titles. - Please don't review the HTML Book copy -- it'll be time consuming to match up that copy with the underlying DITA 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] Commented: (DERBY-405) SYNONYM should not be allowed in SESSION schema because that can confusion wih temporary tables
[ http://issues.apache.org/jira/browse/DERBY-405?page=comments#action_12314793 ] Daniel John Debrunner commented on DERBY-405: - Well, SYNONYM's haven't been released yet, thus we could disallow SYNONYMs in SESSION schema, before 10.1 goes GA. Tables views existed before the temportary SESSION schema was added, that's why they are allowed. Existing applications could have been using the SESSION schema. SYNONYM should not be allowed in SESSION schema because that can confusion wih temporary tables --- Key: DERBY-405 URL: http://issues.apache.org/jira/browse/DERBY-405 Project: Derby Type: Bug Components: SQL Versions: 10.2.0.0 Reporter: Mamta A. Satoor Fix For: 10.2.0.0 A user should not be able to create a synonym in SESSION schema eg create synonym session.st1 for app.t1; select * from session.st1; -- refers to app.t1 declare global temporary table st1(c11 int, c12 int) on commit preserve rows not logged; select * from session.st1; -- refers to app.t1, is that right? I think the last select * from session.st1 should goto temporary table st1 since any references to objects in SESSION schema should first find a match against a temporary table if one by that name exists. We already discourage users from defining objects other than temporary table in SESSION schema in the reference manual Using SESSION as the schema name of a physical table will not cause an error, but is discouraged. The SESSION schema name should be reserved for the temporary table schema. But, IMHO, it will be nice to enforce this wherever possible in Derby code rather than leaving it upto the users to avoid confusion. -- 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-382) Doc Review (CLOSED TO FURTHER COMMENTS): Derby Reference Manual
[ http://issues.apache.org/jira/browse/DERBY-382?page=comments#action_12314794 ] Jean T. Anderson commented on DERBY-382: CREATE FUNCTION at http://incubator.apache.org/derby/docs/ref/rrefcreatefunctionstatement.html doesn't show an example, because the example is nested under the Function Element link at http://incubator.apache.org/derby/docs/ref/rrefcrprofunctionelement.html . If we can un-nest terms in the HTML files view of the docs, then the CREATE FUNCTION example in DERBY-382 could move to the developer's guide as a complete example (later, not now). Doc Review (CLOSED TO FURTHER COMMENTS): Derby Reference Manual --- Key: DERBY-382 URL: http://issues.apache.org/jira/browse/DERBY-382 Project: Derby Type: Improvement Components: Documentation Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.1.1.0 This issue tracks comments for the Derby Reference Manual. The deadline for posting comments was Tuesday, June 28, noon Pacific time. PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have additional comments, please open a JIRA issue for a fixin in a future release, as there is not enough time to incorporate additional comments. Some guidelines to follow when posting comments to this issue are: - Try to make clear and concise comments about what you want changed whenever possible. Provide concrete comments that say Please change original to modified instead of generic comments like This section needs to be rewritten. - If you're reviewing the HTML Files copy, include the URL for the page in the review comment. Obtain the URL like this: * highlight the topic in the left frame * right click * choose Properties * copy and paste the address in the pop up box. - If you're reviewing the PDF copy, in the review comment: * Include the page number for the PDF, and indicate whether the number is the PDF sheet number or the printed page number. * Include the title of the section that the problem occurs in. If it's in a subsection, try to include the hierarchy of titles. - Please don't review the HTML Book copy -- it'll be time consuming to match up that copy with the underlying DITA 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-406) Client DataSource should not require user property to be set
[ http://issues.apache.org/jira/browse/DERBY-406?page=all ] Philip Wilder reassigned DERBY-406: --- Assign To: Philip Wilder Client DataSource should not require user property to be set Key: DERBY-406 URL: http://issues.apache.org/jira/browse/DERBY-406 Project: Derby Type: Bug Components: Network Client Versions: 10.1.1.0, 10.2.0.0 Reporter: Kathey Marsden Assignee: Philip Wilder Attachments: DataSourceNoUser.java ClientDataSource should not require user to be set. It should default to user APP as described in: http://incubator.apache.org/derby/docs/adminguide/cadminappsclient.html This all seems to work ok for for DriverManager connections but fails for ClientDataSource run the attached repro $ java DataSourceNoUser embedded no userid/password client userid/password set client no password client no userid/no password org.apache.derby.client.am.SqlException: null userid not supported at org.apache.derby.client.net.NetConnection.checkUser(NetConnection.java:998) at org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:380) at org.apache.derby.client.net.NetConnection.initialize(NetConnection.java:233) at org.apache.derby.client.net.NetConnection.init(NetConnection.java:201) at org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:156) at org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:135) at DataSourceNoUser.main(DataSourceNoUser.java:42) -- 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] Updated: (DERBY-414) Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level
ok, then it seems like somehow the network client is not setting the right isolation level - rather than isolation level stuff in the server not working. I am not sure what it takes to get tests running against network server but the following tests in the embedded server test out a lot of different specific locking cases against all 4 isolation levels. They are ij tests, so may not be exercising the same path as your test case is using to set the isolation level: store/readlocks.sql store/updatelocks.sql Kathey Marsden wrote: Mike Matrigali wrote: Is this problem specific to network client? Yes. if you switch the repro to use embedded all seems to work ok.
[jira] Commented: (DERBY-31) Statement.setQueryTimeout() support.
[ http://issues.apache.org/jira/browse/DERBY-31?page=comments#action_12314795 ] Daniel John Debrunner commented on DERBY-31: Øyvind's patch committed revision 208650. (into trunk) Statement.setQueryTimeout() support. Key: DERBY-31 URL: http://issues.apache.org/jira/browse/DERBY-31 Project: Derby Type: New Feature Components: JDBC Environment: ALL Reporter: Ali Demir Assignee: Oyvind Bakksjo Attachments: DERBY-31.svn.diff, DERBY-31.svn.status, Derby-31.patch, QueryTimer.java, derbyall_report.txt Calling Statement.setQueryTimeout() throws exception saying that function is not supported. This is an important JDBC feature and is limiting our options to use Derby with our JDBC code. Implementing this JDBC function would make Derby much easier to adopt. -- 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-405) SYNONYM should not be allowed in SESSION schema because that can confusion wih temporary tables
[ http://issues.apache.org/jira/browse/DERBY-405?page=comments#action_12314796 ] Mamta A. Satoor commented on DERBY-405: --- I agree with Dan's response but I think we have a bug here with statement caching. If I recall correctly, I think the goal was to not cache any statements referencing SESSION schema objects to cover an example scenario like Satheesh's script above. But looks like in the example Satheesh gave, select * from session.st1 is getting cached and that is why it does not detect that session.st1 needs to be mapped to temporary table when it is executed the 2nd time in the example. SYNONYM should not be allowed in SESSION schema because that can confusion wih temporary tables --- Key: DERBY-405 URL: http://issues.apache.org/jira/browse/DERBY-405 Project: Derby Type: Bug Components: SQL Versions: 10.2.0.0 Reporter: Mamta A. Satoor Fix For: 10.2.0.0 A user should not be able to create a synonym in SESSION schema eg create synonym session.st1 for app.t1; select * from session.st1; -- refers to app.t1 declare global temporary table st1(c11 int, c12 int) on commit preserve rows not logged; select * from session.st1; -- refers to app.t1, is that right? I think the last select * from session.st1 should goto temporary table st1 since any references to objects in SESSION schema should first find a match against a temporary table if one by that name exists. We already discourage users from defining objects other than temporary table in SESSION schema in the reference manual Using SESSION as the schema name of a physical table will not cause an error, but is discouraged. The SESSION schema name should be reserved for the temporary table schema. But, IMHO, it will be nice to enforce this wherever possible in Derby code rather than leaving it upto the users to avoid confusion. -- 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-405) SYNONYM should not be allowed in SESSION schema because that can confusion wih temporary tables
[ http://issues.apache.org/jira/browse/DERBY-405?page=comments#action_12314797 ] Satheesh Bandaram commented on DERBY-405: - Dan's suggestion is good... We should disable synonyms in SESSION schema. I will submit a patch soon. I will also file another bug to cover the statement caching issue. SYNONYM should not be allowed in SESSION schema because that can confusion wih temporary tables --- Key: DERBY-405 URL: http://issues.apache.org/jira/browse/DERBY-405 Project: Derby Type: Bug Components: SQL Versions: 10.2.0.0 Reporter: Mamta A. Satoor Fix For: 10.2.0.0 A user should not be able to create a synonym in SESSION schema eg create synonym session.st1 for app.t1; select * from session.st1; -- refers to app.t1 declare global temporary table st1(c11 int, c12 int) on commit preserve rows not logged; select * from session.st1; -- refers to app.t1, is that right? I think the last select * from session.st1 should goto temporary table st1 since any references to objects in SESSION schema should first find a match against a temporary table if one by that name exists. We already discourage users from defining objects other than temporary table in SESSION schema in the reference manual Using SESSION as the schema name of a physical table will not cause an error, but is discouraged. The SESSION schema name should be reserved for the temporary table schema. But, IMHO, it will be nice to enforce this wherever possible in Derby code rather than leaving it upto the users to avoid confusion. -- 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-390) Import/export fails with table names that are quoted in SQL like import to table Order
[ http://issues.apache.org/jira/browse/DERBY-390?page=all ] Suresh Thalamati updated DERBY-390: --- Attachment: derby390.diff patch to handle case-sensitive SQL identifiers correctly. Import/export procedure parameters for table names , schema names , columns names should be passed in the case-sensitive form if they are quoted identfiers and in upper case if they are not quoted SQL identifiers. Import/export will generate insert/select statements with quoted table names , schema name and column names to be execute on the database after this patch. Ran debyall test suite , all tests passed. I will create sub-task to modify the documentaion for import/export , once the patch is accepted. I would like this fix to be ported to 10.1 also. Import/export fails with table names that are quoted in SQL like import to table Order -- Key: DERBY-390 URL: http://issues.apache.org/jira/browse/DERBY-390 Project: Derby Type: Bug Versions: 10.0.2.1 Reporter: Suresh Thalamati Assignee: Suresh Thalamati Attachments: derby390.diff import fails irrespective off whether the name is passed as a quoted sttring or not: ij call SYSCS_UTIL.SYSCS_IMPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null, 0) ; ERROR XIE0M: Table 'ORDER' does not exist. ij call SYSCS_UTIL.SYSCS_IMPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null, 0) ; ERROR 38000: The exception 'SQL Exception: Syntax error: Encountered ORDER at line 1, column 13.' was thrown while evaluating an expression. ERROR 42X01: Syntax error: Encountered ORDER at line 1, column 13. Export works with a quoted table name but fails if the name is not quoted : call SYSCS_UTIL.SYSCS_EXPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null) ; --- PASSES ij call SYSCS_UTIL.SYSCS_EXPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null) ; ERROR 38000: The exception 'SQL Exception: Syntax error: Encountered ORDER at line 1, column 15.' was thrown while evaluating an expression. ERROR 42X01: Syntax error: Encountered ORDER at line 1, column 15. Repro: connect 'jdbc:derby:wombat;create=true'; create table ORDER(a int ) ; insert into ORDER values(1) ; insert into ORDER values(2) ; insert into ORDER values(3) ; call SYSCS_UTIL.SYSCS_EXPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null) ; -- Perform Import call SYSCS_UTIL.SYSCS_IMPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null, 0) ; ERROR XIE0M: Table 'ORDER' does not exist. call SYSCS_UTIL.SYSCS_IMPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null, 0) ; ERROR 38000: The exception 'SQL Exception: Syntax error: Encountered ORDER at line 1, column 13.' was thrown while evaluating an expression. ERROR 42X01: Syntax error: Encountered ORDER at line 1, column 13. Note: I think the same problem will occur with when quoted schema Names and column names are passed to import/export procedures. -- 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] Updated: (DERBY-414) Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level
Mike Matrigali wrote: ok, then it seems like somehow the network client is not setting the right isolation level - rather than isolation level stuff in the server not working. I am not sure what it takes to get tests running against network server but the following tests in the embedded server test out a lot of different specific locking cases against all 4 isolation levels. They are ij tests, so may not be exercising the same path as your test case is using to set the isolation level: store/readlocks.sql store/updatelocks.sql To run tests for client you just specify -Dframework=DerbyNetClient Client sends a SET CURRENT ISOLATION statement with setTransactionIsolation and that all seems to be working ok for regular connections and is tested with jdbcapi/setTransactionIsolation.java Running the repro with derby.drda.debug=true in the derby.properties file, you can see that the SET CURRENT ISOLATION statement flows for the xa connection too in the test case but somethhing is going wrong somewhere, but this seems to be xa specific. I haven't looked closely at it though.
Re: [jira] Updated: (DERBY-414) Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level
Something that is different for XA is that each transaction tends to get a lot more context rebuilt then for normal connection (this is because other threads can pick up and enter a global transaction). I wonder if the isolation gets set ok the first time, but then gets lost? Kathey Marsden wrote: Mike Matrigali wrote: ok, then it seems like somehow the network client is not setting the right isolation level - rather than isolation level stuff in the server not working. I am not sure what it takes to get tests running against network server but the following tests in the embedded server test out a lot of different specific locking cases against all 4 isolation levels. They are ij tests, so may not be exercising the same path as your test case is using to set the isolation level: store/readlocks.sql store/updatelocks.sql To run tests for client you just specify -Dframework=DerbyNetClient Client sends a SET CURRENT ISOLATION statement with setTransactionIsolation and that all seems to be working ok for regular connections and is tested with jdbcapi/setTransactionIsolation.java Running the repro with derby.drda.debug=true in the derby.properties file, you can see that the SET CURRENT ISOLATION statement flows for the xa connection too in the test case but somethhing is going wrong somewhere, but this seems to be xa specific. I haven't looked closely at it though.
[jira] Commented: (DERBY-398) Exclude tests for J2ME/CDC/Foundation platform
[ http://issues.apache.org/jira/browse/DERBY-398?page=comments#action_12314801 ] Daniel John Debrunner commented on DERBY-398: - I think for all the new files you've added (test_app.properties) to exclude tests for J2ME Foundation, the correct contents should be as below. Changes are 1) Comment that the tests are being excluded for J2ME/Foundation, not j9. J9 is a VM implementation by IBM, whereas these tests are being excluded due to generic J2ME/Foundation restricitions. (And there is a separate runwithj9 flag that does exclude tests specifically for the IBM J9 vm, but that is not what you need here) 2) Even better would be a comment saying why they are excluded, e.g. test requires BigDecimal 3) The usedefaults flag means the contents of the default_app.properties file is picked up, which is what would happen before adding a new test_app.properties. This means those properties are not in multiple places now, so that if the default_app.properties need to be changed, it is not required to change all these other properties files. Can you re-submit the patch? - #Exclude for J2ME/Foundation - test requires ??? runwithfoundation=false usedefaults=true Exclude tests for J2ME/CDC/Foundation platform -- Key: DERBY-398 URL: http://issues.apache.org/jira/browse/DERBY-398 Project: Derby Type: Sub-task Components: Test Reporter: Deepa Remesh Assignee: Deepa Remesh Attachments: derby-398.diff, derby-398.status, derbyall_report.txt Exclude tests which use DriverManager, Driver or BigDecimal classes which are not in J2ME or JSR169. Ensure that derbyall can be run successfully in J2ME/CDC/Foundation platform using the JDBC Optional Package for CDC/Foundation Profile (JSR169). -- 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] Created: (DERBY-418) outofmemory error when running large query in autocommit=false mode
outofmemory error when running large query in autocommit=false mode --- Key: DERBY-418 URL: http://issues.apache.org/jira/browse/DERBY-418 Project: Derby Type: Bug Components: Store Versions: 10.1.1.0 Environment: I can reproduce this problem on Win2k/ T42 laptop. jdk141. Reporter: Sunitha Kambhampati Fix For: 10.2.0.0 Attachments: AutoCommitTest.java On the derby-user list, Chris reported tihs problem with his application and also a repro for the problem. I am logging the jira issue so it doesnt get lost in all the mail. (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) --from chris's post-- I'm running a set of ~5 queries on one table, using inserts and updates, and i want to be able to roll them back so i turned off autocommit using setAutoCommit(false). As the update runs, the memory used by the JVM increases continually until i get the following exception about 20% of the way through: ERROR 40XT0: An internal error was identified by RawStore module. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java) at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) at org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) at org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) at org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) at org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) at org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) at org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) at org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java) at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java) at org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java) at vi.hotspot.database.DataInterface._query(DataInterface.java:181) at vi.hotspot.database.DataInterface.query(DataInterface.java:160) at vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:518) at vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) at java.lang.Thread.run(Thread.java:534) vi.hotspot.exception.ServerTransactionException at vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:555) at vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) at java.lang.Thread.run(Thread.java:534) Derby is running in standalone mode. -- 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-418) outofmemory error when running large query in autocommit=false mode
[ http://issues.apache.org/jira/browse/DERBY-418?page=all ] Sunitha Kambhampati updated DERBY-418: -- Attachment: AutoCommitTest.java This repro was given by Chris. http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html. To run java -Xmx64M AutoCommitTest outofmemory error when running large query in autocommit=false mode --- Key: DERBY-418 URL: http://issues.apache.org/jira/browse/DERBY-418 Project: Derby Type: Bug Components: Store Versions: 10.1.1.0 Environment: I can reproduce this problem on Win2k/ T42 laptop. jdk141. Reporter: Sunitha Kambhampati Fix For: 10.2.0.0 Attachments: AutoCommitTest.java On the derby-user list, Chris reported tihs problem with his application and also a repro for the problem. I am logging the jira issue so it doesnt get lost in all the mail. (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) --from chris's post-- I'm running a set of ~5 queries on one table, using inserts and updates, and i want to be able to roll them back so i turned off autocommit using setAutoCommit(false). As the update runs, the memory used by the JVM increases continually until i get the following exception about 20% of the way through: ERROR 40XT0: An internal error was identified by RawStore module. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java) at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) at org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) at org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) at org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) at org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) at org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) at org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) at org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java) at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java) at org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java) at vi.hotspot.database.DataInterface._query(DataInterface.java:181) at vi.hotspot.database.DataInterface.query(DataInterface.java:160) at vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:518) at vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) at java.lang.Thread.run(Thread.java:534) vi.hotspot.exception.ServerTransactionException at vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:555) at vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) at java.lang.Thread.run(Thread.java:534) Derby is running in standalone mode. -- 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-384) Doc Review (CLOSED TO FURTHER COMMENTS): Tuning Derby
[ http://issues.apache.org/jira/browse/DERBY-384?page=all ] Jeff Levitt updated DERBY-384: -- Attachment: derby384.diff The attached patch makes the changes requested in this doc review. I have created sample output on my own site: HTML files: http://derby.mylevita.com/tuning/ PDF: http://derby.mylevita.com/tuning/tuningderby.pdf The patch affects EVERY dita file, but not the content for each file. This is because I modified the year in the dita source file copyrights for each file from 2004 to 2005. So while every file is listed in the patch, the only changes that will appear in the PDF and HTML files are those requested in this doc review. For references to ToursDB, I have replaced them with sample, but I doubt the examples would work against the samples database. Since I didn't have examples to replace all of the toursDB examples, my main concern was making sure the code would work; not necessarily whether they would work in a specific db. It would be nice later on to get some examples for many of these sections that would work in the sample db. Also, note that I have made the change to the trademarks page in the same way that I did to the Getting Started guide patch in http://issues.apache.org/jira/browse/DERBY-379. Doc Review (CLOSED TO FURTHER COMMENTS): Tuning Derby - Key: DERBY-384 URL: http://issues.apache.org/jira/browse/DERBY-384 Project: Derby Type: Improvement Components: Documentation Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.1.1.0 Attachments: derby384.diff This issue tracks comments for the manual known as Tuning Derby. The deadline for posting comments was Tuesday, June 28, noon Pacific time. PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have additional comments, please open a JIRA issue for a fixin in a future release, as there is not enough time to incorporate additional comments. Some guidelines to follow when posting comments to this issue are: - Try to make clear and concise comments about what you want changed whenever possible. Provide concrete comments that say Please change original to modified instead of generic comments like This section needs to be rewritten. - If you're reviewing the HTML Files copy, include the URL for the page in the review comment. Obtain the URL like this: * highlight the topic in the left frame * right click * choose Properties * copy and paste the address in the pop up box. - If you're reviewing the PDF copy, in the review comment: * Include the page number for the PDF, and indicate whether the number is the PDF sheet number or the printed page number. * Include the title of the section that the problem occurs in. If it's in a subsection, try to include the hierarchy of titles. - Please don't review the HTML Book copy -- it'll be time consuming to match up that copy with the underlying DITA 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-276) ResultSet.relative(int row) cannot be called when the cursor is not positioned on a row.
[ http://issues.apache.org/jira/browse/DERBY-276?page=all ] Daniel John Debrunner updated DERBY-276: Fix Version: 10.2.0.0 Description: If the cursor is not positioned on a row, calling ResultSet.relative() causes the following exception: Exception in thread main ERROR X0X87: ResultSet.relative(int row) cannot be called when the cursor is not positioned on a row. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301) at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getRelativeRow(ScrollInsensitiveResultSet.java:336) at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:366) at org.apache.derby.impl.jdbc.EmbedResultSet.relative(EmbedResultSet.java:1840) However, The 1.4.2 Javadoc says: Note: Calling the method relative(1) is identical to calling the method next() and calling the method relative(-1) is identical to calling the method previous(). (This is confirmed by the JDBC 3.0 spec, ch. 14.2.2) Since next() is valid, so should rs.relative(1) (and all other arguments, since a too large value will position the cursor after the last row, and a too low value will position it before the first). was: If the cursor is not positioned on a row, calling ResultSet.relative() causes the following exception: Exception in thread main ERROR X0X87: ResultSet.relative(int row) cannot be called when the cursor is not positioned on a row. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301) at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getRelativeRow(ScrollInsensitiveResultSet.java:336) at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:366) at org.apache.derby.impl.jdbc.EmbedResultSet.relative(EmbedResultSet.java:1840) However, The 1.4.2 Javadoc says: Note: Calling the method relative(1) is identical to calling the method next() and calling the method relative(-1) is identical to calling the method previous(). (This is confirmed by the JDBC 3.0 spec, ch. 14.2.2) Since next() is valid, so should rs.relative(1) (and all other arguments, since a too large value will position the cursor after the last row, and a too low value will position it before the first). Environment: Patch committed revision 208683. ResultSet.relative(int row) cannot be called when the cursor is not positioned on a row. Key: DERBY-276 URL: http://issues.apache.org/jira/browse/DERBY-276 Project: Derby Type: Improvement Components: JDBC Reporter: Bernt M. Johnsen Assignee: Bernt M. Johnsen Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-276-V2.diff If the cursor is not positioned on a row, calling ResultSet.relative() causes the following exception: Exception in thread main ERROR X0X87: ResultSet.relative(int row) cannot be called when the cursor is not positioned on a row. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301) at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getRelativeRow(ScrollInsensitiveResultSet.java:336) at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:366) at org.apache.derby.impl.jdbc.EmbedResultSet.relative(EmbedResultSet.java:1840) However, The 1.4.2 Javadoc says: Note: Calling the method relative(1) is identical to calling the method next() and calling the method relative(-1) is identical to calling the method previous(). (This is confirmed by the JDBC 3.0 spec, ch. 14.2.2) Since next() is valid, so should rs.relative(1) (and all other arguments, since a too large value will position the cursor after the last row, and a too low value will position it before the first). -- 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-31) Statement.setQueryTimeout() support.
[ http://issues.apache.org/jira/browse/DERBY-31?page=all ] Daniel John Debrunner updated DERBY-31: --- Fix Version: 10.2.0.0 Statement.setQueryTimeout() support. Key: DERBY-31 URL: http://issues.apache.org/jira/browse/DERBY-31 Project: Derby Type: New Feature Components: JDBC Environment: ALL Reporter: Ali Demir Assignee: Oyvind Bakksjo Fix For: 10.2.0.0 Attachments: DERBY-31.svn.diff, DERBY-31.svn.status, Derby-31.patch, QueryTimer.java, derbyall_report.txt Calling Statement.setQueryTimeout() throws exception saying that function is not supported. This is an important JDBC feature and is limiting our options to use Derby with our JDBC code. Implementing this JDBC function would make Derby much easier to adopt. -- 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: Are SYNONYMS exposed through DatabaseMetaData.getTables() api?
I have not implemented metadata support. It could be taken up as another item. I probably will... Satheesh Mamta Satoor wrote: Hi Satheesh, Just wondered if you got a chance to look at following. Also, if this is supported then is there a test for it? thanks, Mamta On 6/15/05, Mamta Satoor [EMAIL PROTECTED] wrote: Hi Satheesh, I was wondering if a JDBC program can use DatabaseMetaData.getTables() to get the synonyms by using "SYNONYM" as table type? http://java.sun.com/j2se/1.5.0/docs/api/java/sql/DatabaseMetaData.html thanks, Mamta
[jira] Commented: (DERBY-414) Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level
[ http://issues.apache.org/jira/browse/DERBY-414?page=comments#action_12314823 ] Kathey Marsden commented on DERBY-414: -- If I move the setTransactionIsolation to after the start of the xa transaction the isolation level gets set properly. It would appear that with embedded if you set the isolation level with SET CURRENT ISOLATION = UR; it gets reset on start of the xa transaction to the default. and that causes this problem with setTransactionIsolation with client. Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level - Key: DERBY-414 URL: http://issues.apache.org/jira/browse/DERBY-414 Project: Derby Type: Bug Components: Network Client Versions: 10.1.1.0, 10.2.0.0 Reporter: Kathey Marsden Attachments: deby414Repro.zip When using v10.1.1.0 of the Apache Derby Network Client JDBC Driver and configuring the TRANSACTION_READ_UNCOMMITTED isolation level, it is unable to read changes from another transaction which haven't been committed yet. $ java TestDerbyNSXA Connection number: 2. Database product: Apache Derby Database version: 10.2.0.0 alpha Driver name: Apache Derby Network Client JDBC Driver Driver version: 10.2.0.0 alpha Thread 1: transaction started (with read committed isolation) Thread 1: row updated first time. Connection number: 3. Thread 2: transaction started (with read uncommitted isolation) Query complete on thread 2. About to do ResultSet.next()... Thread 1: row updated second time. ResultSet.next() took 19067 milliseconds. Test fails. ResultSet next under read uncommitted isolation appears to have been blocked and unable to perform a dirty read. Thread 1: transaction committed. Thread 2: transaction committed. $ -- 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] Created: (DERBY-419) Support direct execution of derbynet.jar using the -jar option of the VM.
Support direct execution of derbynet.jar using the -jar option of the VM. - Key: DERBY-419 URL: http://issues.apache.org/jira/browse/DERBY-419 Project: Derby Type: Improvement Components: Network Server Reporter: Daniel John Debrunner Assigned to: Daniel John Debrunner Priority: Minor Support direct execution of derbynet.jar using the -jar option of the VM. E.g. java -jar lib/derbynet.jar start java -jar lib/derbynet.jar ping java -jar lib/derbynet.jar shutdown Add manifest entries Main-Class: org.apache.derby.drda.NetworkServerControl Class-Path: derby.jar -- 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] Created: (DERBY-420) missing classes in published javadoc incorrect copyright date
missing classes in published javadoc incorrect copyright date --- Key: DERBY-420 URL: http://issues.apache.org/jira/browse/DERBY-420 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Daniel John Debrunner Assigned to: Daniel John Debrunner Fix For: 10.1.1.0 Missing classes EmbeddedSimpleDataSource dblook All new client classes (driver, data source implementations) -- 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-384) Doc Review (CLOSED TO FURTHER COMMENTS): Tuning Derby
[ http://issues.apache.org/jira/browse/DERBY-384?page=all ] Andrew McIntyre resolved DERBY-384: --- Resolution: Fixed Committed, revision 208690. Doc Review (CLOSED TO FURTHER COMMENTS): Tuning Derby - Key: DERBY-384 URL: http://issues.apache.org/jira/browse/DERBY-384 Project: Derby Type: Improvement Components: Documentation Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.1.1.0 Attachments: derby384.diff This issue tracks comments for the manual known as Tuning Derby. The deadline for posting comments was Tuesday, June 28, noon Pacific time. PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have additional comments, please open a JIRA issue for a fixin in a future release, as there is not enough time to incorporate additional comments. Some guidelines to follow when posting comments to this issue are: - Try to make clear and concise comments about what you want changed whenever possible. Provide concrete comments that say Please change original to modified instead of generic comments like This section needs to be rewritten. - If you're reviewing the HTML Files copy, include the URL for the page in the review comment. Obtain the URL like this: * highlight the topic in the left frame * right click * choose Properties * copy and paste the address in the pop up box. - If you're reviewing the PDF copy, in the review comment: * Include the page number for the PDF, and indicate whether the number is the PDF sheet number or the printed page number. * Include the title of the section that the problem occurs in. If it's in a subsection, try to include the hierarchy of titles. - Please don't review the HTML Book copy -- it'll be time consuming to match up that copy with the underlying DITA 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] Commented: (DERBY-377) There is no information available in the manuals on how to upgrade a database from 10.0 to 10.1 version.
[ http://issues.apache.org/jira/browse/DERBY-377?page=comments#action_12314825 ] Suresh Thalamati commented on DERBY-377: Looks good to me.I am not sure of the following statements , In the Upgrades section , whether on upgrade from 10.0 to 10.1 following is done in the upgrade process: --- adds new columns to one system table (SYS.SYSCOLUMNS). --- adds a new class alias. Thanks -suresht There is no information available in the manuals on how to upgrade a database from 10.0 to 10.1 version. Key: DERBY-377 URL: http://issues.apache.org/jira/browse/DERBY-377 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Suresh Thalamati Fix For: 10.1.1.0 Attachments: derby377.zip I could not find any info in the 10.1 Alpha manuals on how to upgrade a 10.0 database to use a 10.1 engine in full upgrade mode or software mode. I think this feature is implemented in the 10.1 code line , but not documented yet. -- 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-377) There is no information available in the manuals on how to upgrade a database from 10.0 to 10.1 version.
[ http://issues.apache.org/jira/browse/DERBY-377?page=comments#action_12314826 ] Daniel John Debrunner commented on DERBY-377: - Review comments: Soft Upgrade --- Replace 'a soft upgrade allows you to upgrade an older Derby database and later use it with either the older version of Derby or the current version' with (or something similar with better wording :-) soft upgrade allows you run a newer Derby version against an existing database without upgrading it, and continuing to allow the older version to run against the database. Upgrading a database Remove extra trailing semi-colon on JDBC URL Upgrades -- The list of items its incorrect. I think the list should be - Marks the database as upgraded to the current release (10.1) - Allows use of new features such as SYNONYMS with the upgraded database. Change the soft upgrade wording on this page to match the soft upgrade section (see above) There is no information available in the manuals on how to upgrade a database from 10.0 to 10.1 version. Key: DERBY-377 URL: http://issues.apache.org/jira/browse/DERBY-377 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Suresh Thalamati Fix For: 10.1.1.0 Attachments: derby377.zip I could not find any info in the 10.1 Alpha manuals on how to upgrade a 10.0 database to use a 10.1 engine in full upgrade mode or software mode. I think this feature is implemented in the 10.1 code line , but not documented yet. -- 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-379) Doc review (CLOSED TO FURTHER COMMENTS): Getting Started with Derby
[ http://issues.apache.org/jira/browse/DERBY-379?page=all ] Andrew McIntyre resolved DERBY-379: --- Resolution: Fixed Committed modified patch, revision 208692. Doc review (CLOSED TO FURTHER COMMENTS): Getting Started with Derby Key: DERBY-379 URL: http://issues.apache.org/jira/browse/DERBY-379 Project: Derby Type: Improvement Components: Documentation Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.1.1.0 Attachments: derby379modified.diff This issue tracks comments for the Getting Started with Derby manual. The deadline for posting comments was Tuesday, June 28, noon Pacific time. PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have additional comments, please open a JIRA issue for a fixin in a future release, as there is not enough time to incorporate additional comments. Some guidelines to follow when posting comments to this issue are: - Try to make clear and concise comments about what you want changed whenever possible. Provide concrete comments that say Please change original to modified instead of generic comments like This section needs to be rewritten. - If you're reviewing the HTML Files copy, include the URL for the page in the review comment. Obtain the URL like this: * highlight the topic in the left frame * right click * choose Properties * copy and paste the address in the pop up box. - If you're reviewing the PDF copy, in the review comment: * Include the page number for the PDF, and indicate whether the number is the PDF sheet number or the printed page number. * Include the title of the section that the problem occurs in. If it's in a subsection, try to include the hierarchy of titles. - Please don't review the HTML Book copy -- it'll be time consuming to match up that copy with the underlying DITA 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] Created: (DERBY-421) starting an XA transaction resets the isolation level set with SET CURRENT ISOLATION
starting an XA transaction resets the isolation level set with SET CURRENT
ISOLATION
Key: DERBY-421
URL: http://issues.apache.org/jira/browse/DERBY-421
Project: Derby
Type: Sub-task
Reporter: Kathey Marsden
When an XA Transaction is started the isolation level set with SET CURRENT
ISOLATION gets reset to CS.
Embedded setTransactionIsolation does not have this problem but this problem
is the root cause of DERBY-414 because client implements
setTransactionIsolation by sending SET CURRENT ISOLATION
$ java TestSetCurrentIsolation
Database product: Apache Derby
Database version: 10.2.0.0 alpha
Driver name: Apache Derby Embedded JDBC Driver
Driver version: 10.2.0.0 alpha
SET CURRENT ISOLATION = UR
CURRENT ISOLATION: UR
getTransactionIsolation:TRANSACTION_READ_UNCOMMITTED:1
Isolation level after xa start
CURRENT ISOLATION: CS
getTransactionIsolation:TRANSACTION_READ_COMMITTED:2
$
import java.sql.*;
import javax.sql.*;
import javax.transaction.xa.*;
public class TestSetCurrentIsolation
{
public static void main(String[] args) throws Throwable
{
try
{
final org.apache.derby.jdbc.EmbeddedXADataSource ds =
new org.apache.derby.jdbc.EmbeddedXADataSource();
ds.setDatabaseName(C:\\drivers\\derby\\databases\\SCHEDDB);
ds.setUser(dbuser1);
ds.setPassword(**);
XAConnection xaConn = ds.getXAConnection();
Connection conn = xaConn.getConnection();
conn.setAutoCommit(true);
System.out.println(Database product: +
conn.getMetaData().getDatabaseProductName());
System.out.println(Database version: +
conn.getMetaData().getDatabaseProductVersion());
System.out.println(Driver name: +
conn.getMetaData().getDriverName());
System.out.println(Driver version:+
conn.getMetaData().getDriverVersion());
Statement stmt = conn.createStatement();
System.out.println(SET CURRENT ISOLATION = UR);
stmt.executeUpdate(SET CURRENT ISOLATION = UR);
showIsolationLevel(conn);
conn.setAutoCommit(false);
XAResource xaRes = xaConn.getXAResource();
Xid xid = new TestXid(1,(byte) 32, (byte) 32);
xaRes.start(xid, XAResource.TMNOFLAGS);
System.out.println(Isolation level after xa start);
showIsolationLevel(conn);
xaRes.end(xid, XAResource.TMSUCCESS);
xaRes.rollback(xid);
conn.close();
xaConn.close();
}
catch (SQLException sqlX)
{
System.out.println(Error on thread 1.);
do sqlX.printStackTrace();
while ((sqlX = sqlX.getNextException()) != null);
}
catch (Throwable th)
{
System.out.println(Error on thread 1.);
do th.printStackTrace();
while ((th = th.getCause()) != null);
}
}
/**
* @param conn
* @throws SQLException
*/
private static void showIsolationLevel(Connection conn) throws
SQLException {
PreparedStatement ps = conn.prepareStatement(VALUES CURRENT
ISOLATION);
ResultSet rs = ps.executeQuery();
//ResultSet rs = conn.createStatement().executeQuery(VALUES
CURRENT ISOLATION);
rs.next();
System.out.println(CURRENT ISOLATION: + rs.getString(1));
System.out.println(getTransactionIsolation: +
getIsoLevelName(conn.getTransactionIsolation()));
}
public static String getIsoLevelName(int level)
{
switch (level) {
case java.sql.Connection.TRANSACTION_REPEATABLE_READ:
return TRANSACTION_REAPEATABLE_READ: + level;
case java.sql.Connection.TRANSACTION_READ_COMMITTED:
return TRANSACTION_READ_COMMITTED: + level;
case java.sql.Connection.TRANSACTION_SERIALIZABLE:
return TRANSACTION_SERIALIZABLE: + level;
case java.sql.Connection.TRANSACTION_READ_UNCOMMITTED:
return TRANSACTION_READ_UNCOMMITTED: + level;
}
return UNEXPECTED_ISO_LEVEL;
}
}
--
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-414) With Network Client starting an XA transaction resets the isolation level set with setTransactionIsolation
[ http://issues.apache.org/jira/browse/DERBY-414?page=all ] Kathey Marsden updated DERBY-414: - Summary: With Network Client starting an XA transaction resets the isolation level set with setTransactionIsolation (was: Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level) Description: When using v10.1.1.0 of the Apache Derby Network Client JDBC Driver and configuring the TRANSACTION_READ_UNCOMMITTED isolation level, it is unable to read changes from another transaction which haven't been committed yet if the setTransactionIsolation call comes before the xa transation is started. $ java TestDerbyNSXA Connection number: 2. Database product: Apache Derby Database version: 10.2.0.0 alpha Driver name: Apache Derby Network Client JDBC Driver Driver version: 10.2.0.0 alpha Thread 1: transaction started (with read committed isolation) Thread 1: row updated first time. Connection number: 3. Thread 2: transaction started (with read uncommitted isolation) Query complete on thread 2. About to do ResultSet.next()... Thread 1: row updated second time. ResultSet.next() took 19067 milliseconds. Test fails. ResultSet next under read uncommitted isolation appears to have been blocked and unable to perform a dirty read. Thread 1: transaction committed. Thread 2: transaction committed. $ was: When using v10.1.1.0 of the Apache Derby Network Client JDBC Driver and configuring the TRANSACTION_READ_UNCOMMITTED isolation level, it is unable to read changes from another transaction which haven't been committed yet. $ java TestDerbyNSXA Connection number: 2. Database product: Apache Derby Database version: 10.2.0.0 alpha Driver name: Apache Derby Network Client JDBC Driver Driver version: 10.2.0.0 alpha Thread 1: transaction started (with read committed isolation) Thread 1: row updated first time. Connection number: 3. Thread 2: transaction started (with read uncommitted isolation) Query complete on thread 2. About to do ResultSet.next()... Thread 1: row updated second time. ResultSet.next() took 19067 milliseconds. Test fails. ResultSet next under read uncommitted isolation appears to have been blocked and unable to perform a dirty read. Thread 1: transaction committed. Thread 2: transaction committed. $ With Network Client starting an XA transaction resets the isolation level set with setTransactionIsolation -- Key: DERBY-414 URL: http://issues.apache.org/jira/browse/DERBY-414 Project: Derby Type: Bug Components: Network Client Versions: 10.1.1.0, 10.2.0.0 Reporter: Kathey Marsden Attachments: deby414Repro.zip When using v10.1.1.0 of the Apache Derby Network Client JDBC Driver and configuring the TRANSACTION_READ_UNCOMMITTED isolation level, it is unable to read changes from another transaction which haven't been committed yet if the setTransactionIsolation call comes before the xa transation is started. $ java TestDerbyNSXA Connection number: 2. Database product: Apache Derby Database version: 10.2.0.0 alpha Driver name: Apache Derby Network Client JDBC Driver Driver version: 10.2.0.0 alpha Thread 1: transaction started (with read committed isolation) Thread 1: row updated first time. Connection number: 3. Thread 2: transaction started (with read uncommitted isolation) Query complete on thread 2. About to do ResultSet.next()... Thread 1: row updated second time. ResultSet.next() took 19067 milliseconds. Test fails. ResultSet next under read uncommitted isolation appears to have been blocked and unable to perform a dirty read. Thread 1: transaction committed. Thread 2: transaction committed. $ -- 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-383) Doc Review (CLOSED TO FURTHER COMMENTS): Derby Tools and Utilities Guide
[ http://issues.apache.org/jira/browse/DERBY-383?page=all ] Andrew McIntyre resolved DERBY-383: --- Resolution: Fixed Committed, revision 208693. Doc Review (CLOSED TO FURTHER COMMENTS): Derby Tools and Utilities Guide Key: DERBY-383 URL: http://issues.apache.org/jira/browse/DERBY-383 Project: Derby Type: Improvement Components: Documentation Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.1.1.0 Attachments: derby383.diff This issue tracks comments for the Derby Tools and Utilities Guide. The deadline for posting comments was Tuesday, June 28, noon Pacific time. PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have additional comments, please open a JIRA issue for a fixin in a future release, as there is not enough time to incorporate additional comments. Some guidelines to follow when posting comments to this issue are: - Try to make clear and concise comments about what you want changed whenever possible. Provide concrete comments that say Please change original to modified instead of generic comments like This section needs to be rewritten. - If you're reviewing the HTML Files copy, include the URL for the page in the review comment. Obtain the URL like this: * highlight the topic in the left frame * right click * choose Properties * copy and paste the address in the pop up box. - If you're reviewing the PDF copy, in the review comment: * Include the page number for the PDF, and indicate whether the number is the PDF sheet number or the printed page number. * Include the title of the section that the problem occurs in. If it's in a subsection, try to include the hierarchy of titles. - Please don't review the HTML Book copy -- it'll be time consuming to match up that copy with the underlying DITA 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] Resolved: (DERBY-381) Doc review (CLOSED TO FURTHER COMMENTS): Derby Server and Admin Guide
[ http://issues.apache.org/jira/browse/DERBY-381?page=all ] Andrew McIntyre resolved DERBY-381: --- Resolution: Fixed Committed, revision 208694. Doc review (CLOSED TO FURTHER COMMENTS): Derby Server and Admin Guide - Key: DERBY-381 URL: http://issues.apache.org/jira/browse/DERBY-381 Project: Derby Type: Improvement Components: Documentation Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.1.1.0 Attachments: derby381.diff This issue tracks comments for the Derby Server and Administration Guide. The deadline for posting comments WAS Tuesday, June 28, noon Pacific time. PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have additional comments, please open a JIRA issue for a fixin in a future release, as there is not enough time to incorporate additional comments. Some guidelines to follow when posting comments to this issue are: - Try to make clear and concise comments about what you want changed whenever possible. Provide concrete comments that say Please change original to modified instead of generic comments like This section needs to be rewritten. - If you're reviewing the HTML Files copy, include the URL for the page in the review comment. Obtain the URL like this: * highlight the topic in the left frame * right click * choose Properties * copy and paste the address in the pop up box. - If you're reviewing the PDF copy, in the review comment: * Include the page number for the PDF, and indicate whether the number is the PDF sheet number or the printed page number. * Include the title of the section that the problem occurs in. If it's in a subsection, try to include the hierarchy of titles. - Please don't review the HTML Book copy -- it'll be time consuming to match up that copy with the underlying DITA 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] Created: (DERBY-424) Queryplan for a query using SESSION schema view is incorrectly put in statement cache. This could cause incorrect plan getting executed later if a temp. table is created wi
Queryplan for a query using SESSION schema view is incorrectly put in statement cache. This could cause incorrect plan getting executed later if a temp. table is created with that name. - Key: DERBY-424 URL: http://issues.apache.org/jira/browse/DERBY-424 Project: Derby Type: Bug Components: SQL Versions: 10.1.1.0 Environment: generic Reporter: Satheesh Bandaram Priority: Minor See DERBY-405 for some discussion related this issue. I suspect this is because of statement caching. Derby doesn't seem to recognise we have a temporary table that just overloaded an existing physical table. It would have been good to avoid permanent tables/views/synonyms in SESSION schema. Not sure what we should do now about this, though. ij create view session.st1 as select * from t; 0 rows inserted/updated/deleted ij select * from session.st1; I |J |K --- 1 |1 |NULL 2 |2 |NULL 3 |3 |NULL 4 |4 |NULL 4 rows selected ij select * from t; I |J |K --- 1 |1 |NULL 2 |2 |NULL 3 |3 |NULL 4 |4 |NULL 4 rows selected ij declare global temporary table st1(c11 int, c12 int) on commit preserve rows not logged; 0 rows inserted/updated/deleted ij select * from session.st1; I |J |K --- 1 |1 |NULL 2 |2 |NULL 3 |3 |NULL 4 |4 |NULL 4 rows selected ij select * from session.st1; This statement has an extra space between FROM and session.st1 C11 |C12 --- 0 rows selected -- 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-405) SYNONYM should not be allowed in SESSION schema because that can confusion wih temporary tables
[ http://issues.apache.org/jira/browse/DERBY-405?page=all ] Satheesh Bandaram resolved DERBY-405: - Resolution: Fixed Fix has been merged into trunk. This may get ported to 10.1, if Andrew, the release czar, decides this is important for 10.1 release. SYNONYM should not be allowed in SESSION schema because that can confusion wih temporary tables --- Key: DERBY-405 URL: http://issues.apache.org/jira/browse/DERBY-405 Project: Derby Type: Bug Components: SQL Versions: 10.2.0.0 Reporter: Mamta A. Satoor Fix For: 10.2.0.0 A user should not be able to create a synonym in SESSION schema eg create synonym session.st1 for app.t1; select * from session.st1; -- refers to app.t1 declare global temporary table st1(c11 int, c12 int) on commit preserve rows not logged; select * from session.st1; -- refers to app.t1, is that right? I think the last select * from session.st1 should goto temporary table st1 since any references to objects in SESSION schema should first find a match against a temporary table if one by that name exists. We already discourage users from defining objects other than temporary table in SESSION schema in the reference manual Using SESSION as the schema name of a physical table will not cause an error, but is discouraged. The SESSION schema name should be reserved for the temporary table schema. But, IMHO, it will be nice to enforce this wherever possible in Derby code rather than leaving it upto the users to avoid confusion. -- 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-405) SYNONYM should not be allowed in SESSION schema because that can confusion wih temporary tables
[ http://issues.apache.org/jira/browse/DERBY-405?page=comments#action_12314833 ] Satheesh Bandaram commented on DERBY-405: - Jeff, can you alter CREATE SYNONYM section to say creating synonyms in SESSION schema is not allowed? SYNONYM should not be allowed in SESSION schema because that can confusion wih temporary tables --- Key: DERBY-405 URL: http://issues.apache.org/jira/browse/DERBY-405 Project: Derby Type: Bug Components: SQL Versions: 10.2.0.0 Reporter: Mamta A. Satoor Fix For: 10.2.0.0 A user should not be able to create a synonym in SESSION schema eg create synonym session.st1 for app.t1; select * from session.st1; -- refers to app.t1 declare global temporary table st1(c11 int, c12 int) on commit preserve rows not logged; select * from session.st1; -- refers to app.t1, is that right? I think the last select * from session.st1 should goto temporary table st1 since any references to objects in SESSION schema should first find a match against a temporary table if one by that name exists. We already discourage users from defining objects other than temporary table in SESSION schema in the reference manual Using SESSION as the schema name of a physical table will not cause an error, but is discouraged. The SESSION schema name should be reserved for the temporary table schema. But, IMHO, it will be nice to enforce this wherever possible in Derby code rather than leaving it upto the users to avoid confusion. -- 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-382) Doc Review (CLOSED TO FURTHER COMMENTS): Derby Reference Manual
[ http://issues.apache.org/jira/browse/DERBY-382?page=all ] Jeff Levitt updated DERBY-382: -- Attachment: derby382.diff The attached patch makes the changes requested in this doc review. I have created sample output on my own site: HTML files: http://derby.mylevita.com/tools/ PDF: http://derby.mylevita.com/tools/derbytools.pdf The patch affects EVERY dita file, but not the content for each file. This is because I modified the year in the dita source file copyrights for each file from 2004 to 2005. So while every file is listed in the patch, the only changes that will appear in the PDF and HTML files are those requested in this doc review. I was not able to incorporate several requests due to the need for either more input or more time. I have created a new JIRA issue for fix in 10.2 outlining these requirements. It is http://issues.apache.org/jira/browse/DERBY-423 Also, note that I have made the change to the trademarks page in the same way that I did to the Getting Started guide patch in http://issues.apache.org/jira/browse/DERBY-379. Doc Review (CLOSED TO FURTHER COMMENTS): Derby Reference Manual --- Key: DERBY-382 URL: http://issues.apache.org/jira/browse/DERBY-382 Project: Derby Type: Improvement Components: Documentation Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.1.1.0 Attachments: derby382.diff This issue tracks comments for the Derby Reference Manual. The deadline for posting comments was Tuesday, June 28, noon Pacific time. PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have additional comments, please open a JIRA issue for a fixin in a future release, as there is not enough time to incorporate additional comments. Some guidelines to follow when posting comments to this issue are: - Try to make clear and concise comments about what you want changed whenever possible. Provide concrete comments that say Please change original to modified instead of generic comments like This section needs to be rewritten. - If you're reviewing the HTML Files copy, include the URL for the page in the review comment. Obtain the URL like this: * highlight the topic in the left frame * right click * choose Properties * copy and paste the address in the pop up box. - If you're reviewing the PDF copy, in the review comment: * Include the page number for the PDF, and indicate whether the number is the PDF sheet number or the printed page number. * Include the title of the section that the problem occurs in. If it's in a subsection, try to include the hierarchy of titles. - Please don't review the HTML Book copy -- it'll be time consuming to match up that copy with the underlying DITA 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] Commented: (DERBY-382) Doc Review (CLOSED TO FURTHER COMMENTS): Derby Reference Manual
[ http://issues.apache.org/jira/browse/DERBY-382?page=comments#action_12314834 ] Jeff Levitt commented on DERBY-382: --- Forgot to change the links in my posting template to point to the ref manual on my site: http://derby.mylevita.com/ref/refderby.pdf http://derby.mylevita.com/ref/ Doc Review (CLOSED TO FURTHER COMMENTS): Derby Reference Manual --- Key: DERBY-382 URL: http://issues.apache.org/jira/browse/DERBY-382 Project: Derby Type: Improvement Components: Documentation Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.1.1.0 Attachments: derby382.diff This issue tracks comments for the Derby Reference Manual. The deadline for posting comments was Tuesday, June 28, noon Pacific time. PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have additional comments, please open a JIRA issue for a fixin in a future release, as there is not enough time to incorporate additional comments. Some guidelines to follow when posting comments to this issue are: - Try to make clear and concise comments about what you want changed whenever possible. Provide concrete comments that say Please change original to modified instead of generic comments like This section needs to be rewritten. - If you're reviewing the HTML Files copy, include the URL for the page in the review comment. Obtain the URL like this: * highlight the topic in the left frame * right click * choose Properties * copy and paste the address in the pop up box. - If you're reviewing the PDF copy, in the review comment: * Include the page number for the PDF, and indicate whether the number is the PDF sheet number or the printed page number. * Include the title of the section that the problem occurs in. If it's in a subsection, try to include the hierarchy of titles. - Please don't review the HTML Book copy -- it'll be time consuming to match up that copy with the underlying DITA 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-424) Queryplan for a query using SESSION schema view is incorrectly put in statement cache. This could cause incorrect plan getting executed later if a temp. table is created wi
[ http://issues.apache.org/jira/browse/DERBY-424?page=all ] Satheesh Bandaram updated DERBY-424: Version: 10.2.0.0 Queryplan for a query using SESSION schema view is incorrectly put in statement cache. This could cause incorrect plan getting executed later if a temp. table is created with that name. - Key: DERBY-424 URL: http://issues.apache.org/jira/browse/DERBY-424 Project: Derby Type: Bug Components: SQL Versions: 10.1.1.0, 10.2.0.0 Environment: generic Reporter: Satheesh Bandaram Priority: Minor See DERBY-405 for some discussion related this issue. I suspect this is because of statement caching. Derby doesn't seem to recognise we have a temporary table that just overloaded an existing physical table. It would have been good to avoid permanent tables/views/synonyms in SESSION schema. Not sure what we should do now about this, though. ij create view session.st1 as select * from t; 0 rows inserted/updated/deleted ij select * from session.st1; I |J |K --- 1 |1 |NULL 2 |2 |NULL 3 |3 |NULL 4 |4 |NULL 4 rows selected ij select * from t; I |J |K --- 1 |1 |NULL 2 |2 |NULL 3 |3 |NULL 4 |4 |NULL 4 rows selected ij declare global temporary table st1(c11 int, c12 int) on commit preserve rows not logged; 0 rows inserted/updated/deleted ij select * from session.st1; I |J |K --- 1 |1 |NULL 2 |2 |NULL 3 |3 |NULL 4 |4 |NULL 4 rows selected ij select * from session.st1; This statement has an extra space between FROM and session.st1 C11 |C12 --- 0 rows selected -- 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-377) There is no information available in the manuals on how to upgrade a database from 10.0 to 10.1 version.
[ http://issues.apache.org/jira/browse/DERBY-377?page=all ] Andrew McIntyre resolved DERBY-377: --- Resolution: Fixed Committed, revision 208695. There is no information available in the manuals on how to upgrade a database from 10.0 to 10.1 version. Key: DERBY-377 URL: http://issues.apache.org/jira/browse/DERBY-377 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Suresh Thalamati Fix For: 10.1.1.0 Attachments: derby377modified.zip I could not find any info in the 10.1 Alpha manuals on how to upgrade a 10.0 database to use a 10.1 engine in full upgrade mode or software mode. I think this feature is implemented in the 10.1 code line , but not documented yet. -- 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-420) missing classes in published javadoc incorrect copyright date
[ http://issues.apache.org/jira/browse/DERBY-420?page=comments#action_12314837 ] Andrew McIntyre commented on DERBY-420: --- I checked in a fix for the missing classes to the trunk and posted a copy for review on my public_html: http://people.apache.org/~fuzzylogic/publishedapi/ I'll merge this over to the branch shortly. missing classes in published javadoc incorrect copyright date --- Key: DERBY-420 URL: http://issues.apache.org/jira/browse/DERBY-420 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Daniel John Debrunner Assignee: Daniel John Debrunner Fix For: 10.1.1.0 Missing classes EmbeddedSimpleDataSource dblook All new client classes (driver, data source implementations) -- 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-424) Queryplan for a query using SESSION schema view is incorrectly put in statement cache. This could cause incorrect plan getting executed later if a temp. table is created w
[ http://issues.apache.org/jira/browse/DERBY-424?page=all ] Mamta A. Satoor reassigned DERBY-424: - Assign To: Mamta A. Satoor Queryplan for a query using SESSION schema view is incorrectly put in statement cache. This could cause incorrect plan getting executed later if a temp. table is created with that name. - Key: DERBY-424 URL: http://issues.apache.org/jira/browse/DERBY-424 Project: Derby Type: Bug Components: SQL Versions: 10.1.1.0, 10.2.0.0 Environment: generic Reporter: Satheesh Bandaram Assignee: Mamta A. Satoor Priority: Minor See DERBY-405 for some discussion related this issue. I suspect this is because of statement caching. Derby doesn't seem to recognise we have a temporary table that just overloaded an existing physical table. It would have been good to avoid permanent tables/views/synonyms in SESSION schema. Not sure what we should do now about this, though. ij create view session.st1 as select * from t; 0 rows inserted/updated/deleted ij select * from session.st1; I |J |K --- 1 |1 |NULL 2 |2 |NULL 3 |3 |NULL 4 |4 |NULL 4 rows selected ij select * from t; I |J |K --- 1 |1 |NULL 2 |2 |NULL 3 |3 |NULL 4 |4 |NULL 4 rows selected ij declare global temporary table st1(c11 int, c12 int) on commit preserve rows not logged; 0 rows inserted/updated/deleted ij select * from session.st1; I |J |K --- 1 |1 |NULL 2 |2 |NULL 3 |3 |NULL 4 |4 |NULL 4 rows selected ij select * from session.st1; This statement has an extra space between FROM and session.st1 C11 |C12 --- 0 rows selected -- 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-382) Doc Review (CLOSED TO FURTHER COMMENTS): Derby Reference Manual
[ http://issues.apache.org/jira/browse/DERBY-382?page=all ] Andrew McIntyre resolved DERBY-382: --- Resolution: Fixed Applied provided patch with revision 208698. Further comments should be attached to issue DERBY-423. Doc Review (CLOSED TO FURTHER COMMENTS): Derby Reference Manual --- Key: DERBY-382 URL: http://issues.apache.org/jira/browse/DERBY-382 Project: Derby Type: Improvement Components: Documentation Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.1.1.0 Attachments: derby382.diff This issue tracks comments for the Derby Reference Manual. The deadline for posting comments was Tuesday, June 28, noon Pacific time. PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have additional comments, please open a JIRA issue for a fixin in a future release, as there is not enough time to incorporate additional comments. Some guidelines to follow when posting comments to this issue are: - Try to make clear and concise comments about what you want changed whenever possible. Provide concrete comments that say Please change original to modified instead of generic comments like This section needs to be rewritten. - If you're reviewing the HTML Files copy, include the URL for the page in the review comment. Obtain the URL like this: * highlight the topic in the left frame * right click * choose Properties * copy and paste the address in the pop up box. - If you're reviewing the PDF copy, in the review comment: * Include the page number for the PDF, and indicate whether the number is the PDF sheet number or the printed page number. * Include the title of the section that the problem occurs in. If it's in a subsection, try to include the hierarchy of titles. - Please don't review the HTML Book copy -- it'll be time consuming to match up that copy with the underlying DITA 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
[doc] Legacy content on the doc server at Apache
This is a minor issue, and I wasnt sure whether it was something that needed a JIRA issue. I've noticed that some of the html output files for the docs that have been removed from the manuals for whatever reason are still on the server. It might be nice to clear out those directories every now and then to make sure these files aren't hanging around too long. More lengthy detail: I'm guessing this is because the process that creates our nightly builds simply copies over the new html files each night without removing what's in the directory currently. So if file X is deleted from the manual, it still appears, although the content cannot be found from the table of contents and is not linked to from any other page (it is an island). This wouldn't be a problem except for the fact that we have JIRA issues where people have asked for certain pages to be removed and provided links to them. Well, if one goes back to those JIRA issues and checks to see if the page has been removed, they are going to get a working link and not realize that the file is not in the manual anymore. Also, I'm not sure if web search crawlers access our documentation, but I imagine that if they do, or if we want them to in the future, these pages would show up in searches and provide potentially mistaken info.
[jira] Commented: (DERBY-380) Doc Review (CLOSED TO FURTHER COMMENTS): Derby Developer's Guide
[ http://issues.apache.org/jira/browse/DERBY-380?page=comments#action_12314839 ] Jeff Levitt commented on DERBY-380: --- Suresh requested in Derby-377 (too late for that commit): In preparing for Upgrade section , Following step is not required: 1. Force a checkpoint with the earlier version of Derby. To force a checkpoint, connect to the database with the older version of the Derby software and issue a shutdown request using the shutdown=true attribute on the database connection URL, as shown in the following example: /* in a java program */ DriverManager.getConnection(jdbc:derby:sample;shutdown=true); Doc Review (CLOSED TO FURTHER COMMENTS): Derby Developer's Guide Key: DERBY-380 URL: http://issues.apache.org/jira/browse/DERBY-380 Project: Derby Type: Improvement Components: Documentation Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.1.1.0 This issue tracks comments for the Derby Developer's Guide. The deadline for posting comments was Tuesday, June 28, noon Pacific time. PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have additional comments, please open a JIRA issue for a fixin in a future release, as there is not enough time to incorporate additional comments. Some guidelines to follow when posting comments to this issue are: - Try to make clear and concise comments about what you want changed whenever possible. Provide concrete comments that say Please change original to modified instead of generic comments like This section needs to be rewritten. - If you're reviewing the HTML Files copy, include the URL for the page in the review comment. Obtain the URL like this: * highlight the topic in the left frame * right click * choose Properties * copy and paste the address in the pop up box. - If you're reviewing the PDF copy, in the review comment: * Include the page number for the PDF, and indicate whether the number is the PDF sheet number or the printed page number. * Include the title of the section that the problem occurs in. If it's in a subsection, try to include the hierarchy of titles. - Please don't review the HTML Book copy -- it'll be time consuming to match up that copy with the underlying DITA 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
Client data source published api javadoc cleanup
Now the client objects are part of the published api I did some cleanup
of the javadoc comments, attached is the patch. I'll commit assuming no
objections once my derbyall tests run.
M org\apache\derby\jdbc\ClientXADataSource.java
M org\apache\derby\jdbc\ClientConnectionPoolDataSource.java
M org\apache\derby\jdbc\ClientBaseDataSource.java
M org\apache\derby\jdbc\ClientDataSource.java
- Change instance fields to be private, their api is their getter/setter
methods (removes them from the javadoc)
- remove unused constant fields, YES,NO,NOSET
- Add a getPassword() method. password is a standard data source
property and JDBC spec says all supported data source properties must
have getter and setter methods.
- Remove some unused methods
- Make methods only used within the package and intended for internal
use 'package protected', removes them from the javadoc
Still most of the methods have no comments and some of the classes don't
either. Some comments along the lines of the Embedded* JDBC objects
would be good, especially stressing these are the client api.
Also moving some code around would remove some of the public methods, or
allow them to be package protected. These are methods that are not
intended to be part of the public api. I'll submit that in a separate patch.
Another interesting issue is all the propertyKey_* fields appear in the
javadoc, though they are not part of the public api, but how they are
used requires they be public. I think it would be good to somehow fix
this, rather than having javadoc comments saying 'internal field - do
not use'.
Dan.
Index: org/apache/derby/jdbc/ClientXADataSource.java
===
--- org/apache/derby/jdbc/ClientXADataSource.java (revision 208699)
+++ org/apache/derby/jdbc/ClientXADataSource.java (working copy)
@@ -39,7 +39,7 @@
}
public XAConnection getXAConnection() throws SQLException {
-return getXAConnection(user, password);
+return getXAConnection(getUser(), getPassword());
}
public XAConnection getXAConnection(String user, String password) throws
SQLException {
Index: org/apache/derby/jdbc/ClientConnectionPoolDataSource.java
===
--- org/apache/derby/jdbc/ClientConnectionPoolDataSource.java (revision
208699)
+++ org/apache/derby/jdbc/ClientConnectionPoolDataSource.java (working copy)
@@ -47,7 +47,7 @@
if (dncLogWriter != null) {
dncLogWriter.traceEntry(this, getPooledConnection);
}
-PooledConnection pooledConnection = getPooledConnectionX(dncLogWriter,
this, user, password);
+PooledConnection pooledConnection = getPooledConnectionX(dncLogWriter,
this, getUser(), getPassword());
if (dncLogWriter != null) {
dncLogWriter.traceExit(this, getPooledConnection,
pooledConnection);
}
@@ -67,19 +67,6 @@
return pooledConnection;
}
-// method that establishes the initial physical connection using DS
properties instead of CPDS properties.
-public PooledConnection getPooledConnection(ClientDataSource ds, String
user, String password) throws SQLException {
-LogWriter dncLogWriter =
ds.computeDncLogWriterForNewConnection(_cpds);
-if (dncLogWriter != null) {
-dncLogWriter.traceEntry(this, getPooledConnection, ds, user,
escaped);
-}
-PooledConnection pooledConnection = getPooledConnectionX(dncLogWriter,
ds, user, password);
-if (dncLogWriter != null) {
-dncLogWriter.traceExit(this, getPooledConnection,
pooledConnection);
-}
-return pooledConnection;
-}
-
// method that establishes the initial physical connection
// using DS properties instead of CPDS properties.
private PooledConnection getPooledConnectionX(LogWriter dncLogWriter,
ClientDataSource ds, String user, String password) throws SQLException {
Index: org/apache/derby/jdbc/ClientBaseDataSource.java
===
--- org/apache/derby/jdbc/ClientBaseDataSource.java (revision 208699)
+++ org/apache/derby/jdbc/ClientBaseDataSource.java (working copy)
@@ -60,7 +60,7 @@
//-contructors/finalizers-
// This class is abstract, hide the default constructor
-protected ClientBaseDataSource() {
+ClientBaseDataSource() {
}
// loginTimeout
---
@@ -72,7 +72,7 @@
*
* @serial
*/
-protected int loginTimeout = propertyDefault_loginTimeout;
+private int loginTimeout = propertyDefault_loginTimeout;
public final static String propertyKey_loginTimeout = loginTimeout;
public static final int propertyDefault_loginTimeout = 0;
@@ -91,7 +91,7 @@
*
* @see #traceLevel
*/
-
[jira] Created: (DERBY-426) documentation need to be modified to reflect the derby-390 fix(once it is committed) , schem , table , column names need to be in case-sensitive form.
documentation need to be modified to reflect the derby-390 fix(once it is committed) , schem , table , column names need to be in case-sensitive form. --- Key: DERBY-426 URL: http://issues.apache.org/jira/browse/DERBY-426 Project: Derby Type: Sub-task Components: Documentation Versions: 10.1.1.0 Reporter: Suresh Thalamati Tools utilities Guide: Using bulk import/export chapter: BulkImport/ Arguments to the import procedure section: add the following in the end: If you created a schema, table or column name as a non-delimited identifier, you must pass the name in all upper case. If you created a schema, table or column name as a delimited identifier, you must pass the name in the same case as it was created. BulkExport/Arguments to the export procedure: add the following in the end: If you have created a schema or table name as a non-delimited identifier, you must pass the name in all upper case. If you created a schema or table name as a delimited identifier, you must pass the name in the same case as it was created. Examples of bulk import and export section: Add the following two examples to this section: The following example shows how to import data into the Order table (this table was created using delimited quotes to specify the name becuase the word 'Order' is a SQL reserved word) table in a sample database from the myfile.del file. CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE (null,'Order','myfile.del',null,null,null,0); The following example shows how to export data from the Order table (this table was created using delimited quotes to specify the name becuase the word 'Order' is a SQL reserved word) in a sample database from the myfile.del file. CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE (null,'Order','myfile.del',null,null,null); Modify the table name 'staff' to all upper case 'STAFF' for all import/export statements except for EXPORT_QUERY example. for example: CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE (null,'staff','myfile.del',null,null, null,0); toCALL SYSCS_UTIL.SYSCS_IMPORT_TABLE (null,'STAFF,'myfile.del',null,null,null,0); Importing into tables with identity columns section : modify table name 'tab1' to 'TAB1' and all column names also to upper case: CALL SYSCS_UTIL.SYSCS_IMPORT_DATA (NULL, 'tab1', 'c1,c3,c4' , null, 'myfile.del',null, null,null,0) to CALL SYSCS_UTIL.SYSCS_IMPORT_DATA (NULL, 'TAB1', 'C1,C3,C4' , null, 'myfile.del',null, null,null,0) CALL SYSCS_UTIL.SYSCS_IMPORT_DATA (NULL, 'tab1', 'c1,c3,c4' , '1,3,4','empfile.del',null, null,null,0) to CALL SYSCS_UTIL.SYSCS_IMPORT_DATA (NULL, 'TAB1', 'C1,C3,C4' , '1,3,4','empfile.del',null, null,null,0) Executing import/export procedures from JDBC: modify ps.setString(2,staff); to ps.setString(2,STAFF); CODESET values for import/export section: CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE (NULL,'staff','staff.dat',NULL,NULL,'UTF-8') to CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE(NULL,'STAFF','staff.dat',NULL,NULL,'UTF-8') and CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE(NULL,'STAFF','staff.dat',NULL,NULL,'UTF-8',0) In the REFERENCE Book Please do the following changes to import/export procedures: SYSCS_UTIL.SYSCS_EXPORT_TABLE: add the following before the example: If you have created a schema or table name as a non-delimited identifier, you must pass the name in all upper case. If you created a schema or table name as a delimited identifier, you must pass the name in the same case as it was created. modify tablename 'staff' to upper case 'STAFF' CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE (null, 'staff', 'myfile.del', null, null, null) to CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE (null, 'STAFF', 'myfile.del', null, null, null) SYSCS_UTIL.SYSCS_IMPORT_TABLE section: add the following before the example: If you created a schema or table name as a non-delimited identifier, you must pass the name in all upper case. If you created a schema or table name as a delimited identifier, you must pass the name in the same case as it was created. modify table name 'staff' to 'STAFF' CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE(null, 'staff', 'c:/output/myfile.del', ';', '%', null,0); to CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE(null, 'STAFF', 'c:/output/myfile.del', ';', '%', null,0); SYSCS_UTIL.SYSCS_IMPORT_DATA section: If you created a schema, table or column name as a non-delimited identifier, you must pass the name in all upper case. If you created a schema, table or column name as a delimited identifier, you must pass the name in the same case as it was created modify CALL SYSCS_UTIL.SYSCS_IMPORT_DATA(NULL, 'staff', null, '1,3,4', 'data.del', null, null, null,0) to CALL SYSCS_UTIL.SYSCS_IMPORT_DATA(NULL, 'STAFF', null, '1,3,4', 'data.del', null, null, null,0) -- This message is automatically generated by JIRA. - If you think it
[jira] Commented: (DERBY-390) Import/export fails with table names that are quoted in SQL like import to table Order
[ http://issues.apache.org/jira/browse/DERBY-390?page=comments#action_12314842 ] Suresh Thalamati commented on DERBY-390: Same patch (derby390.diff) also works fine for 10.1 branch also. Ran Derbyall on 10.1 after applying the patch for a 10.1 client , all tests passed. Import/export fails with table names that are quoted in SQL like import to table Order -- Key: DERBY-390 URL: http://issues.apache.org/jira/browse/DERBY-390 Project: Derby Type: Bug Versions: 10.0.2.1 Reporter: Suresh Thalamati Assignee: Suresh Thalamati Attachments: derby390.diff import fails irrespective off whether the name is passed as a quoted sttring or not: ij call SYSCS_UTIL.SYSCS_IMPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null, 0) ; ERROR XIE0M: Table 'ORDER' does not exist. ij call SYSCS_UTIL.SYSCS_IMPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null, 0) ; ERROR 38000: The exception 'SQL Exception: Syntax error: Encountered ORDER at line 1, column 13.' was thrown while evaluating an expression. ERROR 42X01: Syntax error: Encountered ORDER at line 1, column 13. Export works with a quoted table name but fails if the name is not quoted : call SYSCS_UTIL.SYSCS_EXPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null) ; --- PASSES ij call SYSCS_UTIL.SYSCS_EXPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null) ; ERROR 38000: The exception 'SQL Exception: Syntax error: Encountered ORDER at line 1, column 15.' was thrown while evaluating an expression. ERROR 42X01: Syntax error: Encountered ORDER at line 1, column 15. Repro: connect 'jdbc:derby:wombat;create=true'; create table ORDER(a int ) ; insert into ORDER values(1) ; insert into ORDER values(2) ; insert into ORDER values(3) ; call SYSCS_UTIL.SYSCS_EXPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null) ; -- Perform Import call SYSCS_UTIL.SYSCS_IMPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null, 0) ; ERROR XIE0M: Table 'ORDER' does not exist. call SYSCS_UTIL.SYSCS_IMPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null, 0) ; ERROR 38000: The exception 'SQL Exception: Syntax error: Encountered ORDER at line 1, column 13.' was thrown while evaluating an expression. ERROR 42X01: Syntax error: Encountered ORDER at line 1, column 13. Note: I think the same problem will occur with when quoted schema Names and column names are passed to import/export procedures. -- 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-385) servlet Back to Main Page link points to csnet instead of derbynet
[ http://issues.apache.org/jira/browse/DERBY-385?page=comments#action_12314843 ] Myrna van Lunteren commented on DERBY-385: -- When this gets fixed, maybe it makes sense to fix up the comments re db2j.locale and db2j.codeset. servlet Back to Main Page link points to csnet instead of derbynet -- Key: DERBY-385 URL: http://issues.apache.org/jira/browse/DERBY-385 Project: Derby Type: Bug Versions: 10.1.1.0 Reporter: Myrna van Lunteren Priority: Trivial Fix For: 10.2.0.0 The link at the top of the servlet java/drda/org/apache/derby/drda/NetServlet.java links to csnet (because of the static String SERVLET_ADDRESS). However, the servlet address is now derbynet. -- 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-377) There is no information available in the manuals on how to upgrade a database from 10.0 to 10.1 version.
[ http://issues.apache.org/jira/browse/DERBY-377?page=comments#action_12314852 ] Andrew McIntyre commented on DERBY-377: --- Jeff - The patch file provided in the zip, derby377modified.diff, did not contain the source file for tdevpreupgrade.html (presumably tdevpreupgrade.dita). If you could please attach that source file to this issue, i'll commit it. There is no information available in the manuals on how to upgrade a database from 10.0 to 10.1 version. Key: DERBY-377 URL: http://issues.apache.org/jira/browse/DERBY-377 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Suresh Thalamati Fix For: 10.1.1.0 Attachments: derby377modified.zip I could not find any info in the 10.1 Alpha manuals on how to upgrade a 10.0 database to use a 10.1 engine in full upgrade mode or software mode. I think this feature is implemented in the 10.1 code line , but not documented yet. -- 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] Created: (DERBY-427) An error message when running in Derby Network Server says cloudscape.LOG rather than derby.log
An error message when running in Derby Network Server says cloudscape.LOG rather than derby.log --- Key: DERBY-427 URL: http://issues.apache.org/jira/browse/DERBY-427 Project: Derby Type: Bug Components: Network Client Versions: 10.2.0.0 Reporter: Mamta A. Satoor Priority: Minor While trying to connect to Derby Network Server in XA environment using ij, I get an error message which talks about looking into cloudscape.LOG rather than derby.log Here are the steps to reproduce Start the Network Server in one window In another window, just have derbytools.jar and derbyclient.jar in the classpath and try to connect using ij as follows java -Dij.protocol=jdbc:derby://localhost:1527/ -Dij.user=db2admin -Dij.password=db2admin -Dij.exceptionTrace=true org.apache.derby.tools.ij xa_datasource 'c:/dellater/db1drda'; The ij window throws following exception IJ ERROR: org.apache.derby.impl.tools.ij.ijException: EmbeddedXADataSource not in classpath, please put derby.jar file in your classpath : EmbeddedXADataSource not in classpath, please put derby.jar file in your classpath (see cloudcape.LOG) The error message should say (see derby.log) rather than (see cloudscape.LOG) -- 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-377) There is no information available in the manuals on how to upgrade a database from 10.0 to 10.1 version.
[ http://issues.apache.org/jira/browse/DERBY-377?page=comments#action_12314853 ] Andrew McIntyre commented on DERBY-377: --- Jeff - The patch file provided in the zip, derby377modified.diff, did not contain the source file for tdevpreupgrade.html (presumably tdevpreupgrade.dita). If you could please attach that source file to this issue, i'll commit it. There is no information available in the manuals on how to upgrade a database from 10.0 to 10.1 version. Key: DERBY-377 URL: http://issues.apache.org/jira/browse/DERBY-377 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Suresh Thalamati Fix For: 10.1.1.0 Attachments: derby377modified.zip I could not find any info in the 10.1 Alpha manuals on how to upgrade a 10.0 database to use a 10.1 engine in full upgrade mode or software mode. I think this feature is implemented in the 10.1 code line , but not documented yet. -- 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-385) servlet Back to Main Page link points to csnet instead of derbynet
[ http://issues.apache.org/jira/browse/DERBY-385?page=all ] Myrna van Lunteren updated DERBY-385: - Attachment: servlet_385.diff this will probably make patch for derby-117 no longer work. servlet Back to Main Page link points to csnet instead of derbynet -- Key: DERBY-385 URL: http://issues.apache.org/jira/browse/DERBY-385 Project: Derby Type: Bug Versions: 10.1.1.0 Reporter: Myrna van Lunteren Assignee: Myrna van Lunteren Priority: Trivial Fix For: 10.2.0.0 Attachments: servlet_385.diff The link at the top of the servlet java/drda/org/apache/derby/drda/NetServlet.java links to csnet (because of the static String SERVLET_ADDRESS). However, the servlet address is now derbynet. -- 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-427) An error message when running in XA environment says cloudscape.LOG rather than derby.log
[ http://issues.apache.org/jira/browse/DERBY-427?page=all ] Mamta A. Satoor updated DERBY-427: -- Component: Unknown (was: Network Client) Summary: An error message when running in XA environment says cloudscape.LOG rather than derby.log (was: An error message when running in Derby Network Server says cloudscape.LOG rather than derby.log) Description: While trying to connect in ij under XA environment, I get an error message which talks about looking into cloudscape.LOG rather than derby.log Here are the steps to reproduce Just have derbytools.jar in the classpath and try to connect using ij as follows java -Dij.exceptionTrace=true org.apache.derby.tools.ij xa_datasource 'c:/dellater/db1drda'; The ij window throws following exception IJ ERROR: org.apache.derby.impl.tools.ij.ijException: EmbeddedXADataSource not in classpath, please put derby.jar file in your classpath : EmbeddedXADataSource not in classpath, please put derby.jar file in your classpath (see cloudcape.LOG) The error message should say (see derby.log) rather than (see cloudscape.LOG) was: While trying to connect to Derby Network Server in XA environment using ij, I get an error message which talks about looking into cloudscape.LOG rather than derby.log Here are the steps to reproduce Start the Network Server in one window In another window, just have derbytools.jar and derbyclient.jar in the classpath and try to connect using ij as follows java -Dij.protocol=jdbc:derby://localhost:1527/ -Dij.user=db2admin -Dij.password=db2admin -Dij.exceptionTrace=true org.apache.derby.tools.ij xa_datasource 'c:/dellater/db1drda'; The ij window throws following exception IJ ERROR: org.apache.derby.impl.tools.ij.ijException: EmbeddedXADataSource not in classpath, please put derby.jar file in your classpath : EmbeddedXADataSource not in classpath, please put derby.jar file in your classpath (see cloudcape.LOG) The error message should say (see derby.log) rather than (see cloudscape.LOG) This is not specific to Network Server. Reproduces in both embedded and network server configurations. An error message when running in XA environment says cloudscape.LOG rather than derby.log - Key: DERBY-427 URL: http://issues.apache.org/jira/browse/DERBY-427 Project: Derby Type: Bug Components: Unknown Versions: 10.2.0.0 Reporter: Mamta A. Satoor Priority: Minor While trying to connect in ij under XA environment, I get an error message which talks about looking into cloudscape.LOG rather than derby.log Here are the steps to reproduce Just have derbytools.jar in the classpath and try to connect using ij as follows java -Dij.exceptionTrace=true org.apache.derby.tools.ij xa_datasource 'c:/dellater/db1drda'; The ij window throws following exception IJ ERROR: org.apache.derby.impl.tools.ij.ijException: EmbeddedXADataSource not in classpath, please put derby.jar file in your classpath : EmbeddedXADataSource not in classpath, please put derby.jar file in your classpath (see cloudcape.LOG) The error message should say (see derby.log) rather than (see cloudscape.LOG) -- 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
