[jira] Commented: (DERBY-178) Provide line number information in distribution's class files
[ http://issues.apache.org/jira/browse/DERBY-178?page=comments#action_61421 ] Samuel Andrew McIntyre commented on DERBY-178: -- If you check out and build Derby yourself, the default mode of building is a debug build. See the sections about the 'sane' build property in BUILDING.txt here: http://svn.apache.org/viewcvs.cgi/incubator/derby/code/trunk/BUILDING.txt?rev=157009&view=markup With the consideration that products embedding Derby would desire a jar file with as small a footprint as possible, I created the distributions on the website with an insane/non-debug build, with all compiler optimizations turned on and assertions removed. However, perhaps posting a -debug distribution along with the -lib, -bin, and -src distributions should be considered. > Provide line number information in distribution's class files > - > > Key: DERBY-178 > URL: http://issues.apache.org/jira/browse/DERBY-178 > Project: Derby > Type: Improvement > Components: Build tools > Versions: 10.0.2.2 > Reporter: Jörg von Frantzius > Priority: Minor > > To make debugging easier using the derby distribution provided for download, > it would be nice to have line numbering information included in the classes. > With javac, that would be providing the option "-g" in the compiler's > commandline. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-182) BUILDING.txt 3.4.6 refers to a readme file for testing that does not exist
[ http://issues.apache.org/jira/browse/DERBY-182?page=history ]
Samuel Andrew McIntyre resolved DERBY-182:
--
Assign To: Samuel Andrew McIntyre
Resolution: Fixed
Fix Version: 10.0.2.2
10.1.0.0
Updated BUILDING.txt with revisions 159083, 159084.
> BUILDING.txt 3.4.6 refers to a readme file for testing that does not exist
> --
>
> Key: DERBY-182
> URL: http://issues.apache.org/jira/browse/DERBY-182
> Project: Derby
> Type: Bug
> Components: Documentation
> Versions: 10.0.2.2
> Environment: -- Java Information --
> Java Version:1.4.2_05
> Java Vendor: Sun Microsystems Inc.
> Java home: d:\j2sdk1.4.2_05\jre
> Java classpath: classes
> OS name: Windows XP
> OS architecture: x86
> OS version: 5.1
> Java user name: davidvc
> Java user home: C:\Documents and Settings\davidvc
> Java user dir: d:\derby\src\10.0
> - Derby Information
> [D:\derby\src\10.0\classes] 10.0.2.2 - (158519)
> --
> Reporter: David Van Couvering
> Assignee: Samuel Andrew McIntyre
> Fix For: 10.0.2.2, 10.1.0.0
>
> BUILDING.txt 3.4.6 says
> "(6) Derby also includes a suite of tests for more comprehensive verification.
> Information on how to run these tests can be found in the source tree,
> in the file
> ${derby.source}/java/testing/org/apache/derbyTesting/readme.htm"
> However, there is no such file in this location. The only instructions for
> testing I can find are on the web site where there are instructions on how to
> submit a patch.
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-182) BUILDING.txt 3.4.6 refers to a readme file for testing that does not exist
[
http://issues.apache.org/jira/browse/DERBY-182?page=comments#action_61575 ]
Samuel Andrew McIntyre commented on DERBY-182:
--
There is a readme for testing checked into subversion, but the path in
building.txt is in fact incorrect. The correct path is
${derby.source}/java/testing/readme.htm. I will update BUILDING.txt accordingly.
> BUILDING.txt 3.4.6 refers to a readme file for testing that does not exist
> --
>
> Key: DERBY-182
> URL: http://issues.apache.org/jira/browse/DERBY-182
> Project: Derby
> Type: Bug
> Components: Documentation
> Versions: 10.0.2.2
> Environment: -- Java Information --
> Java Version:1.4.2_05
> Java Vendor: Sun Microsystems Inc.
> Java home: d:\j2sdk1.4.2_05\jre
> Java classpath: classes
> OS name: Windows XP
> OS architecture: x86
> OS version: 5.1
> Java user name: davidvc
> Java user home: C:\Documents and Settings\davidvc
> Java user dir: d:\derby\src\10.0
> - Derby Information
> [D:\derby\src\10.0\classes] 10.0.2.2 - (158519)
> --
> Reporter: David Van Couvering
>
> BUILDING.txt 3.4.6 says
> "(6) Derby also includes a suite of tests for more comprehensive verification.
> Information on how to run these tests can be found in the source tree,
> in the file
> ${derby.source}/java/testing/org/apache/derbyTesting/readme.htm"
> However, there is no such file in this location. The only instructions for
> testing I can find are on the web site where there are instructions on how to
> submit a patch.
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-182) BUILDING.txt 3.4.6 refers to a readme file for testing that does not exist
[ http://issues.apache.org/jira/browse/DERBY-182?page=history ]
Samuel Andrew McIntyre closed DERBY-182:
> BUILDING.txt 3.4.6 refers to a readme file for testing that does not exist
> --
>
> Key: DERBY-182
> URL: http://issues.apache.org/jira/browse/DERBY-182
> Project: Derby
> Type: Bug
> Components: Documentation
> Versions: 10.0.2.2
> Environment: -- Java Information --
> Java Version:1.4.2_05
> Java Vendor: Sun Microsystems Inc.
> Java home: d:\j2sdk1.4.2_05\jre
> Java classpath: classes
> OS name: Windows XP
> OS architecture: x86
> OS version: 5.1
> Java user name: davidvc
> Java user home: C:\Documents and Settings\davidvc
> Java user dir: d:\derby\src\10.0
> - Derby Information
> [D:\derby\src\10.0\classes] 10.0.2.2 - (158519)
> --
> Reporter: David Van Couvering
> Assignee: Samuel Andrew McIntyre
> Fix For: 10.0.2.2, 10.1.0.0
>
> BUILDING.txt 3.4.6 says
> "(6) Derby also includes a suite of tests for more comprehensive verification.
> Information on how to run these tests can be found in the source tree,
> in the file
> ${derby.source}/java/testing/org/apache/derbyTesting/readme.htm"
> However, there is no such file in this location. The only instructions for
> testing I can find are on the web site where there are instructions on how to
> submit a patch.
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-187) Starting derby network server as a service in Win OS
[ http://issues.apache.org/jira/browse/DERBY-187?page=comments#action_61703 ] Samuel Andrew McIntyre commented on DERBY-187: -- Another, probably better solution than my previous suggestion would be one based around the Jakarta Commons Daemon project, which lives here: http://jakarta.apache.org/commons/daemon/ andrew > Starting derby network server as a service in Win OS > > > Key: DERBY-187 > URL: http://issues.apache.org/jira/browse/DERBY-187 > Project: Derby > Type: New Feature > Components: Services > Versions: 10.0.2.1 > Environment: OS will be only any flavour of Windows. > Reporter: Amit Handa > Priority: Minor > > The Derby Network Server Database could be started/stopped as a service in > Windows OS. > This may involve updating the win registry. Further work needs to be done to > understand what all will it require to do such a thing. > I am putting below Andrew McIntyre's comments if they can help in getting a > solution to this problem. > If you would like to see this functionality added, please add a JIRA entry > for it. The easiest way to do this would be to provide a registry key file > for Derby Network Server and provide instructions on how to install it as a > Windows service using instsrv and srvany. However, we obviously can't > redistribute those two utilities, but it would be nice to provide all the > parts to the solution. So, a little searching turned up this public domain > srvany replacement: > http://iain.cx/src/nssm/ > I haven't tried it, but I suggest trying it out to see how well it works. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-200) Fixes to dita source for upgrade to DITA toolkit 1.0.1
[ http://issues.apache.org/jira/browse/DERBY-200?page=comments#action_62411 ] Samuel Andrew McIntyre commented on DERBY-200: -- Committed attachments 1 and 2 with revision 160492. The website's dita.xml instructions should be updated to reflect that the DITA 1.0.1 toolkit should be used before this bug should be closed. > Fixes to dita source for upgrade to DITA toolkit 1.0.1 > -- > > Key: DERBY-200 > URL: http://issues.apache.org/jira/browse/DERBY-200 > Project: Derby > Type: Task > Components: Documentation > Environment: All > Reporter: Jeff Levitt > Attachments: dita-ot101.diff, linkchanges.diff > > The new DITA Toolkit release (Version 1.0.1) is much more powerful than the > first release. PDF generation is improved, and a navigation pane for the > PDF's is now generated. However, there were some errors in the DITA source > files that are only generated using the new toolkit. The errors included > links to a topic within itself. So for example, withing "Create Table," there > might be a link to "Create Table." There were more than 70 of these kinds of > links in all 6 books, so this patch will fix that in preparation for a > possible move to using the 1.0.1 version of the toolkit. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-153) Bad Eclipse plugin version specification
[ http://issues.apache.org/jira/browse/DERBY-153?page=history ] Samuel Andrew McIntyre resolved DERBY-153: -- Resolution: Fixed Fix Version: 10.0.2.2 10.1.0.0 Committed, revision 161100 (trunk) and 161102 (10.0) > Bad Eclipse plugin version specification > > > Key: DERBY-153 > URL: http://issues.apache.org/jira/browse/DERBY-153 > Project: Derby > Type: Bug > Versions: 10.1.0.0 > Environment: Eclipse 3.1 M5 (probably problematic also with earlier versions) > Reporter: Jörg von Frantzius > Fix For: 10.0.2.2, 10.1.0.0 > Attachments: eclipseplugin.diff > > In the plugin.xml of the Derby Eclipse plugin, the version specification > reads "10.1.0.0 (124830)", which Eclipse complains about as being illegal. In > consequence, the plugin is not loaded. > The Eclipse docs have the following to say about the version specification: > "Plug-in version format is major.minor.service.qualifier". > Stripping the "(1234830)", whatever that is anyway, solves the problem. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-153) Bad Eclipse plugin version specification
[ http://issues.apache.org/jira/browse/DERBY-153?page=history ] Samuel Andrew McIntyre reassigned DERBY-153: Assign To: Samuel Andrew McIntyre > Bad Eclipse plugin version specification > > > Key: DERBY-153 > URL: http://issues.apache.org/jira/browse/DERBY-153 > Project: Derby > Type: Bug > Versions: 10.1.0.0 > Environment: Eclipse 3.1 M5 (probably problematic also with earlier versions) > Reporter: Jörg von Frantzius > Assignee: Samuel Andrew McIntyre > Fix For: 10.0.2.2, 10.1.0.0 > Attachments: eclipseplugin.diff > > In the plugin.xml of the Derby Eclipse plugin, the version specification > reads "10.1.0.0 (124830)", which Eclipse complains about as being illegal. In > consequence, the plugin is not loaded. > The Eclipse docs have the following to say about the version specification: > "Plug-in version format is major.minor.service.qualifier". > Stripping the "(1234830)", whatever that is anyway, solves the problem. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Reopened: (DERBY-153) Bad Eclipse plugin version specification
[ http://issues.apache.org/jira/browse/DERBY-153?page=history ] Samuel Andrew McIntyre reopened DERBY-153: -- Meant to mark this as in-progress, not resolved. Will mark resolved once an updated Eclipse plugin is available from the Derby website. > Bad Eclipse plugin version specification > > > Key: DERBY-153 > URL: http://issues.apache.org/jira/browse/DERBY-153 > Project: Derby > Type: Bug > Versions: 10.1.0.0 > Environment: Eclipse 3.1 M5 (probably problematic also with earlier versions) > Reporter: Jörg von Frantzius > Assignee: Samuel Andrew McIntyre > Fix For: 10.0.2.2, 10.1.0.0 > Attachments: eclipseplugin.diff > > In the plugin.xml of the Derby Eclipse plugin, the version specification > reads "10.1.0.0 (124830)", which Eclipse complains about as being illegal. In > consequence, the plugin is not loaded. > The Eclipse docs have the following to say about the version specification: > "Plug-in version format is major.minor.service.qualifier". > Stripping the "(1234830)", whatever that is anyway, solves the problem. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-153) Bad Eclipse plugin version specification
[ http://issues.apache.org/jira/browse/DERBY-153?page=comments#action_62683 ] Samuel Andrew McIntyre commented on DERBY-153: -- Attached patch for this issue submitted by Rajesh Kartha. > Bad Eclipse plugin version specification > > > Key: DERBY-153 > URL: http://issues.apache.org/jira/browse/DERBY-153 > Project: Derby > Type: Bug > Versions: 10.1.0.0 > Environment: Eclipse 3.1 M5 (probably problematic also with earlier versions) > Reporter: Jörg von Frantzius > Attachments: eclipseplugin.diff > > In the plugin.xml of the Derby Eclipse plugin, the version specification > reads "10.1.0.0 (124830)", which Eclipse complains about as being illegal. In > consequence, the plugin is not loaded. > The Eclipse docs have the following to say about the version specification: > "Plug-in version format is major.minor.service.qualifier". > Stripping the "(1234830)", whatever that is anyway, solves the problem. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-220) Javadoc build should include a timestamp and/or the svn revision number in a visible location.
Javadoc build should include a timestamp and/or the svn revision number in a visible location. -- Key: DERBY-220 URL: http://issues.apache.org/jira/browse/DERBY-220 Project: Derby Type: Improvement Components: Build tools Versions: 10.1.0.0 Reporter: Samuel Andrew McIntyre Priority: Minor Fix For: 10.1.0.0 In order to easily identify when a specific set of javadoc was built, and from what source, it would be useful to include a timestamp and/or the svn revision number at the time the javadoc is built. The footer is an excellent location to place this information, as it is visible on every generated page. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-221) User documentation should include a timestamp and/or svn revision number
User documentation should include a timestamp and/or svn revision number Key: DERBY-221 URL: http://issues.apache.org/jira/browse/DERBY-221 Project: Derby Type: Improvement Components: Documentation Versions: 10.1.0.0 Reporter: Samuel Andrew McIntyre Priority: Minor Fix For: 10.1.0.0 In order to easily identify when a set of documentation was generated, it would be useful to add a timestamp, and possibly the svn revision at which the documentation was generated, to the output. One approach would be to replace a token in either the input files or final output with the appropriate information using Ant. This may not work for PDFs, in which case the timestamp may need to be inserted at the intermediate XSL-FO stage. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-228) need some OSGI related changes to MANIFEST.MF
[ http://issues.apache.org/jira/browse/DERBY-228?page=history ] Samuel Andrew McIntyre reassigned DERBY-228: Assign To: Samuel Andrew McIntyre > need some OSGI related changes to MANIFEST.MF > - > > Key: DERBY-228 > URL: http://issues.apache.org/jira/browse/DERBY-228 > Project: Derby > Type: Bug > Components: Build tools > Versions: 10.0.2.1 > Reporter: Myrna van Lunteren > Assignee: Samuel Andrew McIntyre > Priority: Minor > Fix For: 10.0.2.2 > > The MANIFEST.MF for derby.jar file has some support details for OSGI. > However, there are some issues with it: > - the Bundle-version number does not change with each build. > This would not be a problem if we'd never publish an intermediate build, > but as we do (snapshots), the Bundle-version number should change. > Having the same bundle-version over different builds can cause trouble > updating to the next (snapshot) and may cause confusion over what is > exactly in the bundle. > We could add the buildnumber into the Bundle-version number. > - Import-Package does not need java.sql > Derby does need java.sql to function, but as it's in the java namespace, > it will be loaded (if present) into every bundle that needs it even if > not specified in the import package entry. > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-223) Change programs under demo directory use consistent package names so IDEs do not report errors
[ http://issues.apache.org/jira/browse/DERBY-223?page=history ] Samuel Andrew McIntyre reassigned DERBY-223: Assign To: Samuel Andrew McIntyre > Change programs under demo directory use consistent package names so IDEs do > not report errors > -- > > Key: DERBY-223 > URL: http://issues.apache.org/jira/browse/DERBY-223 > Project: Derby > Type: Improvement > Reporter: John Sisson > Assignee: Samuel Andrew McIntyre > Priority: Trivial > > Currently if you build the demos under eclipse, it gives the following errors: > Severity Description ResourceIn Folder Location > Creation Time > 2 The declared package does not match the expected package nserverdemo > SimpleNetworkClientSample.java derby-trunk/java/demo/nserverdemo line > 1 April 14, 2005 9:32:35 AM > 2 The declared package does not match the expected package nserverdemo > SimpleNetworkServerSample.java derby-trunk/java/demo/nserverdemo line > 1 April 14, 2005 9:32:35 AM > 2 The declared package does not match the expected package simple > SimpleApp.java derby-trunk/java/demo/simpleline 1 April 14, 2005 > 9:32:35 AM > The following demo src files (and their associated documentation for running > them) should be changed so that they specify the package "nserverdemo" so > they are consistent with the other java source files in the same directory: > java/demo/nserverdemo/SimpleNetworkClientSample.java > java/demo/nserverdemo/SimpleNetworkServerSample.java > The following demo src files (and their associated documentation for running > them) should be changed so that they specify the package "simple" so they are > consistent with the other java source files in the nserverdemo directory: > java/demo/simple/SimpleApp.java -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-223) Change programs under demo directory use consistent package names so IDEs do not report errors
[ http://issues.apache.org/jira/browse/DERBY-223?page=history ] Samuel Andrew McIntyre reassigned DERBY-223: Assign To: (was: Samuel Andrew McIntyre) > Change programs under demo directory use consistent package names so IDEs do > not report errors > -- > > Key: DERBY-223 > URL: http://issues.apache.org/jira/browse/DERBY-223 > Project: Derby > Type: Improvement > Reporter: John Sisson > Priority: Trivial > > Currently if you build the demos under eclipse, it gives the following errors: > Severity Description ResourceIn Folder Location > Creation Time > 2 The declared package does not match the expected package nserverdemo > SimpleNetworkClientSample.java derby-trunk/java/demo/nserverdemo line > 1 April 14, 2005 9:32:35 AM > 2 The declared package does not match the expected package nserverdemo > SimpleNetworkServerSample.java derby-trunk/java/demo/nserverdemo line > 1 April 14, 2005 9:32:35 AM > 2 The declared package does not match the expected package simple > SimpleApp.java derby-trunk/java/demo/simpleline 1 April 14, 2005 > 9:32:35 AM > The following demo src files (and their associated documentation for running > them) should be changed so that they specify the package "nserverdemo" so > they are consistent with the other java source files in the same directory: > java/demo/nserverdemo/SimpleNetworkClientSample.java > java/demo/nserverdemo/SimpleNetworkServerSample.java > The following demo src files (and their associated documentation for running > them) should be changed so that they specify the package "simple" so they are > consistent with the other java source files in the nserverdemo directory: > java/demo/simple/SimpleApp.java -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-223) Change programs under demo directory use consistent package names so IDEs do not report errors
[ http://issues.apache.org/jira/browse/DERBY-223?page=comments#action_63338 ] Samuel Andrew McIntyre commented on DERBY-223: -- Thanks for spotting that, John. I will open a separate JIRA issue for the copyright statements and Cloudscape references in the demos, as it is a separate issue from the demo package names. > Change programs under demo directory use consistent package names so IDEs do > not report errors > -- > > Key: DERBY-223 > URL: http://issues.apache.org/jira/browse/DERBY-223 > Project: Derby > Type: Improvement > Reporter: John Sisson > Priority: Trivial > > Currently if you build the demos under eclipse, it gives the following errors: > Severity Description ResourceIn Folder Location > Creation Time > 2 The declared package does not match the expected package nserverdemo > SimpleNetworkClientSample.java derby-trunk/java/demo/nserverdemo line > 1 April 14, 2005 9:32:35 AM > 2 The declared package does not match the expected package nserverdemo > SimpleNetworkServerSample.java derby-trunk/java/demo/nserverdemo line > 1 April 14, 2005 9:32:35 AM > 2 The declared package does not match the expected package simple > SimpleApp.java derby-trunk/java/demo/simpleline 1 April 14, 2005 > 9:32:35 AM > The following demo src files (and their associated documentation for running > them) should be changed so that they specify the package "nserverdemo" so > they are consistent with the other java source files in the same directory: > java/demo/nserverdemo/SimpleNetworkClientSample.java > java/demo/nserverdemo/SimpleNetworkServerSample.java > The following demo src files (and their associated documentation for running > them) should be changed so that they specify the package "simple" so they are > consistent with the other java source files in the nserverdemo directory: > java/demo/simple/SimpleApp.java -- 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-233) Fix copyright notices and other IBM/Cloudscape references in java/demo/*
Fix copyright notices and other IBM/Cloudscape references in java/demo/* Key: DERBY-233 URL: http://issues.apache.org/jira/browse/DERBY-233 Project: Derby Type: Improvement Components: Documentation Versions: 10.0.2.2, 10.1.0.0 Reporter: Samuel Andrew McIntyre Priority: Minor Assigning this issue to "Documentation" component, as there is not a Demos component. -- 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-233) Fix copyright notices and other IBM/Cloudscape references in java/demo/*
[ http://issues.apache.org/jira/browse/DERBY-233?page=all ] Samuel Andrew McIntyre reassigned DERBY-233: Assign To: Samuel Andrew McIntyre > Fix copyright notices and other IBM/Cloudscape references in java/demo/* > > > Key: DERBY-233 > URL: http://issues.apache.org/jira/browse/DERBY-233 > Project: Derby > Type: Improvement > Components: Documentation > Versions: 10.0.2.2, 10.1.0.0 > Reporter: Samuel Andrew McIntyre > Assignee: Samuel Andrew McIntyre > Priority: Minor > > Assigning this issue to "Documentation" component, as there is not a Demos > component. -- 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-233) Fix copyright notices and other IBM/Cloudscape references in java/demo/*
[ http://issues.apache.org/jira/browse/DERBY-233?page=all ] Samuel Andrew McIntyre updated DERBY-233: - Component: Demos/Scripts (was: Documentation) > Fix copyright notices and other IBM/Cloudscape references in java/demo/* > > > Key: DERBY-233 > URL: http://issues.apache.org/jira/browse/DERBY-233 > Project: Derby > Type: Improvement > Components: Demos/Scripts > Versions: 10.0.2.2, 10.1.0.0 > Reporter: Samuel Andrew McIntyre > Assignee: Samuel Andrew McIntyre > Priority: Minor > > Assigning this issue to "Documentation" component, as there is not a Demos > component. -- 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-228) need some OSGI related changes to MANIFEST.MF
[ http://issues.apache.org/jira/browse/DERBY-228?page=comments#action_63692 ] Samuel Andrew McIntyre commented on DERBY-228: -- Fix checked into trunk with revision 164627 and 10.0 with 164628. > need some OSGI related changes to MANIFEST.MF > - > > Key: DERBY-228 > URL: http://issues.apache.org/jira/browse/DERBY-228 > Project: Derby > Type: Bug > Components: Build tools > Versions: 10.0.2.1 > Reporter: Myrna van Lunteren > Assignee: Samuel Andrew McIntyre > Priority: Minor > Fix For: 10.0.2.2 > > The MANIFEST.MF for derby.jar file has some support details for OSGI. > However, there are some issues with it: > - the Bundle-version number does not change with each build. > This would not be a problem if we'd never publish an intermediate build, > but as we do (snapshots), the Bundle-version number should change. > Having the same bundle-version over different builds can cause trouble > updating to the next (snapshot) and may cause confusion over what is > exactly in the bundle. > We could add the buildnumber into the Bundle-version number. > - Import-Package does not need java.sql > Derby does need java.sql to function, but as it's in the java namespace, > it will be loaded (if present) into every bundle that needs it even if > not specified in the import package entry. > -- 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-233) Fix copyright notices and other IBM/Cloudscape references in java/demo/*
[ http://issues.apache.org/jira/browse/DERBY-233?page=comments#action_63693 ] Samuel Andrew McIntyre commented on DERBY-233: -- Fix checked into trunk with revision 164629 and 10.0 with revision 164630. > Fix copyright notices and other IBM/Cloudscape references in java/demo/* > > > Key: DERBY-233 > URL: http://issues.apache.org/jira/browse/DERBY-233 > Project: Derby > Type: Improvement > Components: Demos/Scripts > Versions: 10.0.2.2, 10.1.0.0 > Reporter: Samuel Andrew McIntyre > Assignee: Samuel Andrew McIntyre > Priority: Minor > > Assigning this issue to "Documentation" component, as there is not a Demos > component. -- 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-240) loading special locale fails with jdk131 and jars
[ http://issues.apache.org/jira/browse/DERBY-240?page=comments#action_63855 ] Samuel Andrew McIntyre commented on DERBY-240: -- Test excluded from running in jdk131 with revision 164903. > loading special locale fails with jdk131 and jars > - > > Key: DERBY-240 > URL: http://issues.apache.org/jira/browse/DERBY-240 > Project: Derby > Type: Bug > Components: Localization > Versions: 10.1.0.0 > Environment: IBM and Sun jdk131 and jars > Reporter: Myrna van Lunteren > Priority: Trivial > > With the jdk131 & ibm131 & running with jars, a special test locale > qq_PP_testOnly with which the database gets created does not appear to get > loaded, instead, the default locale set using java.util.Locale.setDefault() > is used. > When using classes in a directory, this does not happen. Running with jdk141 > or jdk15(i.e. 5.0), either jars or classes, the locale also gets loaded > correctly. > This looks like a jvm bug, however, as it's working correctly with later > versions of the jvms, a fix is unlikely. > Affected test: i18n/messageLocale.sql -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-55) Derby documentation mentions script and batch files that don't exist
[ http://issues.apache.org/jira/browse/DERBY-55?page=all ] Samuel Andrew McIntyre closed DERBY-55: --- Resolution: Fixed Fix Version: 10.0.2.2 10.1.0.0 (was: 10.0.2.1) Demos and scripts added to snapshot posted 4/28/2005. > Derby documentation mentions script and batch files that don't exist > > > Key: DERBY-55 > URL: http://issues.apache.org/jira/browse/DERBY-55 > Project: Derby > Type: Bug > Components: Documentation > Reporter: John Sisson > Assignee: Samuel Andrew McIntyre > Fix For: 10.0.2.2, 10.1.0.0 > Attachments: derby.diff.gz > > The Derby documentation > http://incubator.apache.org/derby/manuals/admin/hubprnt22.html says: > Derby provides script files for setting the class path, located in > $DERBY_INSTALL\frameworks\NetworkServer\bin. > setNetworkClientCP.bat (Windows) > setNetworkClientCP.ksh (UNIX) > setNetworkServerCP.bat (Windows) > setNetworkServerCP.ksh (UNIX) > These files do not exist in Derby. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-153) Bad Eclipse plugin version specification
[ http://issues.apache.org/jira/browse/DERBY-153?page=all ] Samuel Andrew McIntyre closed DERBY-153: Resolution: Fixed Eclipse plugin fixed with snapshot version posted on 4/28/2005 > Bad Eclipse plugin version specification > > > Key: DERBY-153 > URL: http://issues.apache.org/jira/browse/DERBY-153 > Project: Derby > Type: Bug > Versions: 10.1.0.0 > Environment: Eclipse 3.1 M5 (probably problematic also with earlier versions) > Reporter: Jörg von Frantzius > Assignee: Samuel Andrew McIntyre > Fix For: 10.0.2.2, 10.1.0.0 > Attachments: eclipseplugin.diff > > In the plugin.xml of the Derby Eclipse plugin, the version specification > reads "10.1.0.0 (124830)", which Eclipse complains about as being illegal. In > consequence, the plugin is not loaded. > The Eclipse docs have the following to say about the version specification: > "Plug-in version format is major.minor.service.qualifier". > Stripping the "(1234830)", whatever that is anyway, solves the problem. -- 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-247) Network Server demo program should support Derby network client driver
Network Server demo program should support Derby network client driver -- Key: DERBY-247 URL: http://issues.apache.org/jira/browse/DERBY-247 Project: Derby Type: Improvement Components: Demos/Scripts Versions: 10.1.0.0 Reporter: Samuel Andrew McIntyre Priority: Minor Currently, the Network Server demo programs require the IBM Universal JDBC Driver (JCC) for client functionality. The demo should be enhanced to also support using the Derby client driver. -- 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-248) Network Server frameworks scripts should support Derby network client driver
Network Server frameworks scripts should support Derby network client driver Key: DERBY-248 URL: http://issues.apache.org/jira/browse/DERBY-248 Project: Derby Type: Improvement Components: Demos/Scripts Versions: 10.1.0.0 Reporter: Samuel Andrew McIntyre Currently the Network Server framework scripts expect the client driver to be the IBM Universal JDBC Driver (JCC). The Network Server framework scripts should be enhanced to support the Derby network client driver. -- 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-249) Builds fail during splitmessages step if path contains spaces
Builds fail during splitmessages step if path contains spaces - Key: DERBY-249 URL: http://issues.apache.org/jira/browse/DERBY-249 Project: Derby Type: Bug Components: Build tools Versions: 10.0.2.2, 10.1.0.0 Reporter: Samuel Andrew McIntyre Priority: Trivial If the path to the Derby source files contains a space, for example /opt/My Local Drive/derbysource, then the build will fail at the splitmessages step with the following error: [java] Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String index out of range: -1 [java] at java.lang.String.substring(String.java:1444) [java] at org.apache.derbyBuild.splitmessages.main(splitmessages.java:44) splitmessages should be improved to handle spaces in the path to the message files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-233) Fix copyright notices and other IBM/Cloudscape references in java/demo/*
[ http://issues.apache.org/jira/browse/DERBY-233?page=all ] Samuel Andrew McIntyre closed DERBY-233: Resolution: Fixed Fix Version: 10.0.2.2 10.1.0.0 Fix included in snapshot posted 4/28/2005 > Fix copyright notices and other IBM/Cloudscape references in java/demo/* > > > Key: DERBY-233 > URL: http://issues.apache.org/jira/browse/DERBY-233 > Project: Derby > Type: Improvement > Components: Demos/Scripts > Versions: 10.0.2.2, 10.1.0.0 > Reporter: Samuel Andrew McIntyre > Assignee: Samuel Andrew McIntyre > Priority: Minor > Fix For: 10.0.2.2, 10.1.0.0 > > Assigning this issue to "Documentation" component, as there is not a Demos > component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-56) NsSample sample program refered to in documentation is missing
[ http://issues.apache.org/jira/browse/DERBY-56?page=all ] Samuel Andrew McIntyre closed DERBY-56: --- Resolution: Fixed Fix Version: 10.0.2.2 10.1.0.0 (was: 10.0.2.1) Demos and scripts added to snapshot posted 4/28/2005 > NsSample sample program refered to in documentation is missing > -- > > Key: DERBY-56 > URL: http://issues.apache.org/jira/browse/DERBY-56 > Project: Derby > Type: Bug > Components: Documentation > Reporter: John Sisson > Assignee: Samuel Andrew McIntyre > Fix For: 10.0.2.2, 10.1.0.0 > > See the following pages for references to the NsSample program. > http://incubator.apache.org/derby/manuals/admin/hubprnt34.html > http://incubator.apache.org/derby/manuals/admin/hubprnt35.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-228) need some OSGI related changes to MANIFEST.MF
[ http://issues.apache.org/jira/browse/DERBY-228?page=all ] Samuel Andrew McIntyre closed DERBY-228: Resolution: Fixed Fix Version: 10.1.0.0 Fix included in snapshot posted 4/28/2005 > need some OSGI related changes to MANIFEST.MF > - > > Key: DERBY-228 > URL: http://issues.apache.org/jira/browse/DERBY-228 > Project: Derby > Type: Bug > Components: Build tools > Versions: 10.0.2.1 > Reporter: Myrna van Lunteren > Assignee: Samuel Andrew McIntyre > Priority: Minor > Fix For: 10.1.0.0, 10.0.2.2 > > The MANIFEST.MF for derby.jar file has some support details for OSGI. > However, there are some issues with it: > - the Bundle-version number does not change with each build. > This would not be a problem if we'd never publish an intermediate build, > but as we do (snapshots), the Bundle-version number should change. > Having the same bundle-version over different builds can cause trouble > updating to the next (snapshot) and may cause confusion over what is > exactly in the bundle. > We could add the buildnumber into the Bundle-version number. > - Import-Package does not need java.sql > Derby does need java.sql to function, but as it's in the java namespace, > it will be loaded (if present) into every bundle that needs it even if > not specified in the import package entry. > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-245) Missing class org/apache/derby/client/am/LossOfPrecisionConversionException
[ http://issues.apache.org/jira/browse/DERBY-245?page=all ] Samuel Andrew McIntyre closed DERBY-245: Resolution: Invalid Closing issue for Dibyendu Majumdar > Missing class org/apache/derby/client/am/LossOfPrecisionConversionException > --- > > Key: DERBY-245 > URL: http://issues.apache.org/jira/browse/DERBY-245 > Project: Derby > Type: Bug > Components: Network Client > Reporter: Dibyendu Majumdar > > When getXAConnection() is executed on ClientXADataSource, the following > exception is thrown: > java.lang.NoClassDefFoundError: > org/apache/derby/client/am/LossOfPrecisionConversionException > at org.apache.derby.client.am.Agent.(Agent.java:63) > at org.apache.derby.client.net.NetAgent.(NetAgent.java:103) > at > org.apache.derby.client.net.NetConnection.newAgent_(NetConnection.java:949) > at > org.apache.derby.client.am.Connection.initConnection(Connection.java:170) > at org.apache.derby.client.am.Connection.(Connection.java:146) > at > org.apache.derby.client.net.NetConnection.(NetConnection.java:203) > at > org.apache.derby.client.net.NetXAConnection.(NetXAConnection.java:38) > at > org.apache.derby.client.ClientPooledConnection.(ClientPooledConnection.java:84) > at > org.apache.derby.client.ClientXAConnection.(ClientXAConnection.java:47) > at > org.apache.derby.jdbc.ClientXADataSource.getXAConnection(ClientXADataSource.java:57) > at > org.apache.derby.jdbc.ClientXADataSource.getXAConnection(ClientXADataSource.java:49) -- 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-1) Can't create a new db on OS X
[ http://issues.apache.org/jira/browse/DERBY-1?page=comments#action_65028 ] Samuel Andrew McIntyre commented on DERBY-1: The underlying JVM issue has been fixed in Mac OS X 10.4 (Tiger), but remains a problem on Mac OS X 10.3. > Can't create a new db on OS X > - > > Key: DERBY-1 > URL: http://issues.apache.org/jira/browse/DERBY-1 > Project: Derby > Type: Bug > Versions: 10.0.2.0 > Environment: OS X 10.3.5, Java 1.4.2_05, Dual G5 > Reporter: Tom Santos > > This problem does not occur when I use the same jars on Linux. > I am unable to create a new database in ij by using the following command: > connect 'jdbc:derby:testdb;create=true'; > I get the following output: > ERROR XJ041: Failed to create database 'testdb', see the next exception for > details. > ERROR XBM01: Startup failed due to an exception, see next exception for > details. > ERROR XJ001: Java exception: > '/Users/tom/dev/java/derby-bin/lib/testdb/log/log1.dat (File exists): > java.io.FileNotFoundException'. > All users have write permissions to the directory so it's not getting blocked > there. I'm not sure what's going on. I've included the contents of > derby.log below. I've also included the result of running sysinfo on my > machine below that. > > 2004-09-24 20:33:53.762 GMT: > Booting Derby version IBM Corp. - Apache Derby - 10.0.2.0 - (30301): > instance c013800d-00ff-3226-5601-0015bd70 > on database directory /Users/tom/dev/java/derby-bin/lib/testdb > 2004-09-24 20:33:53.821 GMT: > Shutting down instance c013800d-00ff-3226-5601-0015bd70 > > 2004-09-24 20:33:53.837 GMT Thread[main,5,main] Cleanup action starting > ERROR XBM01: Startup failed due to an exception, see next exception for > details. > at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java) > at > org.apache.derby.iapi.services.monitor.Monitor.exceptionStartingModule(Monitor.java) > at org.apache.derby.impl.store.raw.log.LogToFile.boot(LogToFile.java) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java) > at > org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java) > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.bootLogFactory(BaseDataFileFactory.java) > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.setRawStoreFactory(BaseDataFileFactory.java) > at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java) > at > org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java) > at > org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java) > at > org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java) > at > org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java) > at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java) > at > org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java) > at > org.apache.derby.impl.services.monitor.BaseMonitor.createPersistentService(BaseMonitor.java) > at > org.apache.derby.iapi.services.monitor.Monitor.createPersistentService(Monitor.java) > at > org.apache.derby.impl.jdbc.EmbedConnection.createDatabase(EmbedConnection.java) > at > org.apache.derby.impl.jdbc.EmbedConnection.(EmbedConnection.java) > at > org.apache.derby.impl.jdbc.EmbedConnection20.(EmbedConnection20.java) > at > org.apache.derby.impl.jdbc.EmbedConnection30.(EmbedConnection30.java) > at org.apache.derby.jdbc.Driver30.getNewEmbedConnection(Driver30.java) > at org.apache.derby.jdbc.Driver169.connect(Driver169.java) > at java.sql.DriverManager.getConnection(DriverManager.
[jira] Closed: (DERBY-279) Tagging in DITA docs causes Derby builds to fail.
[ http://issues.apache.org/jira/browse/DERBY-279?page=all ] Samuel Andrew McIntyre closed DERBY-279: Resolution: Fixed Fix Version: 10.1.0.0 Committed, revision 170061 > Tagging in DITA docs causes Derby builds to fail. > - > > Key: DERBY-279 > URL: http://issues.apache.org/jira/browse/DERBY-279 > Project: Derby > Type: Bug > Components: Documentation > Environment: all > Reporter: Jeff Levitt > Assignee: Jeff Levitt > Priority: Minor > Fix For: 10.1.0.0 > Attachments: pubtags.diff > > There seems to be a tag in the DITA docs at the end of most of the files (I > found it in almost 500 of them). I think the tag was generated by the tool I > had used to create the DITA files originally during the migration to DITA. > In any case, the tag is formatted like this: , where the > x's are a string of numbers. I know these tags are unnecessary for our docs, > but until now I didn't think they affected anything. However, in researching > why the doc builds sometimes fail for different users and different > platforms, it occured to me that it could be because of this tag. The build > failure usually logs that files need to "start and end with the same entity." > Well, if this pub tag is at the end of a file, then it could be causing the > problem. Indeed, I just had a build failure, then removed the pub tag, and > the build succeeded. So I would like to remove these arbitrary tags from all > of the doc files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-282) Fix to Net Client DITA files
[ http://issues.apache.org/jira/browse/DERBY-282?page=all ] Samuel Andrew McIntyre closed DERBY-282: Resolution: Fixed Committed, revision 170064. > Fix to Net Client DITA files > > > Key: DERBY-282 > URL: http://issues.apache.org/jira/browse/DERBY-282 > Project: Derby > Type: Bug > Components: Documentation > Environment: Linux > Reporter: Jeff Levitt > Assignee: Jeff Levitt > Attachments: dtdfix.diff > > Two of the new DITA files that I created for the Network Client documentation > (cadminappsclientsecurity.dita and cadminappsclienttracing.dita), reference > the DTD in the following format: > "..\dtd\reference.dtd"> > This is wrong, because the slashes should be reversed to: > "../dtd/reference.dtd"> > This causes build breaks on Linux platform. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-146) start derby network class in redhat 9
[ http://issues.apache.org/jira/browse/DERBY-146?page=all ] Samuel Andrew McIntyre closed DERBY-146: Resolution: Incomplete > start derby network class in redhat 9 > -- > > Key: DERBY-146 > URL: http://issues.apache.org/jira/browse/DERBY-146 > Project: Derby > Type: Bug > Components: Network Server > Versions: 10.0.2.2 > Reporter: mohame abd elsamei > Priority: Critical > > Dear all , > i am sorry for posting these error's i have got , i know it might be basics > for derby and java , but i need help in that :) > when i tried to run : > java java org.apache.derby.drda.NetworkServerControl start > from the derby.source/clasess > i get the error > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/derby/drda/NetworkServerControl > also do i need to update my kernel ? -- 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-220) Javadoc build should include a timestamp and/or the svn revision number in a visible location.
[
http://issues.apache.org/jira/browse/DERBY-220?page=comments#action_65687 ]
Samuel Andrew McIntyre commented on DERBY-220:
--
For the svn revision, it should be the svn revision of the view from which the
javadoc was built. This represents most closely the state of the javadoc at the
time it is built. The svn revision can be retrieved using the svnversion
command. See the jar build for an example of how the changenumber property is
set. In fact, you could probably just reuse the initjars target to set the
changenumber.
For the timestamp, I suggest using Ant's internal timestamp properties. the
task is called to set these properties in the init target. It's just a
matter of using them.
So, all that might need to be done is to call the right init targets before the
build, and add ${tstamp} and ${changenumber} to the footer text.
As for using the Subversion keywords in the java source files, I suppose it's
probably most useful for determining who last changed the particular file, but
I think for purposes of dating the build, putting the timestamp and revision in
the footer achieves the same thing much less intrusively.
> Javadoc build should include a timestamp and/or the svn revision number in a
> visible location.
> --
>
> Key: DERBY-220
> URL: http://issues.apache.org/jira/browse/DERBY-220
> Project: Derby
> Type: Improvement
> Components: Build tools
> Versions: 10.1.0.0
> Reporter: Samuel Andrew McIntyre
> Priority: Minor
> Fix For: 10.1.0.0
>
> In order to easily identify when a specific set of javadoc was built, and
> from what source, it would be useful to include a timestamp and/or the svn
> revision number at the time the javadoc is built. The footer is an excellent
> location to place this information, as it is visible on every generated page.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-249) Builds fail during splitmessages step if path contains spaces
[ http://issues.apache.org/jira/browse/DERBY-249?page=all ] Samuel Andrew McIntyre closed DERBY-249: Resolution: Fixed Fix Version: 10.0.2.2 10.1.0.0 revisions 170793 (10.1) and 170782 (10.0) > Builds fail during splitmessages step if path contains spaces > - > > Key: DERBY-249 > URL: http://issues.apache.org/jira/browse/DERBY-249 > Project: Derby > Type: Bug > Components: Build tools > Versions: 10.0.2.2, 10.1.0.0 > Reporter: Samuel Andrew McIntyre > Assignee: Dyre Tjeldvoll > Priority: Trivial > Fix For: 10.0.2.2, 10.1.0.0 > Attachments: derby-249.diff, derby-249.status, derbyall_report.txt > > If the path to the Derby source files contains a space, for example /opt/My > Local Drive/derbysource, then the build will fail at the splitmessages step > with the following error: > [java] Exception in thread "main" > java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > [java] at java.lang.String.substring(String.java:1444) > [java] at > org.apache.derbyBuild.splitmessages.main(splitmessages.java:44) > splitmessages should be improved to handle spaces in the path to the message > files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-248) Network Server frameworks scripts should support Derby network client driver
[ http://issues.apache.org/jira/browse/DERBY-248?page=all ] Samuel Andrew McIntyre closed DERBY-248: Resolution: Fixed Fix Version: 10.1.0.0 patch committed in revision 170821 > Network Server frameworks scripts should support Derby network client driver > > > Key: DERBY-248 > URL: http://issues.apache.org/jira/browse/DERBY-248 > Project: Derby > Type: Improvement > Components: Demos/Scripts > Versions: 10.1.0.0 > Reporter: Samuel Andrew McIntyre > Assignee: Lance Andersen > Fix For: 10.1.0.0 > > Currently the Network Server framework scripts expect the client driver to be > the IBM Universal JDBC Driver (JCC). The Network Server framework scripts > should be enhanced to support the Derby network client driver. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-196) Link for Jikes 1.14 in BUILDING.txt needs to be changed to http://jikes.sourceforge.net/
[ http://issues.apache.org/jira/browse/DERBY-196?page=all ] Samuel Andrew McIntyre closed DERBY-196: Resolution: Fixed Fix Version: 10.0.2.2 10.1.0.0 revisions 170837 (10.1) and 170838 (10.0) > Link for Jikes 1.14 in BUILDING.txt needs to be changed to > http://jikes.sourceforge.net/ > > > Key: DERBY-196 > URL: http://issues.apache.org/jira/browse/DERBY-196 > Project: Derby > Type: Improvement > Components: Documentation > Reporter: John Sisson > Priority: Trivial > Fix For: 10.0.2.2, 10.1.0.0 > Attachments: patch.txt > > The Jikes project is now hosted at SourceForge. The link for Jikes 1.14 in > BUILDING.txt needs to be changed to http://jikes.sourceforge.net/ -- 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-303) derbynet/testconnection.java fails
[ http://issues.apache.org/jira/browse/DERBY-303?page=all ] Samuel Andrew McIntyre resolved DERBY-303: -- Resolution: Fixed Resolved issue on my Linux box, committed patch with revision 171164. Will close issue after waiting for Ole's results. > derbynet/testconnection.java fails > -- > > Key: DERBY-303 > URL: http://issues.apache.org/jira/browse/DERBY-303 > Project: Derby > Type: Bug > Components: Test > Versions: 10.1.0.0 > Environment: Seem to occur on several platforms > Reporter: Øystein Grøvlen > Assignee: David Van Couvering > Attachments: DERBY-303.diff > > When I run the testsuite, derbynet/testconnection.java fails. > testconnection.tmp contains the following: > Testing testconnection > org.apache.derby.drda.NetworkServerControl ping > Could not connect to Derby Network Server on host localhost, port 1527. > java.lang.IllegalThreadStateException: process hasn't exited > at java.lang.UNIXProcess.exitValue(UNIXProcess.java:116) > at > org.apache.derbyTesting.functionTests.tests.derbynet.testconnection.execCmdDumpResults(Unknown > Source) > at > org.apache.derbyTesting.functionTests.tests.derbynet.testconnection.execCmdDumpResults(Unknown > Source) > at > org.apache.derbyTesting.functionTests.tests.derbynet.testconnection.main(Unknown > Source) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-303) derbynet/testconnection.java fails
[ http://issues.apache.org/jira/browse/DERBY-303?page=all ] Samuel Andrew McIntyre closed DERBY-303: Confirmed as fixed by Øystein. > derbynet/testconnection.java fails > -- > > Key: DERBY-303 > URL: http://issues.apache.org/jira/browse/DERBY-303 > Project: Derby > Type: Bug > Components: Test > Versions: 10.1.0.0 > Environment: Seem to occur on several platforms > Reporter: Øystein Grøvlen > Assignee: David Van Couvering > Attachments: DERBY-303.diff > > When I run the testsuite, derbynet/testconnection.java fails. > testconnection.tmp contains the following: > Testing testconnection > org.apache.derby.drda.NetworkServerControl ping > Could not connect to Derby Network Server on host localhost, port 1527. > java.lang.IllegalThreadStateException: process hasn't exited > at java.lang.UNIXProcess.exitValue(UNIXProcess.java:116) > at > org.apache.derbyTesting.functionTests.tests.derbynet.testconnection.execCmdDumpResults(Unknown > Source) > at > org.apache.derbyTesting.functionTests.tests.derbynet.testconnection.execCmdDumpResults(Unknown > Source) > at > org.apache.derbyTesting.functionTests.tests.derbynet.testconnection.main(Unknown > Source) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-266) test tools/dblook_test.java fails if run in a directory having "*derby/*" in its path
[ http://issues.apache.org/jira/browse/DERBY-266?page=all ]
Samuel Andrew McIntyre closed DERBY-266:
Resolution: Fixed
Fix Version: 10.0.2.2
Committed, revision 177986 (10.1), and 177989 (10.0).
> test tools/dblook_test.java fails if run in a directory having "*derby/*" in
> its path
> -
>
> Key: DERBY-266
> URL: http://issues.apache.org/jira/browse/DERBY-266
> Project: Derby
> Type: Bug
> Components: Test
> Versions: 10.1.0.0
> Reporter: Dag H. Wanvik
> Assignee: Myrna van Lunteren
> Priority: Minor
> Fix For: 10.1.0.0, 10.0.2.2
> Attachments: derby266.diff
>
> SYMPTOM: The test "tools/dblook_test" will fail. The diff looks similar to
> this:
> *** Start: dblook_test jdk1.4.2_02 derbyall:derbytools 2005-05-06 22:37:37 ***
> 4861d4860
> < java.io.FileNotFoundException:
> Test Failed.
> *** End: dblook_test jdk1.4.2_02 derbyall:derbytools 2005-05-06 22:37:53 ***
> cf mail thread:
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200505.mbox/[EMAIL
> PROTECTED]
> ANALYSIS: The problem lies with the sed
> functionality in the test harness, which delete certain lines before
> comparing with the master file.
> Sed.java in the harness removes lines containing *derby/* in the path,
> viz:
> deleteLines.addElement("^.*derby/.*\\<.*\\>\\(.*\\).*$");
> deleteLines.addElement("^.*derby/.*\\(.*\\).*$");
> so if your tests are running in a directory containing this pattern, a
> line too much is deleted from dblook_test.tmp, thereby giving a
> comparison failure like you describe.
> I don't know the reason for this deletion yet, so I can't say how to
> fix it, but the work-around is obvious: Run test in a directory whose
> name does not contain this pattern ;-)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-197) Add tip for Windows users in BUILDING.txt file regarding file paths in the ant.properties file
[ http://issues.apache.org/jira/browse/DERBY-197?page=all ] Samuel Andrew McIntyre closed DERBY-197: Resolution: Fixed Fix Version: 10.0.2.2 10.1.0.0 Revision 178554 (10.1) and 178555 (10.0) > Add tip for Windows users in BUILDING.txt file regarding file paths in the > ant.properties file > -- > > Key: DERBY-197 > URL: http://issues.apache.org/jira/browse/DERBY-197 > Project: Derby > Type: Improvement > Components: Documentation > Reporter: John Sisson > Assignee: David Van Couvering > Priority: Trivial > Fix For: 10.0.2.2, 10.1.0.0 > Attachments: DERBY-197-2.diff, DERBY-197.diff > > In the section 3.2, step 2, where the user is instructed to add the j14lib > and j13lib properties to the ant.properties file, it would be worth reminding > the user that on windows, the file seperators need to be escaped. This is > something most windows users will know, but it can be easily forgotten, > especially when in other parts of the instructions you don't need to escape > paths (e.g. when setting the path). > For example, the following works: > j14lib=C:\\j2sdk1.4.2_06\\jre\\lib > j13lib=C:\\jdk1.3.1_14\\jre\\lib > The following doesn't: > j14lib=C:\j2sdk1.4.2_06\jre\lib > j13lib=C:\jdk1.3.1_14\jre\lib > and causes the following errors: > compile_reference: > [javac] Compiling 9 source files to > D:\OpenSourceJava\derby_trunk\trunk\classes > [javac] Found 2 system errors: > [javac] *** Error: Could not find package "java/util" in: > [javac] > D:\OpenSourceJava\derby_trunk\trunk\tools\java\tools\java\empty.jar > [javac] C:\j2sdk1.4.2_06\jre\lib\ext\dnsns.jar > [javac] C:\j2sdk1.4.2_06\jre\lib\ext\ldapsec.jar > [javac] C:\j2sdk1.4.2_06\jre\lib\ext\localedata.jar > [javac] C:\j2sdk1.4.2_06\jre\lib\ext\sunjce_provider.jar > [javac] D:\OpenSourceJava\derby_trunk\trunk\classes > [javac] > D:\OpenSourceJava\derby_trunk\trunk\tools\java\jdbc2_0-stdext.jar > [javac] D:\OpenSourceJava\derby_trunk\trunk\java\engine > [javac] . > [javac] *** Error: Could not find package "java/lang" in: > [javac] > D:\OpenSourceJava\derby_trunk\trunk\tools\java\tools\java\empty.jar > [javac] C:\j2sdk1.4.2_06\jre\lib\ext\dnsns.jar > [javac] C:\j2sdk1.4.2_06\jre\lib\ext\ldapsec.jar > [javac] C:\j2sdk1.4.2_06\jre\lib\ext\localedata.jar > [javac] C:\j2sdk1.4.2_06\jre\lib\ext\sunjce_provider.jar > [javac] D:\OpenSourceJava\derby_trunk\trunk\classes > [javac] > D:\OpenSourceJava\derby_trunk\trunk\tools\java\jdbc2_0-stdext.jar > [javac] D:\OpenSourceJava\derby_trunk\trunk\java\engine > [javac] . > BUILD FAILED > D:\OpenSourceJava\derby_trunk\trunk\build.xml:256: Following error occured > while executing this line > D:\OpenSourceJava\derby_trunk\trunk\java\engine\build.xml:57: Following error > occured while executing this line > D:\OpenSourceJava\derby_trunk\trunk\java\engine\org\apache\derby\iapi\reference\build.xml:32: > Compile failed; see the compiler error > output for details. > Total time: 3 seconds -- 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-180) XCL47 SQLState duplicated in messages_en.properties?
[ http://issues.apache.org/jira/browse/DERBY-180?page=all ]
Samuel Andrew McIntyre reassigned DERBY-180:
Assign To: Samuel Andrew McIntyre
> XCL47 SQLState duplicated in messages_en.properties?
>
>
> Key: DERBY-180
> URL: http://issues.apache.org/jira/browse/DERBY-180
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.0.2.0
> Environment: Windows XP SP1 Professional
> Reporter: George Baklarz
> Assignee: Samuel Andrew McIntyre
> Priority: Minor
>
> In the messages_en.properties file, there are two items that are similar:
> XCL47.S=Use of ''{0}'' requires database to be upgraded from version {1} to
> version {2} or later.
> XCL478.S=The requested function can not reference tables in SESSION schema.
> SQLSTATEs are supposed to be 5 characters long. When I issue a CREATE VIEW on
> a SESSION table, I receive the proper error message:
> ij> declare global temporary table x (a int) not logged;
> 0 rows inserted/updated/deleted
> ij> create view z as (select * from session.x);
> ERROR XCL47: The requested function can not reference tables in SESSION
> schema.
> So, was XCL478 truncated to XCL47? Does this mean that if I tried to do
> something that invokes the other version of XCL47 that I will get the wrong
> message? I suspect one of the message numbers needs to be changed and that
> the SQL error be fixed to be 5 characters long instead of 6.
--
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-305) Fix error messages in properties files to match text in documentation
[ http://issues.apache.org/jira/browse/DERBY-305?page=comments#action_66486 ] Samuel Andrew McIntyre commented on DERBY-305: -- David's patch committed with minor changes as revision 178809. > Fix error messages in properties files to match text in documentation > - > > Key: DERBY-305 > URL: http://issues.apache.org/jira/browse/DERBY-305 > Project: Derby > Type: Sub-task > Components: Localization > Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.0.0 > Reporter: David Van Couvering > Assignee: David Van Couvering > Priority: Trivial > Attachments: DERBY-305.diff, spelling_grammar_changes.txt, > spelling_grammar_changes_with_comments.txt > > Jeff has submitted a patch that documents the SQL States and associated error > messages, but in the process modified the English text. Now the > documentation and messages are out of synch. Rather than adjust the docs to > have the old "bad" English, this subtask will adjust the message text to > match the "good" English in the documentation. > If I find any more adjustments are needed, I will note them, and the > documentation may need to go through another revision to make sure they match. > One thought for a future feature: create a script that generates the > documentation directly from the message files, or that generates the > documentation *and* messages from an independent (XML) source file, so this > is not an ongoing exercise... -- 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-180) XCL47 SQLState duplicated in messages_en.properties?
[ http://issues.apache.org/jira/browse/DERBY-180?page=all ]
Samuel Andrew McIntyre updated DERBY-180:
-
Attachment: DERBY-180.diff
attaching patch previously submitted to derby-dev
> XCL47 SQLState duplicated in messages_en.properties?
>
>
> Key: DERBY-180
> URL: http://issues.apache.org/jira/browse/DERBY-180
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.0.2.0
> Environment: Windows XP SP1 Professional
> Reporter: George Baklarz
> Assignee: Samuel Andrew McIntyre
> Priority: Minor
> Attachments: DERBY-180.diff
>
> In the messages_en.properties file, there are two items that are similar:
> XCL47.S=Use of ''{0}'' requires database to be upgraded from version {1} to
> version {2} or later.
> XCL478.S=The requested function can not reference tables in SESSION schema.
> SQLSTATEs are supposed to be 5 characters long. When I issue a CREATE VIEW on
> a SESSION table, I receive the proper error message:
> ij> declare global temporary table x (a int) not logged;
> 0 rows inserted/updated/deleted
> ij> create view z as (select * from session.x);
> ERROR XCL47: The requested function can not reference tables in SESSION
> schema.
> So, was XCL478 truncated to XCL47? Does this mean that if I tried to do
> something that invokes the other version of XCL47 that I will get the wrong
> message? I suspect one of the message numbers needs to be changed and that
> the SQL error be fixed to be 5 characters long instead of 6.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-180) XCL47 SQLState duplicated in messages_en.properties?
[ http://issues.apache.org/jira/browse/DERBY-180?page=all ]
Samuel Andrew McIntyre closed DERBY-180:
Resolution: Fixed
Fix Version: 10.1.0.0
Committed, revision 179260.
> XCL47 SQLState duplicated in messages_en.properties?
>
>
> Key: DERBY-180
> URL: http://issues.apache.org/jira/browse/DERBY-180
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.0.2.0
> Environment: Windows XP SP1 Professional
> Reporter: George Baklarz
> Assignee: Samuel Andrew McIntyre
> Priority: Minor
> Fix For: 10.1.0.0
> Attachments: DERBY-180.diff
>
> In the messages_en.properties file, there are two items that are similar:
> XCL47.S=Use of ''{0}'' requires database to be upgraded from version {1} to
> version {2} or later.
> XCL478.S=The requested function can not reference tables in SESSION schema.
> SQLSTATEs are supposed to be 5 characters long. When I issue a CREATE VIEW on
> a SESSION table, I receive the proper error message:
> ij> declare global temporary table x (a int) not logged;
> 0 rows inserted/updated/deleted
> ij> create view z as (select * from session.x);
> ERROR XCL47: The requested function can not reference tables in SESSION
> schema.
> So, was XCL478 truncated to XCL47? Does this mean that if I tried to do
> something that invokes the other version of XCL47 that I will get the wrong
> message? I suspect one of the message numbers needs to be changed and that
> the SQL error be fixed to be 5 characters long instead of 6.
--
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-332) Documentation changes for updatable ResultSets
Documentation changes for updatable ResultSets -- Key: DERBY-332 URL: http://issues.apache.org/jira/browse/DERBY-332 Project: Derby Type: Improvement Components: Documentation Versions: 10.1.0.0 Reporter: Samuel Andrew McIntyre Derby's documentation needs to be updated with information on updatable ResultSets. A patch was already submitted and reviewed, but not committed in the thread "[patch][doc] updatable ResultSets" which can be found here: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL PROTECTED] I am opening this JIRA and attaching the patch here so that it is not forgotten. -- 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-332) Documentation changes for updatable ResultSets
[ http://issues.apache.org/jira/browse/DERBY-332?page=all ] Samuel Andrew McIntyre updated DERBY-332: - Attachment: resultsets_changes.diff Attaching Jeff's revised patch from 4/27/2005 for this issue. > Documentation changes for updatable ResultSets > -- > > Key: DERBY-332 > URL: http://issues.apache.org/jira/browse/DERBY-332 > Project: Derby > Type: Improvement > Components: Documentation > Versions: 10.1.0.0 > Reporter: Samuel Andrew McIntyre > Attachments: resultsets_changes.diff > > Derby's documentation needs to be updated with information on updatable > ResultSets. A patch was already submitted and reviewed, but not committed in > the thread "[patch][doc] updatable ResultSets" which can be found here: > http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL > PROTECTED] > I am opening this JIRA and attaching the patch here so that it is not > forgotten. -- 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-332) Documentation changes for updatable ResultSets
[ http://issues.apache.org/jira/browse/DERBY-332?page=comments#action_66699 ] Samuel Andrew McIntyre commented on DERBY-332: -- I am not able to apply the patch cleanly to an updated checkout of derby/docs. The patch needs to be updated so that it can be applied to the latest revision of the docs. > Documentation changes for updatable ResultSets > -- > > Key: DERBY-332 > URL: http://issues.apache.org/jira/browse/DERBY-332 > Project: Derby > Type: Improvement > Components: Documentation > Versions: 10.1.0.0 > Reporter: Samuel Andrew McIntyre > Attachments: resultsets_changes.diff > > Derby's documentation needs to be updated with information on updatable > ResultSets. A patch was already submitted and reviewed, but not committed in > the thread "[patch][doc] updatable ResultSets" which can be found here: > http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL > PROTECTED] > I am opening this JIRA and attaching the patch here so that it is not > forgotten. -- 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-305) Fix error messages in properties files to match text in documentation
[ http://issues.apache.org/jira/browse/DERBY-305?page=all ] Samuel Andrew McIntyre updated DERBY-305: - Attachment: DERBY305edits.diff Proposed edits to DERBY-305.diff > Fix error messages in properties files to match text in documentation > - > > Key: DERBY-305 > URL: http://issues.apache.org/jira/browse/DERBY-305 > Project: Derby > Type: Sub-task > Components: Localization > Versions: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.0.0 > Reporter: David Van Couvering > Assignee: David Van Couvering > Priority: Trivial > Attachments: DERBY-305.diff, DERBY305edits.diff, > spelling_grammar_changes.txt, spelling_grammar_changes_with_comments.txt > > Jeff has submitted a patch that documents the SQL States and associated error > messages, but in the process modified the English text. Now the > documentation and messages are out of synch. Rather than adjust the docs to > have the old "bad" English, this subtask will adjust the message text to > match the "good" English in the documentation. > If I find any more adjustments are needed, I will note them, and the > documentation may need to go through another revision to make sure they match. > One thought for a future feature: create a script that generates the > documentation directly from the message files, or that generates the > documentation *and* messages from an independent (XML) source file, so this > is not an ongoing exercise... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-220) Javadoc build should include a timestamp and/or the svn revision number in a visible location.
[ http://issues.apache.org/jira/browse/DERBY-220?page=all ] Samuel Andrew McIntyre closed DERBY-220: Resolution: Fixed Committed, revision 179401. > Javadoc build should include a timestamp and/or the svn revision number in a > visible location. > -- > > Key: DERBY-220 > URL: http://issues.apache.org/jira/browse/DERBY-220 > Project: Derby > Type: Improvement > Components: Build tools > Versions: 10.1.0.0 > Reporter: Samuel Andrew McIntyre > Assignee: Dyre Tjeldvoll > Priority: Minor > Fix For: 10.1.0.0 > Attachments: derby-220.2.diff, derby-220.diff, derbyall_report.txt, > javadoc-ts.jpg > > In order to easily identify when a specific set of javadoc was built, and > from what source, it would be useful to include a timestamp and/or the svn > revision number at the time the javadoc is built. The footer is an excellent > location to place this information, as it is visible on every generated page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-313) testing/README.htm property descriptions: testSpecialProps wrongly named; useprocess omitted
[ http://issues.apache.org/jira/browse/DERBY-313?page=all ] Samuel Andrew McIntyre closed DERBY-313: Resolution: Fixed Fix Version: 10.1.0.0 Committed, revision 179402. > testing/README.htm property descriptions: testSpecialProps wrongly named; > useprocess omitted > > > Key: DERBY-313 > URL: http://issues.apache.org/jira/browse/DERBY-313 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.1.0.0 > Environment: n/a > Reporter: Dag H. Wanvik > Assignee: Dag H. Wanvik > Priority: Minor > Fix For: 10.1.0.0 > Attachments: 313.diff > > In section 4.12 in ../testing/README.htm, the property > TestSpecialFlags > is described for specifying additional properties to RunTest. I could not > find any evidence of this in RunTest or elsewhere. However, the property > testSpecialProps > is supported by RunTest.java. I found this to work. This property > also has a syntax for specifying more than one property using a "^" > delimiter between properties, i.e. > testSpecialProps==^ ... ^= > Also,I noticed the property "useprocess" (default=true) for controlling > whether RunTest runs the test in a separate vm or a thread in current > vm isn't documented in README.htm. I suggest it be included, since > it's potentially useful for debugging tests. I could include it in the > patch for derby-313 (I don't think anybody committed it yet) or file a > new JIRA issue. > Looking at RunTest reveals that unit tests are not (yet) runnable with > "useprocess=false", though. -- 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-102) can not insert more than 32270 charakters in long varchar, clob
[
http://issues.apache.org/jira/browse/DERBY-102?page=comments#action_66777 ]
Samuel Andrew McIntyre commented on DERBY-102:
--
Sunitha or Rainer,
Could you please review the documentation changes that were made for this
issue? If there are no further comments, I will close this by Friday.
> can not insert more than 32270 charakters in long varchar, clob
> ---
>
> Key: DERBY-102
> URL: http://issues.apache.org/jira/browse/DERBY-102
> Project: Derby
> Type: Bug
> Components: Documentation
> Versions: 10.0.2.1
> Environment: Windows XP/2000
> Reporter: rainer garbotz
> Priority: Critical
>
> I have created an table with
> create table egal (
> text long varchar
> );
> Now I try to insert an 38000 charakters long String.
> insert into egal values ('
> ..
> ');
> But there are following error message:
> ERROR 54002: A string constant starting with ''
> d&' is too long.
> I tryed the same with CLOB, but the same error occures.
> The "Reference Manual" says to LONG VARCHAR:
> "The LONG VARCHAR type allows storage of character strings of unlimited
> length"
> Have I missunderstood this, or is this a BUG.
> Thanks
> Rainer
--
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-179) Hibernate bad support
[
http://issues.apache.org/jira/browse/DERBY-179?page=comments#action_66778 ]
Samuel Andrew McIntyre commented on DERBY-179:
--
Dju Dju,
Now that DERBY-104 and DERBY-127 have been fixed, I would like to lower the
priority on this bug to major and assign to a future release, or close this bug
altogether if you are satisfied with the current state of Derby/Hibernate
interaction. The latest 10.1.0.0 alpha snapshot build at:
http://incubator.apache.org/derby/derby_downloads.html
should contain both of these fixes. Please let me know if I can lower the
priority of this bug or close it altogether.
> Hibernate bad support
> -
>
> Key: DERBY-179
> URL: http://issues.apache.org/jira/browse/DERBY-179
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.0.2.1
> Environment: SUN JDK 1.4
> Hibernate 2.1.8
> Reporter: dju dju
> Priority: Blocker
>
> When trying to use Derby with the Hibernate basic example (auction system -
> ant eg) I get the following error . I have being using the Derby Dialect
> posted at http://opensource.atlassian.com/projects/hibernate/browse/HB-1224
> Here is the error message:
> ===
> [java] Hibernate: select * from ( select rownumber() over(order by
> auctionite0_.ends desc) as rownumber_, auctionite0_.id as id0_, bids1_.id as
> id1_, user2_.id as id2_, auctionite0_.description as descript2_0_,
> auctionite0_.ends as ends0_, auctionite0_.condition as condition0_,
> auctionite0_.seller as seller0_, auctionite0_.successfulBid as successf6_0_,
> bids1_.isBuyNow as isBuyNow1_, bids1_.amount as amount1_, bids1_.datetime as
> datetime1_, bids1_.bidder as bidder1_, bids1_.item as item1_, user2_.userName
> as userName2_, user2_."password" as y3_2_, user2_.email as email2_,
> user2_.firstName as firstName2_, user2_."initial" as y6_2_, user2_.lastName
> as lastName2_, bids1_.item as item__, bids1_.id as id__ from AuctionItem
> auctionite0_ left outer join Bid bids1_ on auctionite0_.id=bids1_.item left
> outer join AuctionUser user2_
> on bids1_.bidder=user2_.id order by auctionite0_.ends desc ) as temp_ where
> rownumber_ <= ?
> [java] 15:16:29,959 WARN JDBCExceptionReporter:57 - SQL Error: -1,
> SQLState: 42X01
> [java] 15:16:29,959 ERROR JDBCExceptionReporter:58 - DB2 SQL error:
> SQLCODE: -1, SQLSTATE: 42X01, SQLERRMC: Encount
> ered "(" at line 1, column 40¶42X01
> [java] 15:16:29,990 WARN JDBCExceptionReporter:57 - SQL Error: -1,
> SQLState: 42X01
> [java] 15:16:29,990 ERROR JDBCExceptionReporter:58 - DB2 SQL error:
> SQLCODE: -1, SQLSTATE: 42X01, SQLERRMC: Encount
> ered "(" at line 1, column 40¶42X01
> [java] net.sf.hibernate.exception.SQLGrammarException: Could not execute
> query
> [java] at
> net.sf.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:58)
> [java] at
> net.sf.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
> [java] at
> net.sf.hibernate.impl.SessionImpl.convert(SessionImpl.java:4131)
> [java] at
> net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1557)
> [java] at net.sf.hibernate.impl.QueryImpl.list(QueryImpl.java:49)
> [java] at
> org.hibernate.auction.Main.viewAllAuctionsSlow(Main.java:86)
> [java] at org.hibernate.auction.Main.main(Main.java:366)
> Can you help with this?
--
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-93) Cannot connect to Derby using DB2 Universal Driver
[ http://issues.apache.org/jira/browse/DERBY-93?page=all ] Samuel Andrew McIntyre resolved DERBY-93: - Resolution: Duplicate Duplicate of DERBY-92 > Cannot connect to Derby using DB2 Universal Driver > -- > > Key: DERBY-93 > URL: http://issues.apache.org/jira/browse/DERBY-93 > Project: Derby > Type: Bug > Components: JDBC > Versions: 10.0.2.1 > Environment: JDK 1.4.2.x > Reporter: Raj Subramani > Priority: Minor > > As per the Server & Admi guide, the Derby network server should be accesible > using the DB2 Universal Driver. > namely, > db2jcc.jar > db2jcc_license_c.jar > I have a (licensed) copy of the above driver which which I am able to connect > to Cloudscape-DB2 v5.1.2. > Howver using the same driver jars I am unable to connect to Derby, the trace > as follows: > java.sql.SQLException: No suitable driver > at java.sql.DriverManager.getConnection(DriverManager.java:532) > at java.sql.DriverManager.getConnection(DriverManager.java:171) > at db.connection.TestConnection.setUp(TestConnection.java:34) > at junit.framework.TestCase.runBare(TestCase.java:125) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186) > My connectivity properties are: > db.driver=com.ibm.db2.jcc.DB2Driver > db.url=jdbc:derby:net://localhost/:bootPassword= > db.user=demo > db.password=demo > The Derby database was created using ij and is an encrypted database. I am > able to connect to Derby with the embedded driver > db.driver=db.driver=org.apache.derby.jdbc.EmbeddedDriver > db.url=jdbc:derby:H:/rl-hibernate/db/derby_10_0_2_1/ name>;bootPassword= > db.user=demo > db.password=demo > NOTE: The use of the ";" for bootPassword in embedded mode and the use of ":" > in the network mode. This is as per the docs (and I have even tried using ";" > for the networked mode but it will still not connect). > I then went and downloaded Clodscape 10 and used > db2jcc.jar > db2jcc_license_c.jar > from this distribution. > When I used the ":" syntax for the bootpassword, as per the docs I got: > com.ibm.db2.jcc.c.SqlException: Invalid database url syntax: > jdbc:derby:net://localhost/:bootPassword= > at com.ibm.db2.jcc.DB2Driver.tokenizeURLProperties(DB2Driver.java:555) > at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:131) > at java.sql.DriverManager.getConnection(DriverManager.java:512) > at java.sql.DriverManager.getConnection(DriverManager.java:171) > at db.connection.TestConnection.setUp(TestConnection.java:34) > at junit.framework.TestCase.runBare(TestCase.java:125) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186) > However, using a ";" before bootPassword=... > results in a SUCCESSFUL connection. > I think it might be useful to state that it will work only with Cloudscape > 10.0 (or above) IBM Universal drivers. > Also given that this licensed driver may expire after some time (as per the > IBM license file), it makes it diffult to use this over a longer term. Will > there be a AF licensed network driver for Derby? -- 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-92) Cannot connect to Derby using DB2 Universal Driver
[ http://issues.apache.org/jira/browse/DERBY-92?page=all ] Samuel Andrew McIntyre reassigned DERBY-92: --- Assign To: Samuel Andrew McIntyre > Cannot connect to Derby using DB2 Universal Driver > -- > > Key: DERBY-92 > URL: http://issues.apache.org/jira/browse/DERBY-92 > Project: Derby > Type: Bug > Versions: 10.0.2.1 > Environment: JDK 1.4.x > Reporter: Raj Subramani > Assignee: Samuel Andrew McIntyre > > As per the Server & Admi guide, the Derby network server should be accesible > using the DB2 Universal Driver. > namely, > db2jcc.jar > db2jcc_license_c.jar > I have a (licensed) copy of the above driver which which I am able to connect > to Cloudscape-DB2 v5.1.2. > Howver using the same driver jars I am unable to connect to Derby, the trace > as follows: > java.sql.SQLException: No suitable driver > at java.sql.DriverManager.getConnection(DriverManager.java:532) > at java.sql.DriverManager.getConnection(DriverManager.java:171) > at db.connection.TestConnection.setUp(TestConnection.java:34) > at junit.framework.TestCase.runBare(TestCase.java:125) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186) > My connectivity properties are: > db.driver=com.ibm.db2.jcc.DB2Driver > db.url=jdbc:derby:net://localhost/:bootPassword= > db.user=demo > db.password=demo > The Derby database was created using ij and is an encrypted database. I am > able to connect to Derby with the embedded driver > db.driver=db.driver=org.apache.derby.jdbc.EmbeddedDriver > db.url=jdbc:derby:H:/raruslibri-hibernate/db/derby_10_0_2_1/raruslibri;bootPassword= > db.user=demo > db.password=demo > NOTE: The use of the ";" for bootPassword in embedded mode and the use of ":" > in the network mode. This is as per the docs (and I have even tried using ";" > for the networked mode but it will still not connect). > I then went and downloaded Clodscape 10 and used > db2jcc.jar > db2jcc_license_c.jar > from this distribution. > When I used the ":" syntax for the bootpassword, as per the docs I got: > com.ibm.db2.jcc.c.SqlException: Invalid database url syntax: > jdbc:derby:net://localhost/:bootPassword= > at com.ibm.db2.jcc.DB2Driver.tokenizeURLProperties(DB2Driver.java:555) > at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:131) > at java.sql.DriverManager.getConnection(DriverManager.java:512) > at java.sql.DriverManager.getConnection(DriverManager.java:171) > at db.connection.TestConnection.setUp(TestConnection.java:34) > at junit.framework.TestCase.runBare(TestCase.java:125) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186) > However, using a ";" before bootPassword=... > results in a SUCCESSFUL connection. > I think it might be useful to state that it will work only with Cloudscape > 10.0 (or above) IBM Universal drivers. > Also given that this licensed driver may expire after some time (as per the > IBM license file), it makes it diffult to use this over a longer term. Will > there be a AF licensed network driver for Derby? -- 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-92) Cannot connect to Derby using DB2 Universal Driver
[ http://issues.apache.org/jira/browse/DERBY-92?page=all ] Samuel Andrew McIntyre reassigned DERBY-92: --- Assign To: (was: Samuel Andrew McIntyre) > Cannot connect to Derby using DB2 Universal Driver > -- > > Key: DERBY-92 > URL: http://issues.apache.org/jira/browse/DERBY-92 > Project: Derby > Type: Bug > Versions: 10.0.2.1 > Environment: JDK 1.4.x > Reporter: Raj Subramani > > As per the Server & Admi guide, the Derby network server should be accesible > using the DB2 Universal Driver. > namely, > db2jcc.jar > db2jcc_license_c.jar > I have a (licensed) copy of the above driver which which I am able to connect > to Cloudscape-DB2 v5.1.2. > Howver using the same driver jars I am unable to connect to Derby, the trace > as follows: > java.sql.SQLException: No suitable driver > at java.sql.DriverManager.getConnection(DriverManager.java:532) > at java.sql.DriverManager.getConnection(DriverManager.java:171) > at db.connection.TestConnection.setUp(TestConnection.java:34) > at junit.framework.TestCase.runBare(TestCase.java:125) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186) > My connectivity properties are: > db.driver=com.ibm.db2.jcc.DB2Driver > db.url=jdbc:derby:net://localhost/:bootPassword= > db.user=demo > db.password=demo > The Derby database was created using ij and is an encrypted database. I am > able to connect to Derby with the embedded driver > db.driver=db.driver=org.apache.derby.jdbc.EmbeddedDriver > db.url=jdbc:derby:H:/raruslibri-hibernate/db/derby_10_0_2_1/raruslibri;bootPassword= > db.user=demo > db.password=demo > NOTE: The use of the ";" for bootPassword in embedded mode and the use of ":" > in the network mode. This is as per the docs (and I have even tried using ";" > for the networked mode but it will still not connect). > I then went and downloaded Clodscape 10 and used > db2jcc.jar > db2jcc_license_c.jar > from this distribution. > When I used the ":" syntax for the bootpassword, as per the docs I got: > com.ibm.db2.jcc.c.SqlException: Invalid database url syntax: > jdbc:derby:net://localhost/:bootPassword= > at com.ibm.db2.jcc.DB2Driver.tokenizeURLProperties(DB2Driver.java:555) > at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:131) > at java.sql.DriverManager.getConnection(DriverManager.java:512) > at java.sql.DriverManager.getConnection(DriverManager.java:171) > at db.connection.TestConnection.setUp(TestConnection.java:34) > at junit.framework.TestCase.runBare(TestCase.java:125) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186) > However, using a ";" before bootPassword=... > results in a SUCCESSFUL connection. > I think it might be useful to state that it will work only with Cloudscape > 10.0 (or above) IBM Universal drivers. > Also given that this licensed driver may expire after some time (as per the > IBM license file), it makes it diffult to use this over a longer term. Will > there be a AF licensed network driver for Derby? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-102) can not insert more than 32270 charakters in long varchar, clob
[ http://issues.apache.org/jira/browse/DERBY-102?page=all ]
Samuel Andrew McIntyre closed DERBY-102:
Resolution: Fixed
Fix Version: 10.1.0.0
Fix in original contributed DITA documentation. Review by Sunitha was positive.
closing.
> can not insert more than 32270 charakters in long varchar, clob
> ---
>
> Key: DERBY-102
> URL: http://issues.apache.org/jira/browse/DERBY-102
> Project: Derby
> Type: Bug
> Components: Documentation
> Versions: 10.0.2.1
> Environment: Windows XP/2000
> Reporter: rainer garbotz
> Priority: Critical
> Fix For: 10.1.0.0
>
> I have created an table with
> create table egal (
> text long varchar
> );
> Now I try to insert an 38000 charakters long String.
> insert into egal values ('
> ..
> ');
> But there are following error message:
> ERROR 54002: A string constant starting with ''
> d&' is too long.
> I tryed the same with CLOB, but the same error occures.
> The "Reference Manual" says to LONG VARCHAR:
> "The LONG VARCHAR type allows storage of character strings of unlimited
> length"
> Have I missunderstood this, or is this a BUG.
> Thanks
> Rainer
--
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-243) connection toString should uniquely identify the connection
[ http://issues.apache.org/jira/browse/DERBY-243?page=all ] Samuel Andrew McIntyre updated DERBY-243: - Version: 10.0.2.1 10.0.2.0 10.0.2.2 10.1.0.0 Fix Version: (was: 10.0.2.1) (was: 10.0.2.0) (was: 10.0.2.2) > connection toString should uniquely identify the connection > --- > > Key: DERBY-243 > URL: http://issues.apache.org/jira/browse/DERBY-243 > Project: Derby > Type: Improvement > Components: JDBC > Versions: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.0.0 > Reporter: Kathey Marsden > Assignee: David Van Couvering > Priority: Trivial > Fix For: 10.1.0.0 > Attachments: DERBY-243.diff > > The toString() on the Derby connection doesn't print > unique information. > for example System.out.println(conn) prints: > EmbedConnection in the case of derby embedded > It would be great if the toString() method for connections could be used to > differentiate one connection from another. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-108) Document performance tip for inserts in tuning guide
[ http://issues.apache.org/jira/browse/DERBY-108?page=all ] Samuel Andrew McIntyre closed DERBY-108: Assign To: Jeff Levitt Resolution: Fixed Fix Version: 10.1.0.0 (was: 10.0.2.2) Confirmed that the new tuning suggestion is in the Tuning Guide for 10.1. > Document performance tip for inserts in tuning guide > > > Key: DERBY-108 > URL: http://issues.apache.org/jira/browse/DERBY-108 > Project: Derby > Type: Improvement > Components: Documentation > Versions: 10.0.2.1 > Reporter: Sunitha Kambhampati > Assignee: Jeff Levitt > Priority: Minor > Fix For: 10.1.0.0 > > Need to add this important performance tip in the tuning guide document. > Could probably be added as Tip #8 in > http://incubator.apache.org/derby/manuals/tuning/perf20.html#HDRSII-PERF-25864 > -- > Avoid inserts in autocommit mode if possible: > Inserts can be painfully slow in autocommit mode. The reason is that each > commit involves a flush of the log to the disk for each insert statement. > The commit will not return until a physical disk write has been executed. > To speed things up, there are 2 possibilities > - Run in autocommit false mode and execute a number of inserts in one > transaction and then explicitly issue a commit. > - If your application allows an initial load into the table, one can use the > import system procedures to insert data into a table. > http://incubator.apache.org/derby/manuals/tools/tools90.html#HDRSII-IMPORT-57005. > If loading into an empty table using these interfaces, derby will not log the > individual inserts. The reason is recovery understands that a backout of this > operation is an empty table, and the data in the table is forced to > disk before the transaction commits. > > References from derby mailing lists: > http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=363 > http://nagoya.apache.org/eyebrowse/ReadMsg?listId=271&msgNo=335 -- 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-289) Enable code sharing between Derby client and engine
[ http://issues.apache.org/jira/browse/DERBY-289?page=all ] Samuel Andrew McIntyre updated DERBY-289: - Fix Version: 10.2.0.0 (was: 10.0.2.2) > Enable code sharing between Derby client and engine > --- > > Key: DERBY-289 > URL: http://issues.apache.org/jira/browse/DERBY-289 > Project: Derby > Type: Improvement > Components: Network Client > Versions: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.0.0 > Environment: N/A > Reporter: David Van Couvering > Priority: Minor > Fix For: 10.2.0.0 > > Right now, there is no way for the Derby network client to share code with > the Derby engine. We should have a separate jar file, e.g. derby_common.jar, > that contains shared code and is used by both the client and the engine. -- 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-48) A connection request that has a default schema that is being created by another transaction will fail to connect
[ http://issues.apache.org/jira/browse/DERBY-48?page=all ] Samuel Andrew McIntyre updated DERBY-48: Version: 10.0.2.1 10.0.2.2 10.1.0.0 Fix Version: 10.2.0.0 (was: 10.0.2.0) Moving fix in version to 10.2.0.0. > A connection request that has a default schema that is being created by > another transaction will fail to connect > - > > Key: DERBY-48 > URL: http://issues.apache.org/jira/browse/DERBY-48 > Project: Derby > Type: Bug > Components: JDBC > Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.0.0 > Reporter: Kathey Marsden > Fix For: 10.2.0.0 > > A connection request that has a default schema that is being > created by another transaction will block until that transaction > completes (or time out). Probably in this situation the connection > request should be succeed as if the schema does not exist. > This is a problem in particular for a prepared XA transaction, where even > after restarting the system, the user cannot reconnect and recover the > transaction. > Here is the reproduction in ij. > java -Dij.exceptionTrace=true -Dij.protocol=jdbc:derby: -Dij.user=me > -Dij.password=pw org.apache.derby.tools.ij > ij version 10.0 (C) Copyright IBM Corp. 1997, 2004. > ij> connect 'testdb;create=true'; > ij> autocommit off; > ij> create table mytabi(i int); > 0 rows inserted/updated/deleted > ij> connect 'testdb'; > ERROR 40XL1: A lock could not be obtained within the time requestedERROR > 40XL1: A lock could not be obtained within the time requested > at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java:295) > at > org.apache.derby.impl.services.locks.LockSet.lockObject(LockSet.java:408) > at > org.apache.derby.impl.services.locks.SinglePool.lockAnObject(SinglePool.java:168) > at > org.apache.derby.impl.services.locks.SinglePool.lockObject(SinglePool.java:220) > at > org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForRead(RowLocking3.java:181) > at > org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:425) > at > org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:543) > at > org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(B2IRowLocking3.java:329) > at > org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(B2IRowLocking3.java:571) > at > org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(B2IRowLockingRR.java:115) > at > org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java:374) > at > org.apache.derby.impl.store.access.btree.BTreeScan.next(BTreeScan.java:1691) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java:7118) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java:1381) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java:1291) > at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.initDefaultSchemaDescriptor(GenericLanguageCon > at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.initialize(GenericLanguageConnectionContext.ja > at > org.apache.derby.impl.db.BasicDatabase.setupConnection(BasicDatabase.java:267) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.startTransaction(TransactionResourceImpl.java:182) > at > org.apache.derby.impl.jdbc.EmbedConnection.(EmbedConnection.java:237) > at > org.apache.derby.impl.jdbc.EmbedConnection20.(EmbedConnection20.java:49) > at > org.apache.derby.impl.jdbc.EmbedConnection30.(EmbedConnection30.java:56) > at > org.apache.derby.jdbc.Driver30.getNewEmbedConnection(Driver30.java:68) > at org.apache.derby.jdbc.Driver169.connect(Driver169.java:172) > at java.sql.DriverManager.getConnection(DriverManager.java:512) > at java.sql.DriverManager.getConnection(DriverManager.java:140) > at org.apache.derby.impl.tools.ij.ij.dynamicConnection(ij.java:843) > at org.apache.derby.impl.tools.ij.ij.ConnectStatement(ij.java:700) > at org.apache.derby.impl.tools.ij.ij.ijStatement(ij.java:528) > at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:283) > at org.apache.derby.impl.tools.ij.Main.go(Main.java:204) > at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:170) > at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:50) > at org.apache.derby.tools.ij.main(ij.java:54) -- This message is automatical
[jira] Updated: (DERBY-318) SYS.SYSCOLUMN problem with "GENERATED BY DEFAULT" column w/ Network Server
[ http://issues.apache.org/jira/browse/DERBY-318?page=all ] Samuel Andrew McIntyre updated DERBY-318: - Fix Version: 10.1.0.0 > SYS.SYSCOLUMN problem with "GENERATED BY DEFAULT" column w/ Network Server > -- > > Key: DERBY-318 > URL: http://issues.apache.org/jira/browse/DERBY-318 > Project: Derby > Type: Bug > Components: Network Server > Versions: 10.1.0.0 > Environment: Derby in Network Server mode with either JCC or Derby Net > Client. > Reporter: A B > Fix For: 10.1.0.0 > Attachments: DERBY-318.patch, derbyall_diff.txt > > When connected to the Derby Network Server, if one has a table with a column > defined as "GENERATED BY DEFAULT" and then one tries to select the > "COLUMNDEFAULT" field from SYS.SYSCOLUMNS, the result is an NPE in the server > code that leads to connection deallocation. > I don't know if this is a problem with the "GENERATED BY DEFAULT" feature or > if it's a problem with Network Server--more investigation is required. > To reproduce, use ij to connect to a database using Network Server, and then: > ij> create table t1 (i int generated by default as identity); > 0 rows inserted/updated/deleted > ij> select columndefault from sys.syscolumns; > COLUMNDEFAULT > > > null > java.lang.NullPointerException > at > org.apache.derby.impl.drda.DRDAConnThread.writeFdocaVal(DRDAConnThread.java:6550) > at > org.apache.derby.impl.drda.DRDAConnThread.writeFDODTA(DRDAConnThread.java:5973) > at > org.apache.derby.impl.drda.DRDAConnThread.writeQRYDTA(DRDAConnThread.java:5796) > at > org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:595) > at > org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:226) > agentThread[DRDAConnThread_2,5,main] > ERROR 58009: Execution failed due to a distribution protocol error that > caused deallocation of the conversation. A DRDA Data Stream Syntax Error was > detected. Reason: 0x3 -- 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-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY"
[ http://issues.apache.org/jira/browse/DERBY-308?page=all ] Samuel Andrew McIntyre updated DERBY-308: - Version: 10.1.0.0 Fix Version: 10.1.0.0 > Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY" > --- > > Key: DERBY-308 > URL: http://issues.apache.org/jira/browse/DERBY-308 > Project: Derby > Type: Sub-task > Versions: 10.1.0.0 > Reporter: Tomohito Nakayama > Assignee: Tomohito Nakayama > Fix For: 10.1.0.0 > Attachments: DERBY-308.patch > > The Derby "dblook" utility needs to support "GENERATED BY DEFAULT AS > IDENTITY". > This issue was notified in next mail. > http://article.gmane.org/gmane.comp.apache.db.derby.devel/4096 -- 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-322) Remove resultSetHoldability property from ClientDataSource
[ http://issues.apache.org/jira/browse/DERBY-322?page=all ] Samuel Andrew McIntyre updated DERBY-322: - Fix Version: 10.1.0.0 > Remove resultSetHoldability property from ClientDataSource > -- > > Key: DERBY-322 > URL: http://issues.apache.org/jira/browse/DERBY-322 > Project: Derby > Type: Bug > Components: JDBC, Network Client > Versions: 10.1.0.0 > Reporter: Daniel John Debrunner > Fix For: 10.1.0.0 > > ClientDataSource (through ClientBaseDataSource) implements a Java Bean > property resultSetHoldability which is not documented in the functional spec > at. > http://incubator.apache.org/derby/papers/DerbyClientSpec.html > JDBC provides standard ways to set the holdability of ResultSets, so a > non-standard separate mechanism is not required. The property and associated > code needs to be removed. -- 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-179) Hibernate bad support
[ http://issues.apache.org/jira/browse/DERBY-179?page=all ]
Samuel Andrew McIntyre updated DERBY-179:
-
Priority: Major (was: Blocker)
> Hibernate bad support
> -
>
> Key: DERBY-179
> URL: http://issues.apache.org/jira/browse/DERBY-179
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.0.2.1
> Environment: SUN JDK 1.4
> Hibernate 2.1.8
> Reporter: dju dju
>
> When trying to use Derby with the Hibernate basic example (auction system -
> ant eg) I get the following error . I have being using the Derby Dialect
> posted at http://opensource.atlassian.com/projects/hibernate/browse/HB-1224
> Here is the error message:
> ===
> [java] Hibernate: select * from ( select rownumber() over(order by
> auctionite0_.ends desc) as rownumber_, auctionite0_.id as id0_, bids1_.id as
> id1_, user2_.id as id2_, auctionite0_.description as descript2_0_,
> auctionite0_.ends as ends0_, auctionite0_.condition as condition0_,
> auctionite0_.seller as seller0_, auctionite0_.successfulBid as successf6_0_,
> bids1_.isBuyNow as isBuyNow1_, bids1_.amount as amount1_, bids1_.datetime as
> datetime1_, bids1_.bidder as bidder1_, bids1_.item as item1_, user2_.userName
> as userName2_, user2_."password" as y3_2_, user2_.email as email2_,
> user2_.firstName as firstName2_, user2_."initial" as y6_2_, user2_.lastName
> as lastName2_, bids1_.item as item__, bids1_.id as id__ from AuctionItem
> auctionite0_ left outer join Bid bids1_ on auctionite0_.id=bids1_.item left
> outer join AuctionUser user2_
> on bids1_.bidder=user2_.id order by auctionite0_.ends desc ) as temp_ where
> rownumber_ <= ?
> [java] 15:16:29,959 WARN JDBCExceptionReporter:57 - SQL Error: -1,
> SQLState: 42X01
> [java] 15:16:29,959 ERROR JDBCExceptionReporter:58 - DB2 SQL error:
> SQLCODE: -1, SQLSTATE: 42X01, SQLERRMC: Encount
> ered "(" at line 1, column 40¶42X01
> [java] 15:16:29,990 WARN JDBCExceptionReporter:57 - SQL Error: -1,
> SQLState: 42X01
> [java] 15:16:29,990 ERROR JDBCExceptionReporter:58 - DB2 SQL error:
> SQLCODE: -1, SQLSTATE: 42X01, SQLERRMC: Encount
> ered "(" at line 1, column 40¶42X01
> [java] net.sf.hibernate.exception.SQLGrammarException: Could not execute
> query
> [java] at
> net.sf.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:58)
> [java] at
> net.sf.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
> [java] at
> net.sf.hibernate.impl.SessionImpl.convert(SessionImpl.java:4131)
> [java] at
> net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1557)
> [java] at net.sf.hibernate.impl.QueryImpl.list(QueryImpl.java:49)
> [java] at
> org.hibernate.auction.Main.viewAllAuctionsSlow(Main.java:86)
> [java] at org.hibernate.auction.Main.main(Main.java:366)
> Can you help with this?
--
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-132) in place table/index compress which returns space to OS
[ http://issues.apache.org/jira/browse/DERBY-132?page=all ] Samuel Andrew McIntyre updated DERBY-132: - Fix Version: 10.1.0.0 > in place table/index compress which returns space to OS > --- > > Key: DERBY-132 > URL: http://issues.apache.org/jira/browse/DERBY-132 > Project: Derby > Type: Improvement > Components: Store > Versions: 10.1.0.0 > Reporter: Mike Matrigali > Assignee: Mike Matrigali > Fix For: 10.1.0.0 > > Each derby table or index is stored in a separate file. Space from > deleted rows is eventually reclaimed within the file as is used for > subsequent inserts into the same file. That space is not returned to > the OS unless the user calls the SYSCS_UTIL.SYSCS_COMPRESS_TABLE > system procedure. That procedure will return the unused space in > the tables and indexes to the OS. It gets an exclusive lock on the > table, copies all rows in the indexes and the base table into new > compressed files and delete the old files. Prior to jdk 1.4 this was > the only way to return space from a file to the OS. > In jdk 1.4 RandomAccessFile was enhanced to allow the truncation of a > file, which would return the space at the "end" of the file back to > the OS. In order to take advantage of this new feature a new > compress feature is needed in derby. > The assumption is that this work will be used in future work which will > automatically schedule this job and others in background, with no > interaction needed from the dba. The 1st phase of this work will > simply build a procedure that will do the work. The 2nd phase will > be to look into scheduling the procedure automatically as part of > the current background post commit processing. Longer term it would > be best if this fit into a new background task monitor, which could > schedule larger background tasks balanced against the other priorities > of the system. These tasks might include: this new online compress, > automatic statistics gathering, more proactive deleted row reclamation, > The proposed feature will reorganize base tables and indexes, moving > empty pages to the "end". It will release space back to the operating > system when it has created a chunk of empty pages at the end of the > file. It will be designed to run in background, and will lock resources > of the table for as short a time as possible so that it can iteratively > process the table. > To reclaim space in the heap, it will scan the heap in page reverse order. > It will get a short term table lock, process all the rows on a page, and > then commit that transaction releasing the lock. The commit will be > optimized like other internal transactions, and will not need to wait > for a synchonized write. Each row moved, will require all the index > entries for that row to also be updated. While doing the processing it > will also take care of processing committed deleted rows. When space > is free at the end of the table it will be freed back to the operating > system, using the RandomAccessFile.setLength() interface. > To reclaim space in the btree, data on pages will be moved rather than > rows. Data from pages at the end of the file will be moved to free > smaller numbered pages. Again short term table locks will be required, > and the operation will look similar to the current btree merge operations > already implemented. Again when a chunk of pages is free at the end of > the file, they will be returned to the OS using the same mechanism as > the heap. -- 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-247) Network Server demo program should support Derby network client driver
[ http://issues.apache.org/jira/browse/DERBY-247?page=all ] Samuel Andrew McIntyre updated DERBY-247: - Fix Version: 10.1.0.0 Lance, are you going to work on the demo part of this bug? If not, feel free to assign it to me. > Network Server demo program should support Derby network client driver > -- > > Key: DERBY-247 > URL: http://issues.apache.org/jira/browse/DERBY-247 > Project: Derby > Type: Improvement > Components: Demos/Scripts > Versions: 10.1.0.0 > Reporter: Samuel Andrew McIntyre > Assignee: Lance Andersen > Priority: Minor > Fix For: 10.1.0.0 > > Currently, the Network Server demo programs require the IBM Universal JDBC > Driver (JCC) for client functionality. The demo should be enhanced to also > support using the Derby client driver. -- 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-205) Rename org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl
[ http://issues.apache.org/jira/browse/DERBY-205?page=all ] Samuel Andrew McIntyre updated DERBY-205: - Fix Version: 10.1.0.0 > Rename org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl > - > > Key: DERBY-205 > URL: http://issues.apache.org/jira/browse/DERBY-205 > Project: Derby > Type: Task > Components: Network Server > Versions: 10.1.0.0 > Reporter: Kathey Marsden > Assignee: Dag H. Wanvik > Priority: Trivial > Fix For: 10.1.0.0 > Attachments: 205b-rev1.diff, 205b-rev1.stat > > For historical reasons the class DB2jServerImpl, which implements the public > NetworkServerControl interface is inappropriately named. It should be > renamed to NetworkServerControlImpl -- 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-156) Delete with alias on column fails
[ http://issues.apache.org/jira/browse/DERBY-156?page=all ] Samuel Andrew McIntyre updated DERBY-156: - Version: 10.0.2.1 10.0.2.0 10.0.2.2 10.1.0.0 Fix Version: 10.1.0.0 Marking as Fix in 10.1.0.0 as a patch has been submitted by Shreyas Kaushik and is in review. > Delete with alias on column fails > - > > Key: DERBY-156 > URL: http://issues.apache.org/jira/browse/DERBY-156 > Project: Derby > Type: New Feature > Components: SQL > Versions: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.0.0 > Reporter: Bernd Ruehlicke > Priority: Critical > Fix For: 10.1.0.0 > > DELETE FROM MY_TABLE x WHERE x.MY_COLUMN='value'; > fails with > ERROR 42X01: Syntax error: Encountered "x" at line 1, column 24 > This is the core of the problem. I found it form a more complicated statement > but it cooks down to that this should work but dose not. > B-) -- 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-230) "Schema already exists" when creating a table
[ http://issues.apache.org/jira/browse/DERBY-230?page=all ] Samuel Andrew McIntyre updated DERBY-230: - Fix Version: 10.1.0.0 > "Schema already exists" when creating a table > - > > Key: DERBY-230 > URL: http://issues.apache.org/jira/browse/DERBY-230 > Project: Derby > Type: Bug > Components: SQL > Versions: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.0.0 > Reporter: Øystein Grøvlen > Assignee: Øystein Grøvlen > Priority: Minor > Fix For: 10.1.0.0 > Attachments: Main.java, derby-230c.diff > > When running a multithreaded program where several threads in parallell > create tables in a schema that is not explicitly created, one often get the > following exception: > ERROR X0Y68: Schema 'TESTSCHEMA' already exists. > at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java:322) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.duplicateDescriptorException(DataDictionaryImpl.java:1512) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptorNow(DataDictionaryImpl.java:1496) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptor(DataDictionaryImpl.java:1478) > at > org.apache.derby.impl.sql.execute.CreateSchemaConstantAction.executeConstantAction(CreateSchemaConstantAction.java:147) > at > org.apache.derby.impl.sql.execute.DDLConstantAction.getSchemaDescriptorForCreate(Unknown > Source) > at > org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(CreateTableConstantAction.java:213) > at > org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:56) > at > org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:366) > at > org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1108) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:517) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:475) > at derbytest.Main$CreateTable.run(Main.java:42) > at java.lang.Thread.run(Thread.java:595) > A program that reproduces this bug will be attached. -- 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-296) Document error messages in the Derby Reference Manual
[ http://issues.apache.org/jira/browse/DERBY-296?page=all ] Samuel Andrew McIntyre updated DERBY-296: - Summary: Document error messages in the Derby Reference Manual (was: Document) Version: 10.1.0.0 Fix Version: 10.1.0.0 This document also needs to be updated to include the change for DERBY-180. > Document error messages in the Derby Reference Manual > - > > Key: DERBY-296 > URL: http://issues.apache.org/jira/browse/DERBY-296 > Project: Derby > Type: Task > Components: Documentation > Versions: 10.1.0.0 > Environment: all > Reporter: Jeff Levitt > Assignee: Jeff Levitt > Priority: Minor > Fix For: 10.1.0.0 > Attachments: derby296.zip > > I've spent some time compiling a list of error messages for Derby, to expand > on the error messages section currently in the Reference Manual. I am about > ready to submit a candidate patch, and I am opening up a JIRA issue to > contain it. -- 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-255) Closing a resultset after retrieving a large > 32K value with Network Server does not release locks
[ http://issues.apache.org/jira/browse/DERBY-255?page=all ] Samuel Andrew McIntyre updated DERBY-255: - Version: 10.0.2.1 10.0.2.0 10.0.2.2 10.1.0.0 Fix Version: 10.1.0.0 (was: 10.0.2.1) > Closing a resultset after retrieving a large > 32K value with Network Server > does not release locks > --- > > Key: DERBY-255 > URL: http://issues.apache.org/jira/browse/DERBY-255 > Project: Derby > Type: Bug > Versions: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.0.0 > Reporter: Kathey Marsden > Assignee: Kathey Marsden > Fix For: 10.1.0.0 > Attachments: LargeDataLocks.java, derby255.diff > > Closing a resultset after retriving BLOB or CLOB data > 32K, does not release > locks properly. Network Server uses getClob, getBlob to retrieve the data > even if the application uses getCharacteStream, etc, so holds locks to the > end of the transaction. > To reproduce run attached repro > java LargeDataLocks derbynetclient > > To see the difference with embedded > java LargeDataLocks derby -- 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-291) Debug VTIs should refer to connection string
[ http://issues.apache.org/jira/browse/DERBY-291?page=all ] Samuel Andrew McIntyre updated DERBY-291: - Version: 10.1.0.0 Fix Version: 10.1.0.0 (was: 10.0.2.2) > Debug VTIs should refer to connection string > > > Key: DERBY-291 > URL: http://issues.apache.org/jira/browse/DERBY-291 > Project: Derby > Type: Improvement > Components: Store > Versions: 10.1.0.0, 10.0.2.2 > Reporter: David Van Couvering > Priority: Minor > Fix For: 10.1.0.0 > > Now that the connection toString() provides a unique value, we should display > this in VTIs that show data that that can be scoped by connections (such as > locks, statement caches, etc.). We should add a column to these VTIs called > "connection" which displays the toString() value of the associated > connection. This will allow debuggers to correlate particular items in the > VTI with particular connections. -- 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-305) Fix error messages in properties files to match text in documentation
[ http://issues.apache.org/jira/browse/DERBY-305?page=all ] Samuel Andrew McIntyre resolved DERBY-305: -- Resolution: Fixed Committed revision 179696. > Fix error messages in properties files to match text in documentation > - > > Key: DERBY-305 > URL: http://issues.apache.org/jira/browse/DERBY-305 > Project: Derby > Type: Sub-task > Components: Localization > Versions: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.0.0 > Reporter: David Van Couvering > Assignee: David Van Couvering > Priority: Trivial > Fix For: 10.1.0.0 > Attachments: DERBY-305.diff, DERBY-305.status, spelling_grammar_changes.txt, > spelling_grammar_changes_with_comments.txt > > Jeff has submitted a patch that documents the SQL States and associated error > messages, but in the process modified the English text. Now the > documentation and messages are out of synch. Rather than adjust the docs to > have the old "bad" English, this subtask will adjust the message text to > match the "good" English in the documentation. > If I find any more adjustments are needed, I will note them, and the > documentation may need to go through another revision to make sure they match. > One thought for a future feature: create a script that generates the > documentation directly from the message files, or that generates the > documentation *and* messages from an independent (XML) source file, so this > is not an ongoing exercise... -- 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-221) User documentation should include a timestamp and/or svn revision number
[ http://issues.apache.org/jira/browse/DERBY-221?page=all ] Samuel Andrew McIntyre updated DERBY-221: - Fix Version: 10.2.0.0 (was: 10.1.0.0) > User documentation should include a timestamp and/or svn revision number > > > Key: DERBY-221 > URL: http://issues.apache.org/jira/browse/DERBY-221 > Project: Derby > Type: Improvement > Components: Documentation > Versions: 10.1.0.0 > Reporter: Samuel Andrew McIntyre > Priority: Minor > Fix For: 10.2.0.0 > > In order to easily identify when a set of documentation was generated, it > would be useful to add a timestamp, and possibly the svn revision at which > the documentation was generated, to the output. One approach would be to > replace a token in either the input files or final output with the > appropriate information using Ant. This may not work for PDFs, in which case > the timestamp may need to be inserted at the intermediate XSL-FO stage. -- 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-128) Network Server Gives NPE if SQLException has null arguments (e.g. for ERROR XBM0H)
[ http://issues.apache.org/jira/browse/DERBY-128?page=all ]
Samuel Andrew McIntyre updated DERBY-128:
-
Fix Version: 10.1.0.0
Description:
Network server
Network Server throws an NPE because one of the arguments of the SQLException
is null. It shouldn't do so.
To reproduce try to create a database in the root directory on Linux. Do not
run in security manager. The trace below came from an extra '/' in the url in
NSinSameJVM.java
The issues are:
1) Network Server throws an NPE because one of the arguments of the
SQLException is null in this code. It shouldn't do so.
// arguments are variable part of a message
Object[] args = ce.getArguments();
for (int i = 0; args != null && i < args.length; i++)
sqlerrmc += args[i].toString() + separator;
2) This exception seems to have null arguments which doesn't seem right.
ERROR XBM0H: Directory /NSinSameJVMTestDB cannot be created.
ERROR XBM0H: Directory /NSinSameJVMTestDB cannot be created.
at
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:322)
at
org.apache.derby.impl.services.monitor.PersistentServiceImpl$8.run(PersistentServiceImpl.java:668)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.derby.impl.services.monitor.PersistentServiceImpl.createServiceRoot(PersistentServiceImpl.java:632)
at
org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1756)
at
org.apache.derby.impl.services.monitor.BaseMonitor.createPersistentService(BaseMonitor.java:1018)
at
org.apache.derby.iapi.services.monitor.Monitor.createPersistentService(Monitor.java:578)
at
org.apache.derby.impl.jdbc.EmbedConnection.createDatabase(EmbedConnection.java:1504)
at
org.apache.derby.impl.jdbc.EmbedConnection.(EmbedConnection.java:215)
at
org.apache.derby.impl.jdbc.EmbedConnection20.(EmbedConnection20.java:56)
at
org.apache.derby.impl.jdbc.EmbedConnection30.(EmbedConnection30.java:72)
at
org.apache.derby.jdbc.Driver30.getNewEmbedConnection(Driver30.java:73)
at org.apache.derby.jdbc.Driver169.connect(Driver169.java:175)
at
org.apache.derby.impl.drda.Database.makeConnection(Database.java:245)
at
org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1160)
at
org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1138)
at
org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:2613)
at
org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1001)
at
org.apache.derby.impl.drda.DRDAConnThread.exchangeServerAttributes(DRDAConnThread.java:950)
at
org.apache.derby.impl.drda.DRDAConnThread.sessionInitialState(DRDAConnThread.java:563)
at
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:219)
Cleanup action completed
2005-01-21 01:12:12.794 GMT Thread[DRDAConnThread_2,5,derby.daemons] (DATABASE
= /NSinSameJVMTestDB), (DRDAID = {2}), Failed to create database
'/NSinSameJVMTestDB', see the next exception for details.
2005-01-21 01:12:12.795 GMT Thread[DRDAConnThread_2,5,derby.daemons] (DATABASE
= /NSinSameJVMTestDB), (DRDAID = {2}), Directory /NSinSameJVMTestDB cannot be
created.
2005-01-21 01:12:12.816 GMT Thread[DRDAConnThread_2,5,derby.daemons] (DATABASE
= /NSinSameJVMTestDB), (DRDAID = NF01.A9FB-4124733202448020360{2}), Failed
to create database '/NSinSameJVMTestDB', see the next exception for details.
2005-01-21 01:12:12.816 GMT Thread[DRDAConnThread_2,5,derby.daemons] (DATABASE
= /NSinSameJVMTestDB), (DRDAID = NF01.A9FB-4124733202448020360{2}), null
null
java.lang.NullPointerException
at
org.apache.derby.impl.drda.DRDAConnThread.writeSQLCAGRP(DRDAConnThread.java:5076)
at
org.apache.derby.impl.drda.DRDAConnThread.writeSQLCARD(DRDAConnThread.java:4882)
at
org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1042)
at
org.apache.derby.impl.drda.DRDAConnThread.exchangeServerAttributes(DRDAConnThread.java:950)
at
org.apache.derby.impl.drda.DRDAConnThread.sessionInitialState(DRDAConnThread.java:563)
at
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:219)
null
java.lang.NullPointerException
at
org.apache.derby.impl.drda.DRDAConnThread.writeSQLCAGRP(DRDAConnThread.java:5076)
at
org.apache.derby.impl.drda.DRDAConnThread.writeSQLCARD(DRDAConnThread.java:4882)
at
org.apache.derby.imp
[jira] Updated: (DERBY-292) Add a Connection VTI
[ http://issues.apache.org/jira/browse/DERBY-292?page=all ] Samuel Andrew McIntyre updated DERBY-292: - Fix Version: 10.2.0.0 (was: 10.1.0.0) > Add a Connection VTI > > > Key: DERBY-292 > URL: http://issues.apache.org/jira/browse/DERBY-292 > Project: Derby > Type: Improvement > Versions: 10.1.0.0 > Environment: N/A > Reporter: David Van Couvering > Priority: Minor > Fix For: 10.2.0.0 > > We should add a new VTI that lists all active connections and provides > details about each connection, such as owning user, the associated client > connection if there is one, etc. Linked with the other VTIs this would be a > very useful debugging tool. One of the columns should be the unique > connection string for that connection, once we have this available with > DERBY-243. -- 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-291) Debug VTIs should refer to connection string
[ http://issues.apache.org/jira/browse/DERBY-291?page=all ] Samuel Andrew McIntyre updated DERBY-291: - Fix Version: 10.2.0.0 (was: 10.1.0.0) Environment: > Debug VTIs should refer to connection string > > > Key: DERBY-291 > URL: http://issues.apache.org/jira/browse/DERBY-291 > Project: Derby > Type: Improvement > Components: Store > Versions: 10.0.2.2, 10.1.0.0 > Reporter: David Van Couvering > Priority: Minor > Fix For: 10.2.0.0 > > Now that the connection toString() provides a unique value, we should display > this in VTIs that show data that that can be scoped by connections (such as > locks, statement caches, etc.). We should add a column to these VTIs called > "connection" which displays the toString() value of the associated > connection. This will allow debuggers to correlate particular items in the > VTI with particular connections. -- 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-293) Correlate client connection with embedded connection
[ http://issues.apache.org/jira/browse/DERBY-293?page=all ] Samuel Andrew McIntyre updated DERBY-293: - Fix Version: 10.2.0.0 (was: 10.1.0.0) Description: There should be a way for someone to correlate a given embedded connection with its matching network client connection, if such a client connection exists. See http://article.gmane.org/gmane.comp.apache.db.derby.devel/3748 and http://article.gmane.org/gmane.comp.apache.db.derby.devel/3942 for some background info on how to get useful information out of the DRDA protocol stream to accomplish this. This could be done either by modifying the toString() method of an embedded connection to show its associated network client connection information or (my preference) include this information in the proposed Connection VTI (see DERBY-292). I am worried that if we use toString() for this, the output will be overly long and complicated; also, over a period of time the same embedded connection may be associated with multiple client connections, resulting in a changing toString() value for the embedded connection. This seems problematic if we are intending toString() to uniquely identify a connection for the lifetime of the connection -- this would be a good goal to have as it would enable us to do some useful debugging using the VTIs. was: There should be a way for someone to correlate a given embedded connection with its matching network client connection, if such a client connection exists. See http://article.gmane.org/gmane.comp.apache.db.derby.devel/3748 and http://article.gmane.org/gmane.comp.apache.db.derby.devel/3942 for some background info on how to get useful information out of the DRDA protocol stream to accomplish this. This could be done either by modifying the toString() method of an embedded connection to show its associated network client connection information or (my preference) include this information in the proposed Connection VTI (see DERBY-292). I am worried that if we use toString() for this, the output will be overly long and complicated; also, over a period of time the same embedded connection may be associated with multiple client connections, resulting in a changing toString() value for the embedded connection. This seems problematic if we are intending toString() to uniquely identify a connection for the lifetime of the connection -- this would be a good goal to have as it would enable us to do some useful debugging using the VTIs. > Correlate client connection with embedded connection > > > Key: DERBY-293 > URL: http://issues.apache.org/jira/browse/DERBY-293 > Project: Derby > Type: Improvement > Versions: 10.1.0.0 > Environment: N/A > Reporter: David Van Couvering > Priority: Minor > Fix For: 10.2.0.0 > > There should be a way for someone to correlate a given embedded connection > with its matching network client connection, if such a client connection > exists. > See > http://article.gmane.org/gmane.comp.apache.db.derby.devel/3748 > and > http://article.gmane.org/gmane.comp.apache.db.derby.devel/3942 > for some background info on how to get useful information out of the DRDA > protocol > stream to accomplish this. > This could be done either by modifying the toString() method of an embedded > connection to show its associated network client connection information or (my > preference) include this information in the proposed Connection VTI (see > DERBY-292). I am worried that if we use toString() for this, the output will > be overly long and complicated; also, over a period of time the same embedded > connection may be associated with multiple client connections, resulting in a > changing toString() value for the embedded connection. This seems > problematic if we are intending toString() to uniquely identify a connection > for the lifetime of the connection -- this would be a good goal to have as it > would enable us to do some useful debugging using the VTIs. -- 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] Reopened: (DERBY-205) Rename org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl
[ http://issues.apache.org/jira/browse/DERBY-205?page=all ] Samuel Andrew McIntyre reopened DERBY-205: -- Reopening to close as fixed. previous closure did not update resolved field. > Rename org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl > - > > Key: DERBY-205 > URL: http://issues.apache.org/jira/browse/DERBY-205 > Project: Derby > Type: Task > Components: Network Server > Versions: 10.1.0.0 > Reporter: Kathey Marsden > Assignee: Dag H. Wanvik > Priority: Trivial > Fix For: 10.1.0.0 > Attachments: 205b-rev1.diff, 205b-rev1.stat, 205c.diff, 205c.stat > > For historical reasons the class DB2jServerImpl, which implements the public > NetworkServerControl interface is inappropriately named. It should be > renamed to NetworkServerControlImpl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-205) Rename org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl
[ http://issues.apache.org/jira/browse/DERBY-205?page=all ] Samuel Andrew McIntyre closed DERBY-205: Resolution: Fixed > Rename org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl > - > > Key: DERBY-205 > URL: http://issues.apache.org/jira/browse/DERBY-205 > Project: Derby > Type: Task > Components: Network Server > Versions: 10.1.0.0 > Reporter: Kathey Marsden > Assignee: Dag H. Wanvik > Priority: Trivial > Fix For: 10.1.0.0 > Attachments: 205b-rev1.diff, 205b-rev1.stat, 205c.diff, 205c.stat > > For historical reasons the class DB2jServerImpl, which implements the public > NetworkServerControl interface is inappropriately named. It should be > renamed to NetworkServerControlImpl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-77) Test instructions incomplete for setting classpath.
[ http://issues.apache.org/jira/browse/DERBY-77?page=all ] Samuel Andrew McIntyre closed DERBY-77: --- Comment about locale jars added to java/testing/README.htm > Test instructions incomplete for setting classpath. > --- > > Key: DERBY-77 > URL: http://issues.apache.org/jira/browse/DERBY-77 > Project: Derby > Type: Bug > Components: Test > Versions: 10.0.2.0 > Reporter: Daniel John Debrunner > Assignee: Myrna van Lunteren > Priority: Minor > Fix For: 10.0.2.2 > > The test instructions (java/testing/README.htm) do not specify that the > locale jar files need to be in the classpath. Without them the sysinfo test > fails when running derbynetmats. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-329) Derby doesn't build properly in turkish locale
[ http://issues.apache.org/jira/browse/DERBY-329?page=all ] Samuel Andrew McIntyre closed DERBY-329: > Derby doesn't build properly in turkish locale > -- > > Key: DERBY-329 > URL: http://issues.apache.org/jira/browse/DERBY-329 > Project: Derby > Type: Bug > Components: Build tools > Versions: 10.1.0.0 > Reporter: Kathey Marsden > Priority: Minor > > In Turkish, a lower case dotted i upper cases to an upper case dotted i > which I'll call(Ui). If you build derby on a machine with a Turkish locale, > javacc will uppercase keywords like "insert" to (Ui)INSERT, instead of > INSERT. Derby in general doesn't work and you'll see many odd test failures. > Just reminded of this bit of lore with all the locale issues lately, so > filing a Jira. > Note: Derby (when built on a non-turkish machine) always uppercases in > Locale.ENGLISH, so identifiers like itable will always uppercase to ITABLE, > no matter the Locale. This consistant uppercasing allows databases to be > moved around the world without trouble but does cause culturally incorrect > uppercasing in Turkey. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-139) LOCAL as a reserved keyword does not match other databases
[ http://issues.apache.org/jira/browse/DERBY-139?page=all ] Samuel Andrew McIntyre closed DERBY-139: > LOCAL as a reserved keyword does not match other databases > -- > > Key: DERBY-139 > URL: http://issues.apache.org/jira/browse/DERBY-139 > Project: Derby > Type: Bug > Components: SQL > Versions: 10.0.2.1 > Reporter: Daniel John Debrunner > Assignee: Daniel John Debrunner > Fix For: 10.0.2.2, 10.1.0.0 > > While the SQL standard mandates LOCAL as a reserved keyword, most other > databases such as Oracle, SQL Server, MySQL and DB2 do not enforce it. > Derby enforces this and limits application migration to Derby. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-93) Cannot connect to Derby using DB2 Universal Driver
[ http://issues.apache.org/jira/browse/DERBY-93?page=all ] Samuel Andrew McIntyre closed DERBY-93: --- Duplicate of DERBY-92 > Cannot connect to Derby using DB2 Universal Driver > -- > > Key: DERBY-93 > URL: http://issues.apache.org/jira/browse/DERBY-93 > Project: Derby > Type: Bug > Components: JDBC > Versions: 10.0.2.1 > Environment: JDK 1.4.2.x > Reporter: Raj Subramani > Priority: Minor > > As per the Server & Admi guide, the Derby network server should be accesible > using the DB2 Universal Driver. > namely, > db2jcc.jar > db2jcc_license_c.jar > I have a (licensed) copy of the above driver which which I am able to connect > to Cloudscape-DB2 v5.1.2. > Howver using the same driver jars I am unable to connect to Derby, the trace > as follows: > java.sql.SQLException: No suitable driver > at java.sql.DriverManager.getConnection(DriverManager.java:532) > at java.sql.DriverManager.getConnection(DriverManager.java:171) > at db.connection.TestConnection.setUp(TestConnection.java:34) > at junit.framework.TestCase.runBare(TestCase.java:125) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186) > My connectivity properties are: > db.driver=com.ibm.db2.jcc.DB2Driver > db.url=jdbc:derby:net://localhost/:bootPassword= > db.user=demo > db.password=demo > The Derby database was created using ij and is an encrypted database. I am > able to connect to Derby with the embedded driver > db.driver=db.driver=org.apache.derby.jdbc.EmbeddedDriver > db.url=jdbc:derby:H:/rl-hibernate/db/derby_10_0_2_1/ name>;bootPassword= > db.user=demo > db.password=demo > NOTE: The use of the ";" for bootPassword in embedded mode and the use of ":" > in the network mode. This is as per the docs (and I have even tried using ";" > for the networked mode but it will still not connect). > I then went and downloaded Clodscape 10 and used > db2jcc.jar > db2jcc_license_c.jar > from this distribution. > When I used the ":" syntax for the bootpassword, as per the docs I got: > com.ibm.db2.jcc.c.SqlException: Invalid database url syntax: > jdbc:derby:net://localhost/:bootPassword= > at com.ibm.db2.jcc.DB2Driver.tokenizeURLProperties(DB2Driver.java:555) > at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:131) > at java.sql.DriverManager.getConnection(DriverManager.java:512) > at java.sql.DriverManager.getConnection(DriverManager.java:171) > at db.connection.TestConnection.setUp(TestConnection.java:34) > at junit.framework.TestCase.runBare(TestCase.java:125) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186) > However, using a ";" before bootPassword=... > results in a SUCCESSFUL connection. > I think it might be useful to state that it will work only with Cloudscape > 10.0 (or above) IBM Universal drivers. > Also given that this licensed driver may expire after some time (as per the > IBM license file), it makes it diffult to use this over a longer term. Will > there be a AF licensed network driver for Derby? -- 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-92) Cannot connect to Derby using DB2 Universal Driver
[ http://issues.apache.org/jira/browse/DERBY-92?page=all ] Samuel Andrew McIntyre updated DERBY-92: Fix Version: 10.1.0.0 Doc should be updated to reflect what version of DB2 Universal Driver will work and suggestion to move to Derby Network Client driver. > Cannot connect to Derby using DB2 Universal Driver > -- > > Key: DERBY-92 > URL: http://issues.apache.org/jira/browse/DERBY-92 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.0.2.1 > Environment: JDK 1.4.x > Reporter: Raj Subramani > Fix For: 10.1.0.0 > > As per the Server & Admi guide, the Derby network server should be accesible > using the DB2 Universal Driver. > namely, > db2jcc.jar > db2jcc_license_c.jar > I have a (licensed) copy of the above driver which which I am able to connect > to Cloudscape-DB2 v5.1.2. > Howver using the same driver jars I am unable to connect to Derby, the trace > as follows: > java.sql.SQLException: No suitable driver > at java.sql.DriverManager.getConnection(DriverManager.java:532) > at java.sql.DriverManager.getConnection(DriverManager.java:171) > at db.connection.TestConnection.setUp(TestConnection.java:34) > at junit.framework.TestCase.runBare(TestCase.java:125) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186) > My connectivity properties are: > db.driver=com.ibm.db2.jcc.DB2Driver > db.url=jdbc:derby:net://localhost/:bootPassword= > db.user=demo > db.password=demo > The Derby database was created using ij and is an encrypted database. I am > able to connect to Derby with the embedded driver > db.driver=db.driver=org.apache.derby.jdbc.EmbeddedDriver > db.url=jdbc:derby:H:/raruslibri-hibernate/db/derby_10_0_2_1/raruslibri;bootPassword= > db.user=demo > db.password=demo > NOTE: The use of the ";" for bootPassword in embedded mode and the use of ":" > in the network mode. This is as per the docs (and I have even tried using ";" > for the networked mode but it will still not connect). > I then went and downloaded Clodscape 10 and used > db2jcc.jar > db2jcc_license_c.jar > from this distribution. > When I used the ":" syntax for the bootpassword, as per the docs I got: > com.ibm.db2.jcc.c.SqlException: Invalid database url syntax: > jdbc:derby:net://localhost/:bootPassword= > at com.ibm.db2.jcc.DB2Driver.tokenizeURLProperties(DB2Driver.java:555) > at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:131) > at java.sql.DriverManager.getConnection(DriverManager.java:512) > at java.sql.DriverManager.getConnection(DriverManager.java:171) > at db.connection.TestConnection.setUp(TestConnection.java:34) > at junit.framework.TestCase.runBare(TestCase.java:125) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186) > However, using a ";" before bootPassword=... > results in a SUCCESSFUL connection. > I think it might be useful to state that it will work only with Cloudscape > 10.0 (or above) IBM Universal drivers. > Also given that this licensed driver may expire after some time (as per the > IBM license file), it makes it diffult to use this over a longer term. Will > there be a AF licensed network driver for Derby? -- 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-92) Cannot connect to Derby using DB2 Universal Driver
[ http://issues.apache.org/jira/browse/DERBY-92?page=all ] Samuel Andrew McIntyre updated DERBY-92: Component: Documentation Description: As per the Server & Admi guide, the Derby network server should be accesible using the DB2 Universal Driver. namely, db2jcc.jar db2jcc_license_c.jar I have a (licensed) copy of the above driver which which I am able to connect to Cloudscape-DB2 v5.1.2. Howver using the same driver jars I am unable to connect to Derby, the trace as follows: java.sql.SQLException: No suitable driver at java.sql.DriverManager.getConnection(DriverManager.java:532) at java.sql.DriverManager.getConnection(DriverManager.java:171) at db.connection.TestConnection.setUp(TestConnection.java:34) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186) My connectivity properties are: db.driver=com.ibm.db2.jcc.DB2Driver db.url=jdbc:derby:net://localhost/:bootPassword= db.user=demo db.password=demo The Derby database was created using ij and is an encrypted database. I am able to connect to Derby with the embedded driver db.driver=db.driver=org.apache.derby.jdbc.EmbeddedDriver db.url=jdbc:derby:H:/raruslibri-hibernate/db/derby_10_0_2_1/raruslibri;bootPassword= db.user=demo db.password=demo NOTE: The use of the ";" for bootPassword in embedded mode and the use of ":" in the network mode. This is as per the docs (and I have even tried using ";" for the networked mode but it will still not connect). I then went and downloaded Clodscape 10 and used db2jcc.jar db2jcc_license_c.jar from this distribution. When I used the ":" syntax for the bootpassword, as per the docs I got: com.ibm.db2.jcc.c.SqlException: Invalid database url syntax: jdbc:derby:net://localhost/:bootPassword= at com.ibm.db2.jcc.DB2Driver.tokenizeURLProperties(DB2Driver.java:555) at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:131) at java.sql.DriverManager.getConnection(DriverManager.java:512) at java.sql.DriverManager.getConnection(DriverManager.java:171) at db.connection.TestConnection.setUp(TestConnection.java:34) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186) However, using a ";" before bootPassword=... results in a SUCCESSFUL connection. I think it might be useful to state that it will work only with Cloudscape 10.0 (or above) IBM Universal drivers. Also given that this licensed driver may expire after some time (as per the IBM license file), it makes it diffult to use this over a longer term. Will there be a AF licensed network driver for Derby? was: As per the Server & Admi guide, the Derby network server should be accesible using the DB2 Universal Driver. namely, db2jcc.jar db2jcc_license_c.jar I have a (licensed) copy of the above driver which which I am able to connect to Cloudscape-DB2 v5.1.2. Howver using the same driver jars I am unable to connect to Derby, the trace as follows: java.sql.SQLException: No suitable driver at java.sql.DriverManager.getConnection(DriverManager.java:532) at java.sql.DriverManager.getConnection(DriverManager.java:171) at db.connection.TestConnection.setUp(TestConnection.java:34) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.r
[jira] Closed: (DERBY-305) Fix error messages in properties files to match text in documentation
[ http://issues.apache.org/jira/browse/DERBY-305?page=all ] Samuel Andrew McIntyre closed DERBY-305: Patch applied. Subsequent failures in syscat.sql fixed by Satheesh. Closing. > Fix error messages in properties files to match text in documentation > - > > Key: DERBY-305 > URL: http://issues.apache.org/jira/browse/DERBY-305 > Project: Derby > Type: Sub-task > Components: Localization > Versions: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.0.0 > Reporter: David Van Couvering > Assignee: David Van Couvering > Priority: Trivial > Fix For: 10.1.0.0 > Attachments: DERBY-305.diff, DERBY-305.status, spelling_grammar_changes.txt, > spelling_grammar_changes_with_comments.txt > > Jeff has submitted a patch that documents the SQL States and associated error > messages, but in the process modified the English text. Now the > documentation and messages are out of synch. Rather than adjust the docs to > have the old "bad" English, this subtask will adjust the message text to > match the "good" English in the documentation. > If I find any more adjustments are needed, I will note them, and the > documentation may need to go through another revision to make sure they match. > One thought for a future feature: create a script that generates the > documentation directly from the message files, or that generates the > documentation *and* messages from an independent (XML) source file, so this > is not an ongoing exercise... -- 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] Reopened: (DERBY-194) getPrecision() on TIME and TIMESTAMP is zero
[ http://issues.apache.org/jira/browse/DERBY-194?page=all ] Samuel Andrew McIntyre reopened DERBY-194: -- Reopening to fix resolved field in JIRA. > getPrecision() on TIME and TIMESTAMP is zero > > > Key: DERBY-194 > URL: http://issues.apache.org/jira/browse/DERBY-194 > Project: Derby > Type: Bug > Components: JDBC > Versions: 10.0.2.0 > Environment: Windows XP SP1 Professional > Reporter: George Baklarz > Assignee: A B > Priority: Minor > Fix For: 10.1.0.0 > Attachments: derby-194.patch, derby-194.stat > > Sun JDBC defines getPrecision() to return either the maximum length or > maximum number of digits of the column, or zero for failure (such as the > precision is unknown). > http://docs.sun.com/source/816-6105-10/apicola.htm#211083 > The DATE field returns 10 characters on a getPrecision() call so why doesn't > TIME and TIMESTAMP give a precision length equal to the display length? Just > seems inconsistent that DATE would return a precision (as well as all other > data types) and not TIME nor TIMESTAMP. -- 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-194) getPrecision() on TIME and TIMESTAMP is zero
[ http://issues.apache.org/jira/browse/DERBY-194?page=all ] Samuel Andrew McIntyre resolved DERBY-194: -- Resolution: Fixed Patch was committed with svn revision 179839. Could Army or George please verify this is fixed and close? > getPrecision() on TIME and TIMESTAMP is zero > > > Key: DERBY-194 > URL: http://issues.apache.org/jira/browse/DERBY-194 > Project: Derby > Type: Bug > Components: JDBC > Versions: 10.0.2.0 > Environment: Windows XP SP1 Professional > Reporter: George Baklarz > Assignee: A B > Priority: Minor > Fix For: 10.1.0.0 > Attachments: derby-194.patch, derby-194.stat > > Sun JDBC defines getPrecision() to return either the maximum length or > maximum number of digits of the column, or zero for failure (such as the > precision is unknown). > http://docs.sun.com/source/816-6105-10/apicola.htm#211083 > The DATE field returns 10 characters on a getPrecision() call so why doesn't > TIME and TIMESTAMP give a precision length equal to the display length? Just > seems inconsistent that DATE would return a precision (as well as all other > data types) and not TIME nor TIMESTAMP. -- 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] Reopened: (DERBY-121) Network Server reading blob/clob data size
[ http://issues.apache.org/jira/browse/DERBY-121?page=all ]
Samuel Andrew McIntyre reopened DERBY-121:
--
Reopening to fix resolved field in JIRA.
> Network Server reading blob/clob data size
> --
>
> Key: DERBY-121
> URL: http://issues.apache.org/jira/browse/DERBY-121
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.1.0.0
> Environment: The is a bit shift typo in Network Server reading clob/blob
> data size
> Reporter: Lynh Nguyen
> Assignee: A B
> Priority: Minor
> Fix For: 10.1.0.0
> Attachments: derby-121_2.stat, derby-121_3.patch
>
> in DDMReader.java
> ...
> ... readLengthAndCodePoint() ... {
> ...
> switch (numberOfExtendedLenBytes) {
> case 8:
>ddmScalarLen =
> ((buffer[pos++] & 0xff) << 64) +
> ((buffer[pos++] & 0xff) << 56) +
> ((buffer[pos++] & 0xff) << 48) +
> ((buffer[pos++] & 0xff) << 40) +
> ((buffer[pos++] & 0xff) << 32) +
> ((buffer[pos++] & 0xff) << 16) +
> ((buffer[pos++] & 0xff) << 8) +
> ((buffer[pos++] & 0xff) << 0);
> adjustSize = 12;
> break;
> case 6:
> ddmScalarLen =
> ((buffer[pos++] & 0xff) << 48) +
> ((buffer[pos++] & 0xff) << 40) +
> ((buffer[pos++] & 0xff) << 32) +
> ((buffer[pos++] & 0xff) << 16) +
> ((buffer[pos++] & 0xff) << 8) +
> ((buffer[pos++] & 0xff) << 0);
> adjustSize = 10;
> break;
> case 4:
> ddmScalarLen =
> ((buffer[pos++] & 0xff) << 32) +
> ((buffer[pos++] & 0xff) << 16) +
> ((buffer[pos++] & 0xff) << 8) +
> ((buffer[pos++] & 0xff) << 0);
> adjustSize = 8;
> break;
> ...
> The shift bits should be in order:
> 0,8,16,24
> 0,8,16,24,32,40
> 0,8,16,24,32,40,48,56
> This will only affect a lob if its length requires at least 24 bits--i.e. if
> the lob has a length of at least 2^24 bytes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-121) Network Server reading blob/clob data size
[ http://issues.apache.org/jira/browse/DERBY-121?page=all ]
Samuel Andrew McIntyre closed DERBY-121:
Resolution: Fixed
Patch was committed with svn revision 179859. Closing.
> Network Server reading blob/clob data size
> --
>
> Key: DERBY-121
> URL: http://issues.apache.org/jira/browse/DERBY-121
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.1.0.0
> Environment: The is a bit shift typo in Network Server reading clob/blob
> data size
> Reporter: Lynh Nguyen
> Assignee: A B
> Priority: Minor
> Fix For: 10.1.0.0
> Attachments: derby-121_2.stat, derby-121_3.patch
>
> in DDMReader.java
> ...
> ... readLengthAndCodePoint() ... {
> ...
> switch (numberOfExtendedLenBytes) {
> case 8:
>ddmScalarLen =
> ((buffer[pos++] & 0xff) << 64) +
> ((buffer[pos++] & 0xff) << 56) +
> ((buffer[pos++] & 0xff) << 48) +
> ((buffer[pos++] & 0xff) << 40) +
> ((buffer[pos++] & 0xff) << 32) +
> ((buffer[pos++] & 0xff) << 16) +
> ((buffer[pos++] & 0xff) << 8) +
> ((buffer[pos++] & 0xff) << 0);
> adjustSize = 12;
> break;
> case 6:
> ddmScalarLen =
> ((buffer[pos++] & 0xff) << 48) +
> ((buffer[pos++] & 0xff) << 40) +
> ((buffer[pos++] & 0xff) << 32) +
> ((buffer[pos++] & 0xff) << 16) +
> ((buffer[pos++] & 0xff) << 8) +
> ((buffer[pos++] & 0xff) << 0);
> adjustSize = 10;
> break;
> case 4:
> ddmScalarLen =
> ((buffer[pos++] & 0xff) << 32) +
> ((buffer[pos++] & 0xff) << 16) +
> ((buffer[pos++] & 0xff) << 8) +
> ((buffer[pos++] & 0xff) << 0);
> adjustSize = 8;
> break;
> ...
> The shift bits should be in order:
> 0,8,16,24
> 0,8,16,24,32,40
> 0,8,16,24,32,40,48,56
> This will only affect a lob if its length requires at least 24 bits--i.e. if
> the lob has a length of at least 2^24 bytes.
--
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-287) Return value of IDENTITY_VAL_LOCAL for different connections is not related.
[ http://issues.apache.org/jira/browse/DERBY-287?page=all ] Samuel Andrew McIntyre updated DERBY-287: - Component: Documentation Fix Version: 10.1.0.0 Description: The current IDENTITY_VAL_LOCAL documentation (http://incubator.apache.org/derby/docs/ref/ref-single.html#rrefidentityvallocal) is unclear if the IDENTITY_VAL_LOCAL function returns the most recently assigned value for an identity column, for a connection/transaction/database and it needs to be fixed to say that it is for a connection. The first line in the current doc is "The IDENTITY_VAL_LOCAL function is a non-deterministic function that returns the most recently assigned value for an identity column, where the assignment occurred as a result of a single row INSERT statement using a VALUES clause. " It should read as "The IDENTITY_VAL_LOCAL function is a non-deterministic function that, for a connection, returns the most recently assigned value for an identity column, where the assignment occurred as a result of a single row INSERT statement using a VALUES clause." There is another line on the same page which reads "The value returned by the IDENTITY_VAL_LOCAL function is the value assigned to the identity column of the table identified in the most recent single row INSERT statement." This needs to be slightly modified to say "The value returned by the IDENTITY_VAL_LOCAL function, for a connection, is the value assigned to the identity column of the table identified in the most recent single row INSERT statement." was: The current IDENTITY_VAL_LOCAL documentation (http://incubator.apache.org/derby/docs/ref/ref-single.html#rrefidentityvallocal) is unclear if the IDENTITY_VAL_LOCAL function returns the most recently assigned value for an identity column, for a connection/transaction/database and it needs to be fixed to say that it is for a connection. The first line in the current doc is "The IDENTITY_VAL_LOCAL function is a non-deterministic function that returns the most recently assigned value for an identity column, where the assignment occurred as a result of a single row INSERT statement using a VALUES clause. " It should read as "The IDENTITY_VAL_LOCAL function is a non-deterministic function that, for a connection, returns the most recently assigned value for an identity column, where the assignment occurred as a result of a single row INSERT statement using a VALUES clause." There is another line on the same page which reads "The value returned by the IDENTITY_VAL_LOCAL function is the value assigned to the identity column of the table identified in the most recent single row INSERT statement." This needs to be slightly modified to say "The value returned by the IDENTITY_VAL_LOCAL function, for a connection, is the value assigned to the identity column of the table identified in the most recent single row INSERT statement." Version: 10.1.0.0 Environment: > Return value of IDENTITY_VAL_LOCAL for different connections is not related. > > > Key: DERBY-287 > URL: http://issues.apache.org/jira/browse/DERBY-287 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.1.0.0 > Reporter: Mamta A. Satoor > Fix For: 10.1.0.0 > Attachments: derby287.zip > > The current IDENTITY_VAL_LOCAL documentation > (http://incubator.apache.org/derby/docs/ref/ref-single.html#rrefidentityvallocal) > is unclear if the IDENTITY_VAL_LOCAL function returns the most recently > assigned value for an identity column, for a connection/transaction/database > and it needs to be fixed to say that it is for a connection. > The first line in the current doc is "The IDENTITY_VAL_LOCAL function is a > non-deterministic function that returns the most recently assigned value for > an identity column, where the assignment occurred as a result of a single row > INSERT statement using a VALUES clause. " It should read as "The > IDENTITY_VAL_LOCAL function is a non-deterministic function that, for a > connection, returns the most recently assigned value for an identity column, > where the assignment occurred as a result of a single row INSERT statement > using a VALUES clause." > There is another line on the same page which reads "The value returned by the > IDENTITY_VAL_LOCAL function is the value assigned to the identity column of > the table identified in the most recent single row INSERT statement." This > needs to be slightly modified to say "The value returned by the > IDENTITY_VAL_LOCAL function, for a connection, is the value assigned to the > identity column of the table identified in the most recent single row INSERT > statement." -- 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/Admin
[jira] Closed: (DERBY-91) XA .sql tests fail with jar files
[ http://issues.apache.org/jira/browse/DERBY-91?page=all ] Samuel Andrew McIntyre closed DERBY-91: --- > XA .sql tests fail with jar files > - > > Key: DERBY-91 > URL: http://issues.apache.org/jira/browse/DERBY-91 > Project: Derby > Type: Bug > Components: Tools > Versions: 10.0.2.1 > Reporter: Daniel John Debrunner > Assignee: Daniel John Debrunner > Fix For: 10.0.2.2, 10.1.0.0 > > A handful of SQL tests such as jdbcapi/xaAnotherTest.sql fail when run > against the jar files. > The output contains lines like > JAVA ERROR: java.lang.NullPointerException > for the ij XA testing commands like xa_datasource > Looks like the derbytools.jar is missing the class > org.apache.derby.impl.tools.ij.xaHelper > since it is loaded indirectly. -- 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-55) Derby documentation mentions script and batch files that don't exist
[ http://nagoya.apache.org/jira/browse/DERBY-55?page=history ] Samuel Andrew McIntyre reassigned DERBY-55: --- Assign To: Samuel Andrew McIntyre > Derby documentation mentions script and batch files that don't exist > > > Key: DERBY-55 > URL: http://nagoya.apache.org/jira/browse/DERBY-55 > Project: Derby > Type: Bug > Components: Documentation > Reporter: John Sisson > Assignee: Samuel Andrew McIntyre > > The Derby documentation > http://incubator.apache.org/derby/manuals/admin/hubprnt22.html says: > Derby provides script files for setting the class path, located in > $DERBY_INSTALL\frameworks\NetworkServer\bin. > setNetworkClientCP.bat (Windows) > setNetworkClientCP.ksh (UNIX) > setNetworkServerCP.bat (Windows) > setNetworkServerCP.ksh (UNIX) > These files do not exist in Derby. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-55) Derby documentation mentions script and batch files that don't exist
[ http://nagoya.apache.org/jira/browse/DERBY-55?page=comments#action_55058 ] Samuel Andrew McIntyre commented on DERBY-55: - There are clearly two ways to solve this: remove the references in the docs to the scripts, or have the scripts contributed to Apache. Since the latter is preferable, I will work on having the scripts contributed to Apache. > Derby documentation mentions script and batch files that don't exist > > > Key: DERBY-55 > URL: http://nagoya.apache.org/jira/browse/DERBY-55 > Project: Derby > Type: Bug > Components: Documentation > Reporter: John Sisson > Assignee: Samuel Andrew McIntyre > > The Derby documentation > http://incubator.apache.org/derby/manuals/admin/hubprnt22.html says: > Derby provides script files for setting the class path, located in > $DERBY_INSTALL\frameworks\NetworkServer\bin. > setNetworkClientCP.bat (Windows) > setNetworkClientCP.ksh (UNIX) > setNetworkServerCP.bat (Windows) > setNetworkServerCP.ksh (UNIX) > These files do not exist in Derby. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-2) Can't compile Derby on OS X
[ http://nagoya.apache.org/jira/browse/DERBY-2?page=history ] Samuel Andrew McIntyre closed DERBY-2: -- Resolution: Fixed Fix Version: 10.0.2.0 Closing, as the problem appears to be resolved. > Can't compile Derby on OS X > --- > > Key: DERBY-2 > URL: http://nagoya.apache.org/jira/browse/DERBY-2 > Project: Derby > Type: Bug > Environment: OS X 10.3.5, Java 1.4.2_05, Dual G5 > Reporter: Tom Santos > Fix For: 10.0.2.0 > > I went through all the steps in BUILDING.txt (including downloading all of > the jars except osgi.jar) and have tried to build using both the default > compiler and jikes. I've included both outputs in this message. > My ant.properties file: > j14lib=/System/Library/Frameworks/JavaVM.framework/Home/lib > j13lib=/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib > build.compiler=jikes > Output when using Jikes (note: I get tons of compile errors that all look > like the one I've provided, all while compiling compile_iapi_jdbc_jdbc2): > . > . > . > [echo] Ant environment: > [echo] Base Directory: /Users/tom/dev/java/derby > [echo] Build output: /Users/tom/dev/java/derby/classes > [echo] Compiler: jikes > [echo] Sane = true > [echo] Proceed = no > . > . > . > compile_iapi_jdbc_jdbc2: > [javac] Compiling 3 source files to /Users/tom/dev/java/derby/classes > [javac] Found 2 semantic errors compiling > "BrokeredPreparedStatement.java": > [javac] 24. public class BrokeredPreparedStatement extends > BrokeredStatement > [javac] ^---^ > [javac] *** Semantic Error: The abstract method "void setURL(int $1, > java.net.URL $2) throws java.sql.SQLException;", inherited from type > "java.sql.PreparedStatement", is not implemented in the non-abstract class > "org.apache.derby.iapi.jdbc.BrokeredPreparedStatement". > . > . > . > BUILD FAILED > /Users/tom/dev/java/derby/build.xml:137: The following error occurred while > executing this line: > /Users/tom/dev/java/derby/java/engine/build.xml:43: The following error > occurred while executing this line: > /Users/tom/dev/java/derby/java/engine/org/apache/derby/iapi/build.xml:46: The > following error occurred while executing this line: > /Users/tom/dev/java/derby/java/engine/org/apache/derby/iapi/jdbc/build.xml:64: > Compile failed; see the compiler error output for details. > Output when using the default compiler: > . > . > . > [echo] Ant environment: > [echo] Base Directory: /Users/tom/dev/java/derby > [echo] Build output: /Users/tom/dev/java/derby/classes > [echo] Compiler: modern > [echo] Sane = true > [echo] Proceed = no > . > . > . > compile_iapi_jdbc_jdbc2: > [javac] Compiling 3 source files to /Users/tom/dev/java/derby/classes > [javac] Fatal Error: Unable to locate package java.lang in classpath or > bootclasspath > BUILD FAILED > /Users/tom/dev/java/derby/build.xml:137: The following error occurred while > executing this line: > /Users/tom/dev/java/derby/java/engine/build.xml:43: The following error > occurred while executing this line: > /Users/tom/dev/java/derby/java/engine/org/apache/derby/iapi/build.xml:46: The > following error occurred while executing this line: > /Users/tom/dev/java/derby/java/engine/org/apache/derby/iapi/jdbc/build.xml:64: > Compile failed; see the compiler error output for details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-56) NsSample sample program refered to in documentation is missing
[ http://nagoya.apache.org/jira/browse/DERBY-56?page=history ] Samuel Andrew McIntyre reassigned DERBY-56: --- Assign To: Samuel Andrew McIntyre > NsSample sample program refered to in documentation is missing > -- > > Key: DERBY-56 > URL: http://nagoya.apache.org/jira/browse/DERBY-56 > Project: Derby > Type: Bug > Components: Documentation > Reporter: John Sisson > Assignee: Samuel Andrew McIntyre > > See the following pages for references to the NsSample program. > http://incubator.apache.org/derby/manuals/admin/hubprnt34.html > http://incubator.apache.org/derby/manuals/admin/hubprnt35.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
