[jira] [Commented] (DERBY-4939) Enable istat daemon and tests
[ https://issues.apache.org/jira/browse/DERBY-4939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009602#comment-13009602 ] Andrew McIntyre commented on DERBY-4939: > Enable istat daemon and tests > - > > Key: DERBY-4939 > URL: https://issues.apache.org/jira/browse/DERBY-4939 > Project: Derby > Issue Type: Sub-task > Components: SQL >Affects Versions: 10.8.0.0 >Reporter: Kristian Waagan >Assignee: Kristian Waagan > Fix For: 10.8.0.0 > > Attachments: derby-4939-1a-enable_istat.diff, releaseNote.html, > releaseNote.html, releaseNote.html, releaseNote.html > > > Enable automatic updates and creations of index cardinality statistics, and > wire the tests into the regression suite. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-590) How to integrate Derby with Lucene API?
[ https://issues.apache.org/jira/browse/DERBY-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre updated DERBY-590: -- Attachment: lucene_demo.diff Attaching rough draft of patch for optional tool to create, update, and query Lucene indexes in Derby. > How to integrate Derby with Lucene API? > --- > > Key: DERBY-590 > URL: https://issues.apache.org/jira/browse/DERBY-590 > Project: Derby > Issue Type: Improvement > Components: Documentation, SQL >Reporter: Abhijeet Mahesh > Labels: derby_triage10_11 > Attachments: lucene_demo.diff > > > In order to use derby with lucene API what should be the steps to be taken? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DERBY-590) How to integrate Derby with Lucene API?
[ https://issues.apache.org/jira/browse/DERBY-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799278#comment-13799278 ] Andrew McIntyre commented on DERBY-590: --- Attached patch sent to mailing list. ij script that can be used to demonstrate the patch's features is here: http://people.apache.org/~fuzzylogic/lucene_titles.sql although this contains what might be considered copyrighted data, so this will be removed and I'll try to replace it with a more appropriate dataset and include it directly in the patch when I can find one that works well. As I said, very rough, I basically just got it working. :-) Some things don't work (the rankCutoff parameter in the query function doesn't do anything), it needs formatting, comments, javadoc, tests, etc. etc. Regarding Rick's comment on the dev list about further integration via the parser, it seems like it would be pretty straightforward to go from the procedure call in this patch to wiring the index creation into the sql grammar by using the MySQL-ish: CREATE FULLTEXT INDEX INDEX_NAME ON SCHEMA.TABLE (COLUMN) > How to integrate Derby with Lucene API? > --- > > Key: DERBY-590 > URL: https://issues.apache.org/jira/browse/DERBY-590 > Project: Derby > Issue Type: Improvement > Components: Documentation, SQL >Reporter: Abhijeet Mahesh > Labels: derby_triage10_11 > Attachments: lucene_demo.diff > > > In order to use derby with lucene API what should be the steps to be taken? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DERBY-590) How to integrate Derby with Lucene API?
[ https://issues.apache.org/jira/browse/DERBY-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13801296#comment-13801296 ] Andrew McIntyre commented on DERBY-590: --- Looks like I grabbed some extra text when copying things over to my Apache account. indexDatabase() was from an earlier experiment and can be ignored. I've removed it from lucene_titles.sql. for iii - I think SQL exceptions in case of missing / corrupted indexes will do for now, as if another index were missing or corrupted. My original idea for organizing the indexes was to keep the indexes in a per-db 'lucene' directory at the same level as 'log' and 'seg0', then in subdirectories named 'schema_table_column,' so it would be obvious looking in the db's lucene directory which columns were indexed. That's not what we have here, which is a system-wide lucene directory instead of a per-db directory. I'll try to get a per-db dir for the next patch, if I can pry the db directory out of the monitor/store. With a per-db lucene dir, if the database directory is backed up, the lucene indexes would be be backed up along with also. I also thought about having a drop lucene index procedure, but figured for the moment leaving that to the user/developer, since it involves deleting directories in the filesystem ii/iv - comments/javadoc/tests to come in the next patch. Main problem right now is finding time, and scraping/generating a decently large set of test data that is ok to reuse. The lucene project probably has some, though. as for i - feel free to let me know any particulars, or you can wait for the next patch. it will probably be a few days. > How to integrate Derby with Lucene API? > --- > > Key: DERBY-590 > URL: https://issues.apache.org/jira/browse/DERBY-590 > Project: Derby > Issue Type: Improvement > Components: Documentation, SQL >Reporter: Abhijeet Mahesh > Labels: derby_triage10_11 > Attachments: lucene_demo.diff > > > In order to use derby with lucene API what should be the steps to be taken? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (DERBY-590) How to integrate Derby with Lucene API?
[ https://issues.apache.org/jira/browse/DERBY-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre updated DERBY-590: -- Attachment: lucene_demo_2.diff > How to integrate Derby with Lucene API? > --- > > Key: DERBY-590 > URL: https://issues.apache.org/jira/browse/DERBY-590 > Project: Derby > Issue Type: Improvement > Components: Documentation, SQL >Reporter: Abhijeet Mahesh > Labels: derby_triage10_11 > Attachments: lucene_demo_2.diff, lucene_demo.diff > > > In order to use derby with lucene API what should be the steps to be taken? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DERBY-590) How to integrate Derby with Lucene API?
[ https://issues.apache.org/jira/browse/DERBY-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13804722#comment-13804722 ] Andrew McIntyre commented on DERBY-590: --- Attached a second patch which now includes javadoc, tightens up the comments, and includes a starter set of tests for the functionality. Still need to dig up a fuller set of data, I'll try to get to that maybe this weekend. In the meantime, I made some up with some things I had on my bookshelf and the schema from before. - indexTable() in lucene_titles.sql was also from a previous experiment, I had changed it to luceneIndex() for the patch in lucene_demo.diff, but for the updated patch in lucene_demo_2.diff, I decided to standardize the naming with createIndex, updateIndex, dropIndex, etc. -The indexes are now hopefully all located in the database directory, per-db, and I liked the suggestion for listing out the indexes, so also included is another function/VTI for listing out the Lucene indexes for the current database. -More tests and documentation to come. At some point I'll try to get the rankCutoff function working as well. > How to integrate Derby with Lucene API? > --- > > Key: DERBY-590 > URL: https://issues.apache.org/jira/browse/DERBY-590 > Project: Derby > Issue Type: Improvement > Components: Documentation, SQL >Reporter: Abhijeet Mahesh > Labels: derby_triage10_11 > Attachments: lucene_demo_2.diff, lucene_demo.diff > > > In order to use derby with lucene API what should be the steps to be taken? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (DERBY-590) How to integrate Derby with Lucene API?
[ https://issues.apache.org/jira/browse/DERBY-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre updated DERBY-590: -- Attachment: (was: lucene_demo_2.diff) > How to integrate Derby with Lucene API? > --- > > Key: DERBY-590 > URL: https://issues.apache.org/jira/browse/DERBY-590 > Project: Derby > Issue Type: Improvement > Components: Documentation, SQL >Reporter: Abhijeet Mahesh > Labels: derby_triage10_11 > Attachments: lucene_demo.diff > > > In order to use derby with lucene API what should be the steps to be taken? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (DERBY-590) How to integrate Derby with Lucene API?
[ https://issues.apache.org/jira/browse/DERBY-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre updated DERBY-590: -- Attachment: lucene_demo_2.diff Reattaching lucene_demo_2.diff, this time with the rankCutoff part of the query function working and additional tests for same. > How to integrate Derby with Lucene API? > --- > > Key: DERBY-590 > URL: https://issues.apache.org/jira/browse/DERBY-590 > Project: Derby > Issue Type: Improvement > Components: Documentation, SQL >Reporter: Abhijeet Mahesh > Labels: derby_triage10_11 > Attachments: lucene_demo_2.diff, lucene_demo.diff > > > In order to use derby with lucene API what should be the steps to be taken? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] Commented: (DERBY-3322) Server guide refers to phantom property in template policy file for the Network Server
[
https://issues.apache.org/jira/browse/DERBY-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577308#action_12577308
]
Andrew McIntyre commented on DERBY-3322:
Dyre, I'm still publishing my nightly doc build out to the docs/dev area of the
website. Please let me know if what's up there is stale and I'll check on the
copying process.
> Server guide refers to phantom property in template policy file for the
> Network Server
> --
>
> Key: DERBY-3322
> URL: https://issues.apache.org/jira/browse/DERBY-3322
> Project: Derby
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 10.3.1.4, 10.3.2.1
> Environment: N/A
>Reporter: John H. Embretsen
>Assignee: John H. Embretsen
>Priority: Trivial
> Fix For: 10.4.0.0
>
> Attachments: d3322v01.diff, tadminnetservcustom.html
>
>
> The Server and Administration guide contains a section about customizing the
> Network Server's security policy, based on the template policy:
> http://db.apache.org/derby/docs/dev/adminguide/tadminnetservcustom.html
> This section mentions that the variable ${derby.security.host} should be
> replaced with a suitable value.
>
> However, the template policy, at /demo/templates/server.policy (released
> binaries) or java/drda/org/apache/derby/drda/template.policy (SVN codeline),
> does not refer to any variable or property called ${derby.security.host}.
> Instead, the policy file specifies the wildcard address, with appropriate
> comments:
>
> // Accept connections from any host. Derby is listening to the host
> // interface specified via the -h option to "NetworkServerControl
> // start" on the command line, via the address parameter to the
> // org.apache.derby.drda.NetworkServerControl constructor in the API
> // or via the property derby.drda.host; the default is localhost.
> // You may want to restrict allowed hosts, e.g. to hosts in a specific
> // subdomain, e.g. "*.acme.com".
> permission java.net.SocketPermission "*", "accept";
>
> See also
> http://www.nabble.com/Customizing-the-Network-Server%27s-security-policy-%28docs-vs.-reality%29-td14841290.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3322) Server guide refers to phantom property in template policy file for the Network Server
[
https://issues.apache.org/jira/browse/DERBY-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577734#action_12577734
]
Andrew McIntyre commented on DERBY-3322:
hi John, I'll take a look tomorrow and see if I can figure out why my automated
copy is not updating the files. The copy process itself is not reporting any
errors, but maybe there are permissions problems on people.apache.org that are
preventing the files from being updated.
> Server guide refers to phantom property in template policy file for the
> Network Server
> --
>
> Key: DERBY-3322
> URL: https://issues.apache.org/jira/browse/DERBY-3322
> Project: Derby
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 10.3.1.4, 10.3.2.1
> Environment: N/A
>Reporter: John H. Embretsen
>Assignee: John H. Embretsen
>Priority: Trivial
> Fix For: 10.4.0.0
>
> Attachments: d3322v01.diff, tadminnetservcustom.html
>
>
> The Server and Administration guide contains a section about customizing the
> Network Server's security policy, based on the template policy:
> http://db.apache.org/derby/docs/dev/adminguide/tadminnetservcustom.html
> This section mentions that the variable ${derby.security.host} should be
> replaced with a suitable value.
>
> However, the template policy, at /demo/templates/server.policy (released
> binaries) or java/drda/org/apache/derby/drda/template.policy (SVN codeline),
> does not refer to any variable or property called ${derby.security.host}.
> Instead, the policy file specifies the wildcard address, with appropriate
> comments:
>
> // Accept connections from any host. Derby is listening to the host
> // interface specified via the -h option to "NetworkServerControl
> // start" on the command line, via the address parameter to the
> // org.apache.derby.drda.NetworkServerControl constructor in the API
> // or via the property derby.drda.host; the default is localhost.
> // You may want to restrict allowed hosts, e.g. to hosts in a specific
> // subdomain, e.g. "*.acme.com".
> permission java.net.SocketPermission "*", "accept";
>
> See also
> http://www.nabble.com/Customizing-the-Network-Server%27s-security-policy-%28docs-vs.-reality%29-td14841290.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (DERBY-3572) directory error in the file "java/testing/README.htm"
[ https://issues.apache.org/jira/browse/DERBY-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre reopened DERBY-3572: Assignee: Junjie Peng Reopening, as the proposed fix has not been committed. Assigning to Junjie Peng, who has attached a proposed fix for this issue. > directory error in the file "java/testing/README.htm" > - > > Key: DERBY-3572 > URL: https://issues.apache.org/jira/browse/DERBY-3572 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.3.2.1 >Reporter: Junjie Peng >Assignee: Junjie Peng >Priority: Minor > Attachments: README.htm > > Original Estimate: 0.02h > Remaining Estimate: 0.02h > > In the document "db-derby-10.3.2.1-src/java/testing/Readme.txt", there is a > bug. In section "2. QuickStart 2.1 running tests", It says: > > " > To run a suite: > syntax: > java -D > org.apache.derbyTesting.functionTests.harness.RunSuite > where > * > are test specific properties, such as 'verbose' for > the RunSuite class. > * > is one of the suites under org/apache/derbyTesting/suites > for example for running the suite derbylang: >java -Dverbose=true org.apache.derbyTesting.functionTests.harness.RunSuite > derbylang > " >However, the sentence " is one of the suites under > org/apache/derbyTesting/suites > " should be replaced with " is one of the suites under > org/apache/derbyTesting/functionTests/suites". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3659) revive tests with ldap references to be runnable as junit tests
[ https://issues.apache.org/jira/browse/DERBY-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593904#action_12593904 ] Andrew McIntyre commented on DERBY-3659: Surely the Apache Directory project has a test server running somewhere. Maybe check on their dev and/or user list if they have a test server that they're ok having multiple automated Derby test clients hitting at all hours of the day. > revive tests with ldap references to be runnable as junit tests > --- > > Key: DERBY-3659 > URL: https://issues.apache.org/jira/browse/DERBY-3659 > Project: Derby > Issue Type: Test > Components: Test >Reporter: Myrna van Lunteren >Priority: Minor > > During initial contribution some tests were created with references to ldap > security mechanism. > However, because we don't have ourselves setup for a public ldap server, > these tests have fallen by the wayside. > Specifically, there is still a secureUsers .out file in functionTests.master > that uses some ldap references, and there's the -not running - > jdbcapi.xaJNDI.java. > These should be turned into junit tests out of these that take properties for > the ldapserver, port, and dnString. > If we ever get a Zone, with an ldap server, or somehow get access to another > public ldap server, then we can modify the tests to have the correct > references. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2720) remove dead code associated with unsupported National Char implementation
[ https://issues.apache.org/jira/browse/DERBY-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre updated DERBY-2720: --- Fix Version/s: (was: 10.4.1.3) (was: 10.3.2.2) 10.3.3.1 > remove dead code associated with unsupported National Char implementation > - > > Key: DERBY-2720 > URL: https://issues.apache.org/jira/browse/DERBY-2720 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Mike Matrigali >Assignee: Mamta A. Satoor >Priority: Minor > Fix For: 10.3.3.1 > > > Derby still has some untested, unused code relating to a non-standard > implementation of a Nationa Char type. The current code can be removed. > I believe the interesting functionality associated with this is now provided > by DERBY-1478 (territory based collation) . If Derby ever implements a > National Char type it should do so differently than the existing code, > collation should not be tied to the National Char type. > I believe a future National char type might have to maintain a separate type > id for compatibility with jdbc interface, but actual implmentation should be > the same code as the char types. Collating of the the national char type > should be supported in exactly same way as regular char types. > If anyone is really intested in the national char code, it's history will > always be available in svn, and a consistent version is available by looking > at 10.0, 10.1, > and 10.2 codelines. I would propose any removal of code only take place in > trunk and not be backported to a released codeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3037) Language ResultSet.finish() is called even when the ResultSet is going to be re-used.
[ https://issues.apache.org/jira/browse/DERBY-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre updated DERBY-3037: --- Fix Version/s: (was: 10.4.1.3) (was: 10.3.2.2) 10.3.3.1 > Language ResultSet.finish() is called even when the ResultSet is going to be > re-used. > - > > Key: DERBY-3037 > URL: https://issues.apache.org/jira/browse/DERBY-3037 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.4.1.3 >Reporter: Daniel John Debrunner >Assignee: Mamta A. Satoor > Fix For: 10.3.3.1 > > Attachments: DERBY3037_patch_not_ready_for_commit_v2_diff.txt, > DERBY3037_patch_not_ready_for_commit_v2_stat.txt, > Derby_3037_AlterTableConstantActionChanges_v1_diff.txt, > Derby_3037_AlterTableConstantActionChanges_v1_stat.txt, DERBY_3304_Repro.java > > > DERBY-827 (correctly) changed the lifetime of the language ResultSet tree to > be the lifetime of the activation, but did not fix up the correct calls to > ResultSet.close() and ResultSet.finish(). > A language ResultSet's lifetime should be driven by the activation, so > activation.close() should call finish() on its ResultSet. > EmbedResultSet should call close on its language ResultSet (theResults field) > when the JDBC ResultSet is closed, it should not be calling finish() on its > ResultSet. > See comments in DERBY-827 for some more details and issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2457) Use of column aliases in group by / having clauses can cause queries to fail
[ https://issues.apache.org/jira/browse/DERBY-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595109#action_12595109 ] Andrew McIntyre commented on DERBY-2457: See also the discussion in DERBY-84 and DERBY-127. This bug could be potentially be considered a dup of DERBY-84. > Use of column aliases in group by / having clauses can cause queries to fail > > > Key: DERBY-2457 > URL: https://issues.apache.org/jira/browse/DERBY-2457 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.3.1.4 >Reporter: Andrew McIntyre >Assignee: Bryan Pendleton >Priority: Minor > Attachments: 1624_repro.sql > > > Some use of column aliases in group by / having clauses can cause queries to > fail with error 42X04. The queries can sometimes be made to work by also > aliasing the table or rewriting the query to use a subselect. Attached is a > simple sql script which reproduces the issue, originally found as part of > DERBY-1624. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3730) Bundle-SymbolicName: needed in Derby manifest for OSGi 4 environment
[ https://issues.apache.org/jira/browse/DERBY-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre updated DERBY-3730: --- Attachment: derby-3730.diff Attaching a patch which sets Bundle-SymbolicName. Is this all that is needed for this issue? > Bundle-SymbolicName: needed in Derby manifest for OSGi 4 environment > > > Key: DERBY-3730 > URL: https://issues.apache.org/jira/browse/DERBY-3730 > Project: Derby > Issue Type: Bug >Affects Versions: 10.2.2.0, 10.3.3.0, 10.4.1.3 >Reporter: Stan Bradbury > Attachments: derby-3730.diff > > > The manifest does not have a Bundle Symbolic Name. This causes some tools not > to recognize it as an OSGi bundle and some things don't work nicely without > the symbolic name. > Add Bundle-SymbolicName: derby to the manifest. > NOTE: this issue will address issue #1 of the multi-issue bug: DERBY-1945 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4140) Derby 10.3.3.0 not in Maven repository
[ https://issues.apache.org/jira/browse/DERBY-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre updated DERBY-4140: --- Fix Version/s: (was: 10.2.3.0) 10.3.3.0 correct fix version > Derby 10.3.3.0 not in Maven repository > -- > > Key: DERBY-4140 > URL: https://issues.apache.org/jira/browse/DERBY-4140 > Project: Derby > Issue Type: Bug >Affects Versions: 10.3.3.0 >Reporter: Brandon Smith >Assignee: Andrew McIntyre > Fix For: 10.3.3.0 > > > The stable build for the 10.3.x stream, 10.3.3.0, is not in the Maven > repository ecosystem. Since both 10.3.2.1 and 10.3.1.4 contain bugs that > affect data corruption, they are no longer available at db.apache.org/derby > and it is recommended to update to 10.3.3.0, which at present is not possible > using a public Maven repository. > http://repo1.maven.org/maven2/org/apache/derby/derby/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-4140) Derby 10.3.3.0 not in Maven repository
[ https://issues.apache.org/jira/browse/DERBY-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre resolved DERBY-4140. Resolution: Fixed Fix Version/s: 10.2.3.0 I added Derby 10.3.3.0 to the Apache Maven 1 repository. As far as I am concerned, this resolves the issue. If someone wants to contribute the necessary files and instructions to deploy to a Maven 2 repository, that can be tracked in a separate issue. Marking resolved. > Derby 10.3.3.0 not in Maven repository > -- > > Key: DERBY-4140 > URL: https://issues.apache.org/jira/browse/DERBY-4140 > Project: Derby > Issue Type: Bug >Affects Versions: 10.3.3.0 >Reporter: Brandon Smith >Assignee: Andrew McIntyre > Fix For: 10.2.3.0 > > > The stable build for the 10.3.x stream, 10.3.3.0, is not in the Maven > repository ecosystem. Since both 10.3.2.1 and 10.3.1.4 contain bugs that > affect data corruption, they are no longer available at db.apache.org/derby > and it is recommended to update to 10.3.3.0, which at present is not possible > using a public Maven repository. > http://repo1.maven.org/maven2/org/apache/derby/derby/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4220) Derby 10.5.1.1 is not available in the maven repositories
[ https://issues.apache.org/jira/browse/DERBY-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12709985#action_12709985 ] Andrew McIntyre commented on DERBY-4220: Permissions on 10.3.3.0 jars now also fixed. > Derby 10.5.1.1 is not available in the maven repositories > - > > Key: DERBY-4220 > URL: https://issues.apache.org/jira/browse/DERBY-4220 > Project: Derby > Issue Type: Bug >Affects Versions: 10.5.1.1 >Reporter: H.-Dirk Schmitt >Priority: Minor > > I'm not able to find the artifacts via mvn. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3944) CHECK constraints involving user-coded functions may return different results depending on who performs the trigging INSERT/UPDATE
[ https://issues.apache.org/jira/browse/DERBY-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646683#action_12646683 ] Andrew McIntyre commented on DERBY-3944: Did a quick check as I happened to have several different DBs handy. DB2 v9 only allows user defined functions that can be expressed in SQL, and IDS 11, Oracle 9, and MS SQL Server 2005 all disallow user-defined functions in check constraints. > CHECK constraints involving user-coded functions may return different results > depending on who performs the trigging INSERT/UPDATE > -- > > Key: DERBY-3944 > URL: https://issues.apache.org/jira/browse/DERBY-3944 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.5.0.0 >Reporter: Rick Hillegas > > When compiling a CHECK constraint on behalf of an INSERT/UPDATE statement, > Derby uses the current schema in order to resolve unqualified function names > which appear in the CHECK constraint. This means that the CHECK constraint > may evaluate true for some users, false for others, and for others the CHECK > constraint may raise an error saying that Derby can't resolve the function > reference. This behavior violates the "retrospective determinacy" of CHECK > constraints as specified by part 2 of the ANSI/ISO standard: > 1) section 11.9 (), syntax rule 5 > 2) same section, general rule 1 > 3) section 11.6 (), general rule 3 > 4) section 4.16 (Determinism) > For more discussion, please see this email thread: > http://www.nabble.com/Problem-with-CHECK-constraints-td20445344.html#a20445344 > The following script demonstrates this problem: > connect > 'jdbc:derby:derbyauth;create=true;user=test_dbo;password=test_dbopassword' as > test_dbo_conn; > drop table t_bp_2; > drop function f_fp_minus; > create function f_fp_minus > ( > a int > ) > returns int > language java > deterministic > parameter style java > no sql > external name > 'org.apache.derbyTesting.functionTests.tests.lang.GeneratedColumnsTest.minus' > ; > create table t_bp_2( a int, constraint t_bp_2_check check ( f_fp_minus( a ) < > 0 ) ); > grant insert on t_bp_2 to public; > insert into test_dbo.t_bp_2( a ) values ( 100 ); > connect 'jdbc:derby:derbyauth;create=true;user=janet;password=janetpassword' > as janet_conn; > insert into test_dbo.t_bp_2( a ) values ( 100 ); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3944) CHECK constraints involving user-coded functions may return different results depending on who performs the trigging INSERT/UPDATE
[ https://issues.apache.org/jira/browse/DERBY-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646728#action_12646728 ] Andrew McIntyre commented on DERBY-3944: DB2 assigns it to the current schema. In the default case, this is the schema corresponding to the user id. FWIW, the copy of the SQL standard I have says in sec. 5.4, 4a that the unqualified identifiers should resolve to the current schema for the SQL session and the definition of routine invocation has no language to contradict that and simply says that it's a qualified identifier. While it seems logical to me that an unqualified function name in a check constraint would resolve to the schema containing the table with the constraint, it could be useful to have the function resolve to different functions in each schema, e.g. allowing different users to insert data into a table with different constraints. > CHECK constraints involving user-coded functions may return different results > depending on who performs the trigging INSERT/UPDATE > -- > > Key: DERBY-3944 > URL: https://issues.apache.org/jira/browse/DERBY-3944 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.5.0.0 >Reporter: Rick Hillegas > > When compiling a CHECK constraint on behalf of an INSERT/UPDATE statement, > Derby uses the current schema in order to resolve unqualified function names > which appear in the CHECK constraint. This means that the CHECK constraint > may evaluate true for some users, false for others, and for others the CHECK > constraint may raise an error saying that Derby can't resolve the function > reference. This behavior violates the "retrospective determinacy" of CHECK > constraints as specified by part 2 of the ANSI/ISO standard: > 1) section 11.9 (), syntax rule 5 > 2) same section, general rule 1 > 3) section 11.6 (), general rule 3 > 4) section 4.16 (Determinism) > For more discussion, please see this email thread: > http://www.nabble.com/Problem-with-CHECK-constraints-td20445344.html#a20445344 > The following script demonstrates this problem: > connect > 'jdbc:derby:derbyauth;create=true;user=test_dbo;password=test_dbopassword' as > test_dbo_conn; > drop table t_bp_2; > drop function f_fp_minus; > create function f_fp_minus > ( > a int > ) > returns int > language java > deterministic > parameter style java > no sql > external name > 'org.apache.derbyTesting.functionTests.tests.lang.GeneratedColumnsTest.minus' > ; > create table t_bp_2( a int, constraint t_bp_2_check check ( f_fp_minus( a ) < > 0 ) ); > grant insert on t_bp_2 to public; > insert into test_dbo.t_bp_2( a ) values ( 100 ); > connect 'jdbc:derby:derbyauth;create=true;user=janet;password=janetpassword' > as janet_conn; > insert into test_dbo.t_bp_2( a ) values ( 100 ); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3944) CHECK constraints involving user-coded functions may return different results depending on who performs the trigging INSERT/UPDATE
[ https://issues.apache.org/jira/browse/DERBY-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647041#action_12647041 ] Andrew McIntyre commented on DERBY-3944: I checked yesterday and contrary to the way the docs read, DB2 doesn't actually allow user defined functions in SQL in check constraints either. I suspect this may simply be an overlooked corner in the SQL spec, since none of the major vendors support user-defined functions in check constraints and built-in functions never need a schema qualifier. > CHECK constraints involving user-coded functions may return different results > depending on who performs the trigging INSERT/UPDATE > -- > > Key: DERBY-3944 > URL: https://issues.apache.org/jira/browse/DERBY-3944 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.5.0.0 >Reporter: Rick Hillegas > > When compiling a CHECK constraint on behalf of an INSERT/UPDATE statement, > Derby uses the current schema in order to resolve unqualified function names > which appear in the CHECK constraint. This means that the CHECK constraint > may evaluate true for some users, false for others, and for others the CHECK > constraint may raise an error saying that Derby can't resolve the function > reference. This behavior violates the "retrospective determinacy" of CHECK > constraints as specified by part 2 of the ANSI/ISO standard: > 1) section 11.9 (), syntax rule 5 > 2) same section, general rule 1 > 3) section 11.6 (), general rule 3 > 4) section 4.16 (Determinism) > For more discussion, please see this email thread: > http://www.nabble.com/Problem-with-CHECK-constraints-td20445344.html#a20445344 > The following script demonstrates this problem: > connect > 'jdbc:derby:derbyauth;create=true;user=test_dbo;password=test_dbopassword' as > test_dbo_conn; > drop table t_bp_2; > drop function f_fp_minus; > create function f_fp_minus > ( > a int > ) > returns int > language java > deterministic > parameter style java > no sql > external name > 'org.apache.derbyTesting.functionTests.tests.lang.GeneratedColumnsTest.minus' > ; > create table t_bp_2( a int, constraint t_bp_2_check check ( f_fp_minus( a ) < > 0 ) ); > grant insert on t_bp_2 to public; > insert into test_dbo.t_bp_2( a ) values ( 100 ); > connect 'jdbc:derby:derbyauth;create=true;user=janet;password=janetpassword' > as janet_conn; > insert into test_dbo.t_bp_2( a ) values ( 100 ); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2389) DOCS - Move Derby system and properties info from Tuning Guide into Reference Manual
[ https://issues.apache.org/jira/browse/DERBY-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648277#action_12648277 ] Andrew McIntyre commented on DERBY-2389: Hi Kim, I'm not sure what was preventing the copy from happening, but I kicked the copy of the docs off by hand and it appears to be working. The docs should be updated in an hour or so. > DOCS - Move Derby system and properties info from Tuning Guide into Reference > Manual > > > Key: DERBY-2389 > URL: https://issues.apache.org/jira/browse/DERBY-2389 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.4.2.0 >Reporter: Laura Stewart >Assignee: Kim Haase > Attachments: DERBY-2389-adminguide.diff, DERBY-2389-adminguide.stat, > DERBY-2389-adminguide.zip, DERBY-2389-devguide.diff, > DERBY-2389-devguide.stat, DERBY-2389-devguide.zip, DERBY-2389-getstart.diff, > DERBY-2389-getstart.stat, DERBY-2389-getstart.zip, DERBY-2389-ref.diff, > DERBY-2389-ref.stat, DERBY-2389-ref.zip, DERBY-2389-ref2.zip, > DERBY-2389-tuning.diff, DERBY-2389-tuning.stat, DERBY-2389-tuning.zip > > > From Derby User list: > On 2/21/07, Anders Morken <[EMAIL PROTECTED]> wrote: > > Shooting from the hip here, but one thing that has occured to me a few > > times as I've browsed the docs to figure something out is that I > > intuitively expect Derby system and database properties (especially the > > non-performance-related) to be documented in the reference guide, not > > the tuning guide. =) > On 2/21/07, Oystein Grovlen - Sun Norway <[EMAIL PROTECTED]> wrote: > > I agree on this. I would have preferred that all "facts" where > > presented in the Reference Manual, and that the other manuals where more > > "pedagogical" presentations of the same material. Currently, it is not > > very intuitive to determine which manual has the information you are > > looking for. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4024) Replace felix.jar file with the felix sources
[ https://issues.apache.org/jira/browse/DERBY-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664766#action_12664766 ] Andrew McIntyre commented on DERBY-4024: I'm not sure that I understand the reasoning behind this change. felix.jar is a part of Derby's source distribution. Derby completely compiles from the source tarball today, easier than ever thanks to all your recent build work. What advantage is conferred by including the Felix source instead of the jar file in the source distribution, exactly? > Replace felix.jar file with the felix sources > - > > Key: DERBY-4024 > URL: https://issues.apache.org/jira/browse/DERBY-4024 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.5.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: derby-4024-01-aa-felixSources.diff, > derby-4024-01-ab-felixSources.diff > > > In order to bundle Derby with popular linux distributions like Debian and > Ubuntu, it must be possible to build Derby from sources and existing linux > components. By replacing Felix jar with the corresponding sources, we move > another step closer to being able to bundle Derby with linux distributions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-4140) Derby 10.3.3.0 not in Maven repository
[ https://issues.apache.org/jira/browse/DERBY-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre reassigned DERBY-4140: -- Assignee: Andrew McIntyre > Derby 10.3.3.0 not in Maven repository > -- > > Key: DERBY-4140 > URL: https://issues.apache.org/jira/browse/DERBY-4140 > Project: Derby > Issue Type: Bug >Affects Versions: 10.3.3.0 >Reporter: Brandon Smith >Assignee: Andrew McIntyre > > The stable build for the 10.3.x stream, 10.3.3.0, is not in the Maven > repository ecosystem. Since both 10.3.2.1 and 10.3.1.4 contain bugs that > affect data corruption, they are no longer available at db.apache.org/derby > and it is recommended to update to 10.3.3.0, which at present is not possible > using a public Maven repository. > http://repo1.maven.org/maven2/org/apache/derby/derby/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4140) Derby 10.3.3.0 not in Maven repository
[ https://issues.apache.org/jira/browse/DERBY-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12695164#action_12695164 ] Andrew McIntyre commented on DERBY-4140: I thought that I had uploaded the 10.3.3.0 jars to the maven 1 repo on people.apache.org (i.e. http://people.apache.org/repo/m1-ibiblio-rsync-repository/), but something must not have deployed or copied properly. They are now up there. In the past, these had been automatically copied to other maven repositories, hopefully that will continue to happen. The jars are currently lacking PGP signatures, I'll add those later today when I'm near my GPG and close this out. Please let me know if you think there is something additional that needs to be done. > Derby 10.3.3.0 not in Maven repository > -- > > Key: DERBY-4140 > URL: https://issues.apache.org/jira/browse/DERBY-4140 > Project: Derby > Issue Type: Bug >Affects Versions: 10.3.3.0 >Reporter: Brandon Smith >Assignee: Andrew McIntyre > > The stable build for the 10.3.x stream, 10.3.3.0, is not in the Maven > repository ecosystem. Since both 10.3.2.1 and 10.3.1.4 contain bugs that > affect data corruption, they are no longer available at db.apache.org/derby > and it is recommended to update to 10.3.3.0, which at present is not possible > using a public Maven repository. > http://repo1.maven.org/maven2/org/apache/derby/derby/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4140) Derby 10.3.3.0 not in Maven repository
[ https://issues.apache.org/jira/browse/DERBY-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12695636#action_12695636 ] Andrew McIntyre commented on DERBY-4140: Once upon a time, artifacts added to the Maven 1 repostiory were autoconverted and added to the Maven 2 repository, see the discussion in DERBY-1378. I don't think anyone in the Derby development community uses Maven, but if the necessary files and explicit instructions were contributed, deployment to the Maven 2 repository could be added to the Derby release process. > Derby 10.3.3.0 not in Maven repository > -- > > Key: DERBY-4140 > URL: https://issues.apache.org/jira/browse/DERBY-4140 > Project: Derby > Issue Type: Bug >Affects Versions: 10.3.3.0 >Reporter: Brandon Smith >Assignee: Andrew McIntyre > > The stable build for the 10.3.x stream, 10.3.3.0, is not in the Maven > repository ecosystem. Since both 10.3.2.1 and 10.3.1.4 contain bugs that > affect data corruption, they are no longer available at db.apache.org/derby > and it is recommended to update to 10.3.3.0, which at present is not possible > using a public Maven repository. > http://repo1.maven.org/maven2/org/apache/derby/derby/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-337) dblook doesn't generate SQL statements for SQL functions.
[ http://issues.apache.org/jira/browse/DERBY-337?page=all ]
Andrew McIntyre updated DERBY-337:
--
Fix Version: 10.1.0.0
> dblook doesn't generate SQL statements for SQL functions.
> -
>
> Key: DERBY-337
> URL: http://issues.apache.org/jira/browse/DERBY-337
> Project: Derby
> Type: Bug
> Components: Tools
> Versions: 10.0.2.0
> Environment: All platforms.
> Reporter: Satheesh Bandaram
> Priority: Critical
> Fix For: 10.1.0.0
>
> DBLOOK schema dumping tool doesn't emit SQL statements for functions. It
> covers procedures and all other database objects, but not funtions. Here is
> an example I tried:
> [bandaram:satheesh] java org.apache.derby.tools.dblook -d 'jdbc:derby:tdb'
> -- Timestamp: 2005-06-05 09:41:20.603
> -- Source database is: tdb
> -- Connection URL is: jdbc:derby:tdb
> -- appendLogs: false
> -- --
> -- DDL Statements for tables
> -- --
> CREATE TABLE "APP"."T" ("I" INTEGER);
> At this point, the database has only one table 'T'. Now create a function:
> C:\DerbyCode\bug>java -Dij.protocol=jdbc:derby: org.apache.derby.tools.ij
> ij version 10.1
> ij> connect 'tdb';
> ij> create procedure insertAsciiColumn( stmtText varchar( 256), colNumber
> int) P
> ARAMETER STYLE JAVA LANGUAGE JAVA MODIFIES SQL DATA
> EXTERNAL NAME
> 'org.apache.derbyTesting.functionTests.util.StreamUtil.insertAsciiColumn';
> 0 rows inserted/updated/deleted
> Now the output of DBLOOK should show the procedure, but it doesn't.
> [bandaram:satheesh] java org.apache.derby.tools.dblook -d 'jdbc:derby:tdb'
> -- Timestamp: 2005-06-05 09:41:20.603
> -- Source database is: tdb
> -- Connection URL is: jdbc:derby:tdb
> -- appendLogs: false
> -- --
> -- DDL Statements for tables
> -- --
> CREATE TABLE "APP"."T" ("I" INTEGER);
> Now create a procedure:
> C:\DerbyCode\bug>java -Dij.protocol=jdbc:derby: org.apache.derby.tools.ij
> ij version 10.1
> ij> connect 'tdb';
> ij> create procedure insertAsciiColumn( stmtText varchar( 256), colNumber
> int) P
> ARAMETER STYLE JAVA LANGUAGE JAVA MODIFIES SQL DATA
> EXTERNAL NAME
> 'org.apache.derbyTesting.functionTests.util.StreamUtil.insertAsc
> iiColumn';
> 0 rows inserted/updated/deleted
> ij>
> DBLOOK output include newly created procedure, but still not function
> statement.
> [bandaram:satheesh] java org.apache.derby.tools.dblook -d 'jdbc:derby:tdb'
> -- Timestamp: 2005-06-05 09:43:09.5
> -- Source database is: tdb
> -- Connection URL is: jdbc:derby:tdb
> -- appendLogs: false
> -- --
> -- DDL Statements for stored procedures
> -- --
> CREATE PROCEDURE "APP"."INSERTASCIICOLUMN" (IN STMTTEXT VARCHAR(256),IN
> COLNUMBE
> R INTEGER) LANGUAGE JAVA PARAMETER STYLE JAVA MODIFIES SQL DATA EXTERNAL NAME
> 'o
> rg.apache.derbyTesting.functionTests.util.StreamUtil.insertAsciiColumn' ;
> -- --
> -- DDL Statements for tables
> -- --
> CREATE TABLE "APP"."T" ("I" INTEGER);
--
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-338) Move checks for referential constraints from DDL execution time to DML execution time
Move checks for referential constraints from DDL execution time to DML execution time - Key: DERBY-338 URL: http://issues.apache.org/jira/browse/DERBY-338 Project: Derby Type: Bug Components: SQL Versions: 10.0.2.1, 10.0.2.0, 10.1.0.0, 10.0.2.2 Reporter: Andrew McIntyre Assigned to: Jack Klebanoff Fix For: 10.1.0.0 Description for this bug from Jack Klebanoff: The attached patch fixes a problem that Derby had with conflicting referential constraints. Consider the following DDL: create table t2( ref1 int references t1(id) on delete cascade, ref2 int references t1(id) on delete set null) If both the ref1 and ref2 columns of the same t2 row refer to the same t1 row and that t1 row is deleted then the two referential constraint actions conflict. One says that the t2 row should be deleted, the other says that the ref2 column should be set to null. According to the SQL2003 spec an exception should be thrown when the t1 row is deleted. That is what Derby does after the attached patch is applied. Without the patch Derby disallows the DDL statement that creates a constraint whose action may conflict with other constraint actions. This is a mistake. Derby cannot tell at DDL time whether there will actually be a conflict. Derby rejects the DDL statement in the example above. However if none of the t2 rows refer to the same t1 row then there is no conflict. Derby rejects some DDL that will work perfectly well. As, I said above this is contrary to the SQL standard which requires that the checks be made at DML execution time not at DDL execution time. The patch changes iapi/sql/dictionary/DDUtils.java to remove the DDL time checks and changes impl/sql/execute/DeleteCascadeResultSet.java, DMLWriteResultSet.java, and UpdateResultSet.java to add the DML execution time checks. The execution time checks are implemented by building a hash table of all the rows that are changed as the result of referential constraint actions. An exception is thrown if any row is entered into the hash table twice with different actions. The hash table is implemented with BackingStoreHashtable in case it is too large to fit into memory. -- 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-150) Disable logging
[ http://issues.apache.org/jira/browse/DERBY-150?page=comments#action_12312757 ] Andrew McIntyre commented on DERBY-150: --- I think this may be a duplicate of DERBY-218. It would be nice if the submitter of this issue could determine if the reduced durability mode provided for DERBY-218 fulfills this request. > Disable logging > --- > > Key: DERBY-150 > URL: http://issues.apache.org/jira/browse/DERBY-150 > Project: Derby > Type: New Feature > Environment: all > Reporter: Barnet Wagman > > As a means of improving performance, I would like to be able to disable > logging completely. > I use Derby in applications thatnever use rollback and I suspect that quite a > lot of time is going to logging. > Thanks -- 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-339) Network client XA should only keep XA state for transaction branch association, to track whether to send commit in autocommit mode. All other state and state related decisions should be deferred to the server.
[ http://issues.apache.org/jira/browse/DERBY-339?page=all ] Andrew McIntyre updated DERBY-339: -- Fix Version: 10.1.0.0 > Network client XA should only keep XA state for transaction branch > association, to track whether to send commit in autocommit mode. All other > state and state related decisions should be deferred to the server. > -- > > Key: DERBY-339 > URL: http://issues.apache.org/jira/browse/DERBY-339 > Project: Derby > Type: Bug > Components: Network Client > Versions: 10.1.0.0 > Reporter: Kathey Marsden > Assignee: Kathey Marsden > Fix For: 10.1.0.0 > Attachments: derby339.diff > > Network client XA should only keep XA state for transaction branch > association, to track whether to send commit in autocommit mode. All other > state and state related decisions should be defered to the server. > The client tries to track XA state to make decisions based on current XA > state. Most of this state handling was removed with DERBY246, but it still > was not being handled properly. This is evidenced by multiple failures in > xaSimplePostive that now that it gets past DERBY-246. > This fix will have the client track only branch association as outlined in > the XA+ specification. Table 6-2, State Table for Transaction Branch > Association. The client will track only > XA_TO_NOT_ASSOCIATED > XA_T1_ASSOCIATED > Association Suspended (T2) will map to XA_TO_NOT_ASSOCIATED for the client's > pupurposes. > The client commit in autocommit mode only for > XA_TO_NOT_ASSOCIATED. -- 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-341) Client should disallow XAConnection getConnection() when a global transaction has been started and a logical connection has already been obtained
[ http://issues.apache.org/jira/browse/DERBY-341?page=all ] Andrew McIntyre updated DERBY-341: -- Fix Version: 10.1.0.0 > Client should disallow XAConnection getConnection() when a global transaction > has been started and a logical connection has already been obtained > - > > Key: DERBY-341 > URL: http://issues.apache.org/jira/browse/DERBY-341 > Project: Derby > Type: Bug > Versions: 10.1.0.0 > Reporter: Kathey Marsden > Fix For: 10.1.0.0 > > If a logical connection has already been obtained, client should disallow > XAConnection getConnection if a global transaction has been started and a > logical connection has already been obtained > Repro: > With the client the script below does not give an error. > ij> connect 'wombat;create=true'; > ij> disconnect; > ij> xa_datasource 'wombat'; > ij> xa_connect user 'APP' password 'xxx'; > Connection number: 3. > ij> -- start new transaction > xa_start xa_noflags 0; > ij> xa_getconnection; > ij> -- Should not be able to get connection again > xa_getconnection; > With embedded we get. > ERROR XJ059: Cannot close a connection while a global transaction is still > active. -- 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-343) Clean up related DRDA classes
[ http://issues.apache.org/jira/browse/DERBY-343?page=all ]
Andrew McIntyre updated DERBY-343:
--
Fix Version: 10.2.0.0
(was: 10.0.2.1)
(was: 10.0.2.0)
> Clean up related DRDA classes
> -
>
> Key: DERBY-343
> URL: http://issues.apache.org/jira/browse/DERBY-343
> Project: Derby
> Type: Sub-task
> Components: Network Server
> Versions: 10.0.2.1, 10.0.2.0
> Reporter: Philip Wilder
> Assignee: Philip Wilder
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: Derby213.diff
>
> The follow is a list of changes to be implemented in the DRDAConnThread,
> DRDAStatement and DRDAResultSet. It is hoped that these changes will clean up
> code related to DERBY-213 and make the fix easier to implement.
> ###
> Step 1:
> In org.apache.derby.impl.drda.DRDAResultSet add
> public static final int QRYCLSIMP_DEFAULT = CodePoint.QRYCLSIMP_NO;
>
> Step 2:
> Copy the org.apache.derby.impl.drda.DRDAStatement.setOPNQRYOptions() method
> to the org.apache.derby.impl.drda.DRDAResultSet class and
> change the logic of set setOPNQRYOptions() to remove the setting of the
> qryclsimp value to QRYCLSIMP_SERVER_CHOICE. Only the values of YES or NO will
> ever be stored internally.
> e.g.
> DRDAResultSet.setOPNQRYOptions(int blksize, int qryblkctl, int maxblkext, int
> outovropt, int qryrowset,
> int qryclsimpl) {
> this.blksize = blksize;
> setQryprctyp(qryblkctl);
> this.maxblkext = maxblkext;
> this.outovropt = outovropt;
> this.qryrowset = qryrowset;
> this.qryclsimp = (qryclsimpl == CodePoint.QRYCLSIMP_SERVER_CHOICE)
> ? DRDAResultSet.QRYCLSIMP_DEFAULT : qryclsimpl;
> }
> Thereafter change to the DRDAStatement.setOPNQRYOptions() to a delegation
> method which calls the method in DRDAResultSet
> e.g.
> DRDAStatement.setOPNQRYOptions(int blksize, int qryblkctl,
> int maxblkext, int outovropt,int
> qryrowset,int qryclsimpl)
> {
> currentDrdaRs.setOPNQRYOptions(blksize, qryblkctl, maxblkext,
> outovropt, qryrowset, qryclsimpl);
> }
> ###
> Step 3:
> Add org.apache.derby.impl.drda.DRDAResultSet.isRSCloseImplicit() which will
> test to see if the resultset should close implicitly
> e.g.
> boolean DRDAResultSet.isRSCloseImplicit() {
> return currentDrdaRs.qryclsimp == CodePoint.QRYCLSIMP_YES &&
> stmt.getQryprctyp() != CodePoint.LMTBLKPRC
> }
> Then add a corresponding delegation method in
> org.apache.derby.impl.drda.DRDAStatement()
> boolean DRDAStatement.isRSCloseImplicit() {
> return currentDrdaRs.isRSCloseImplicit();
> }
> ###
> Step 4:
> Remove org.apache.derby.impl.drda.DRDAStatment.setQryclsimp(int value)
> ###
> Step 5:
> Remove all references to
> if (qryclsimp == CodePoint.QRYCLSIMP_YES &&
> stmt.getQryprctyp() != CodePoint.LMTBLKPRC) { ...
> logic and replace with
> if (drdaStatement.isRSCloseImplicit()) { ...
> This should remove all references to
> org.apache.derby.impl.drda.DRDAStatment.getQryclsimp() which can in turn be
> removed.
> ###
> Step 6:
> In org.apache.derby.drda.impl.DRDAResultSet change:
> protected int qryclsimp
> to
> private int qryclsimp;
> ###
> Step 7:
> In org.apache.derby.drda.impl.DRDAConnThread.parseOPNQRY() change the line
> int qryclsimp = CodePoint.QRYCLSIMP_DEFAULT;
> to
> int qryclsimp = DRDAResultSet.QRYCLSIMP_DEFAULT
> ###
> Step 8:
> In org.apache.derby.drda.impl.CodePoint remove
> static final int QRYCLSIMP_DEFAULT = QRYCLSIMP_SERVER_CHOICE;
> ###
> Step 9: Insure that the new methods and changed methods have appropriate java
> documentation.
> ###
> Step 10: Organize the import for the DRDAConnThread, DRDAStatement and
> DRDAResultSet classes found in the org.apache.derby.drda.impl package.
--
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-297) Submit an entry for the Derby logo contest by uploading it to this issue
[ http://issues.apache.org/jira/browse/DERBY-297?page=all ] Andrew McIntyre updated DERBY-297: -- Attachment: andrew-derbyhat1.jpg Simple Derby logo on the hat theme. > Submit an entry for the Derby logo contest by uploading it to this issue > > > Key: DERBY-297 > URL: http://issues.apache.org/jira/browse/DERBY-297 > Project: Derby > Type: Task > Components: Web Site > Reporter: Jean T. Anderson > Assignee: Jean T. Anderson > Priority: Minor > Attachments: andrew-derbyhat1.jpg, andrew-derbyhat2.jpg, derby.JPG, > derby4.jpg > > On May 3 Susan Cline posted a note to kick start the Derby logo contest: > http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL > PROTECTED] > If you have a logo to submit, please attach it to this issue. (See > http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL > PROTECTED] for the suggestion on using Jira to manage logo submissions.) > The assignee will update the index to images below: > File : Submitter > derby4.jpg : Andrew Kachalo > derby.jpg : Michael D. Purdue -- 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-297) Submit an entry for the Derby logo contest by uploading it to this issue
[ http://issues.apache.org/jira/browse/DERBY-297?page=all ] Andrew McIntyre updated DERBY-297: -- Attachment: andrew-derbyknight2.jpg Attaching derby knight with sans serif font separately. > Submit an entry for the Derby logo contest by uploading it to this issue > > > Key: DERBY-297 > URL: http://issues.apache.org/jira/browse/DERBY-297 > Project: Derby > Type: Task > Components: Web Site > Reporter: Jean T. Anderson > Assignee: Jean T. Anderson > Priority: Minor > Attachments: andrew-derbyhat1.jpg, andrew-derbyhat2.jpg, > andrew-derbyknight1.jpg, derby4.jpg > > On May 3 Susan Cline posted a note to kick start the Derby logo contest: > http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL > PROTECTED] > If you have a logo to submit, please attach it to this issue. (See > http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL > PROTECTED] for the suggestion on using Jira to manage logo submissions.) > The assignee will update the index to images below: > File : Submitter > derby4.jpg : Andrew Kachalo > derby.jpg : Michael D. Purdue -- 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-297) Submit an entry for the Derby logo contest by uploading it to this issue
[ http://issues.apache.org/jira/browse/DERBY-297?page=all ] Andrew McIntyre updated DERBY-297: -- Attachment: andrew-derbyknight1.jpg > Submit an entry for the Derby logo contest by uploading it to this issue > > > Key: DERBY-297 > URL: http://issues.apache.org/jira/browse/DERBY-297 > Project: Derby > Type: Task > Components: Web Site > Reporter: Jean T. Anderson > Assignee: Jean T. Anderson > Priority: Minor > Attachments: andrew-derbyhat1.jpg, andrew-derbyhat2.jpg, > andrew-derbyknight1.jpg, derby4.jpg > > On May 3 Susan Cline posted a note to kick start the Derby logo contest: > http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL > PROTECTED] > If you have a logo to submit, please attach it to this issue. (See > http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL > PROTECTED] for the suggestion on using Jira to manage logo submissions.) > The assignee will update the list of images below: > File : Submitter > derby4.jpg : Andrew Kachalo > andrew-derbyhat.jpg : Andrew McIntyre > andrew-derbyhat2.jpg : Andrew McIntyre -- 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-297) Submit an entry for the Derby logo contest by uploading it to this issue
[ http://issues.apache.org/jira/browse/DERBY-297?page=all ] Andrew McIntyre updated DERBY-297: -- Attachment: andrew-derbyknight2.jpg > Submit an entry for the Derby logo contest by uploading it to this issue > > > Key: DERBY-297 > URL: http://issues.apache.org/jira/browse/DERBY-297 > Project: Derby > Type: Task > Components: Web Site > Reporter: Jean T. Anderson > Assignee: Jean T. Anderson > Priority: Minor > Attachments: andrew-derbyhat1.jpg, andrew-derbyhat2.jpg, > andrew-derbyknight1.jpg, andrew-derbyknight2.jpg, derby4.jpg > > On May 3 Susan Cline posted a note to kick start the Derby logo contest: > http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL > PROTECTED] > If you have a logo to submit, please attach it to this issue. (See > http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL > PROTECTED] for the suggestion on using Jira to manage logo submissions.) > The assignee will update the list of images below: > File : Submitter > derby4.jpg : Andrew Kachalo > andrew-derbyhat.jpg : Andrew McIntyre > andrew-derbyhat2.jpg : Andrew McIntyre -- 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-297) Submit an entry for the Derby logo contest by uploading it to this issue
[ http://issues.apache.org/jira/browse/DERBY-297?page=all ] Andrew McIntyre updated DERBY-297: -- Attachment: andrew-derbyknight.jpg Derby logo with a knight-chess-piece theme. Implies strong, flexible, a strategic inside part of an application. included a couple different type options for comparison. > Submit an entry for the Derby logo contest by uploading it to this issue > > > Key: DERBY-297 > URL: http://issues.apache.org/jira/browse/DERBY-297 > Project: Derby > Type: Task > Components: Web Site > Reporter: Jean T. Anderson > Assignee: Jean T. Anderson > Priority: Minor > Attachments: andrew-derbyhat1.jpg, andrew-derbyhat2.jpg, > andrew-derbyknight.jpg, derby4.jpg > > On May 3 Susan Cline posted a note to kick start the Derby logo contest: > http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL > PROTECTED] > If you have a logo to submit, please attach it to this issue. (See > http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL > PROTECTED] for the suggestion on using Jira to manage logo submissions.) > The assignee will update the index to images below: > File : Submitter > derby4.jpg : Andrew Kachalo > derby.jpg : Michael D. Purdue -- 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-297) Submit an entry for the Derby logo contest by uploading it to this issue
[ http://issues.apache.org/jira/browse/DERBY-297?page=all ] Andrew McIntyre updated DERBY-297: -- Attachment: andrew-derbyknight1.jpg Attaching Derby knight with serif font separately. > Submit an entry for the Derby logo contest by uploading it to this issue > > > Key: DERBY-297 > URL: http://issues.apache.org/jira/browse/DERBY-297 > Project: Derby > Type: Task > Components: Web Site > Reporter: Jean T. Anderson > Assignee: Jean T. Anderson > Priority: Minor > Attachments: andrew-derbyhat1.jpg, andrew-derbyhat2.jpg, > andrew-derbyknight1.jpg, derby4.jpg > > On May 3 Susan Cline posted a note to kick start the Derby logo contest: > http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL > PROTECTED] > If you have a logo to submit, please attach it to this issue. (See > http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL > PROTECTED] for the suggestion on using Jira to manage logo submissions.) > The assignee will update the index to images below: > File : Submitter > derby4.jpg : Andrew Kachalo > derby.jpg : Michael D. Purdue -- 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-344) NPE while performing a 'select distinct ' on a database in softupgrademode with 10.1
[ http://issues.apache.org/jira/browse/DERBY-344?page=all ] Andrew McIntyre updated DERBY-344: -- Fix Version: 10.1.0.0 > NPE while performing a 'select distinct ' on a database in softupgrademode > with 10.1 > > > Key: DERBY-344 > URL: http://issues.apache.org/jira/browse/DERBY-344 > Project: Derby > Type: Bug > Components: SQL > Versions: 10.1.0.0 > Environment: Windows 2000 > Reporter: Rajesh Kartha > Assignee: Jack Klebanoff > Fix For: 10.1.0.0 > Attachments: BackingStoreHashtable2005-06-07.diff > > Performing a 'select distinct' on a database create with v10.0 and running > under softupgrademode with v10.1 throws a NPE. > The ij tool in v10.1 was started using java > -Dderby.database.allowPreReleaseUpgrade=true org.apache.derby.tools.ij > to allow softupgrades. > ij> connect 'jdbc:derby:videodb'; > ij> select distinct title from music_titles; > TITLE > -- > ACPE_music Blue You Flew Moo Do > APIH_music You Flew Moo Do > ABZC_music You Flew Moo Do > ERROR XJ001: Java exception: ': java.lang.NullPointerException'. > Following is the stack trace from the derby.log: > 2005-06-07 23:15:53.921 GMT Thread[main,5,main] (XID = 279297), (SESSIONID = > 0), (DATABASE = videodb), (DRDAID = null), Failed Statement is: select > distinct title from music_titles > java.lang.NullPointerException > at > org.apache.derby.iapi.store.access.BackingStoreHashtable.cloneRow(BackingStoreHashtable.java:326) > at > org.apache.derby.iapi.store.access.DiskHashtable$ElementEnum.nextElement(DiskHashtable.java:351) > at > org.apache.derby.iapi.store.access.BackingStoreHashtable$BackingStoreHashtableEnumeration.nextElement(BackingStoreHashtable.java:739) > at > org.apache.derby.impl.sql.execute.DistinctScanResultSet.getNextRowCore(DistinctScanResultSet.java:140) > at > org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(BasicNoPutResultSetImpl.java:471) > at > org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:346) > at > org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:299) > at > org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:334) > at > org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:271) > at > org.apache.derby.tools.JDBCDisplayUtil.DisplayResults(JDBCDisplayUtil.java:260) > at > org.apache.derby.impl.tools.ij.utilMain.displayResult(utilMain.java:381) > at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:434) > at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310) > at org.apache.derby.impl.tools.ij.Main.go(Main.java:203) > at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:169) > at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55) > at org.apache.derby.tools.ij.main(ij.java:60) > Cleanup action completed > The schema looks like: > CREATE TABLE music_titles ( > titlevarchar (50) NOT NULL, > artist varchar (50) NOT NULL, > artist_more varchar (50) not null, > distributor varchar (50), > record_label varchar (50), > type CHARACTER (10),CONSTRAINT music_titles_pk > PRIMARY KEY (title, artist, artist_more)) -- 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-297) Submit an entry for the Derby logo contest by uploading it to this issue
[ http://issues.apache.org/jira/browse/DERBY-297?page=all ] Andrew McIntyre updated DERBY-297: -- Attachment: andrew-derbyknight1.jpg > Submit an entry for the Derby logo contest by uploading it to this issue > > > Key: DERBY-297 > URL: http://issues.apache.org/jira/browse/DERBY-297 > Project: Derby > Type: Task > Components: Web Site > Reporter: Jean T. Anderson > Assignee: Jean T. Anderson > Priority: Minor > Attachments: andrew-derbyhat1.jpg, andrew-derbyhat2.jpg, > andrew-derbyknight1.jpg, derby4.jpg > > On May 3 Susan Cline posted a note to kick start the Derby logo contest: > http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL > PROTECTED] > If you have a logo to submit, please attach it to this issue. (See > http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL > PROTECTED] for the suggestion on using Jira to manage logo submissions.) > The assignee will update the list of images below: > File : Submitter > derby4.jpg : Andrew Kachalo > andrew-derbyhat.jpg : Andrew McIntyre > andrew-derbyhat2.jpg : Andrew McIntyre -- 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-297) Submit an entry for the Derby logo contest by uploading it to this issue
[ http://issues.apache.org/jira/browse/DERBY-297?page=all ] Andrew McIntyre updated DERBY-297: -- Attachment: andrew-derbyhat2.jpg Variation on andrew-derbyhat, simple logo with the hat theme. Raised the 'y' in derby so that the top is aligned with the already raised 'er', making the 'db' embedded. (haha) > Submit an entry for the Derby logo contest by uploading it to this issue > > > Key: DERBY-297 > URL: http://issues.apache.org/jira/browse/DERBY-297 > Project: Derby > Type: Task > Components: Web Site > Reporter: Jean T. Anderson > Assignee: Jean T. Anderson > Priority: Minor > Attachments: andrew-derbyhat1.jpg, andrew-derbyhat2.jpg, derby.JPG, > derby4.jpg > > On May 3 Susan Cline posted a note to kick start the Derby logo contest: > http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL > PROTECTED] > If you have a logo to submit, please attach it to this issue. (See > http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL > PROTECTED] for the suggestion on using Jira to manage logo submissions.) > The assignee will update the index to images below: > File : Submitter > derby4.jpg : Andrew Kachalo > derby.jpg : Michael D. Purdue -- 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-343) Clean up DRDA classes handling of OPNQRY options
[ http://issues.apache.org/jira/browse/DERBY-343?page=all ]
Andrew McIntyre updated DERBY-343:
--
Fix Version: 10.1.0.0
(was: 10.2.0.0)
> Clean up DRDA classes handling of OPNQRY options
>
>
> Key: DERBY-343
> URL: http://issues.apache.org/jira/browse/DERBY-343
> Project: Derby
> Type: Sub-task
> Components: Network Server
> Versions: 10.0.2.1, 10.0.2.0
> Reporter: Philip Wilder
> Assignee: Philip Wilder
> Priority: Minor
> Fix For: 10.1.0.0
> Attachments: Derby213.diff
>
> The follow is a list of changes to be implemented in the DRDAConnThread,
> DRDAStatement and DRDAResultSet. It is hoped that these changes will clean up
> code related to DERBY-213 and make the fix easier to implement.
> ###
> Step 1:
> In org.apache.derby.impl.drda.DRDAResultSet add
> public static final int QRYCLSIMP_DEFAULT = CodePoint.QRYCLSIMP_NO;
>
> Step 2:
> Copy the org.apache.derby.impl.drda.DRDAStatement.setOPNQRYOptions() method
> to the org.apache.derby.impl.drda.DRDAResultSet class and
> change the logic of set setOPNQRYOptions() to remove the setting of the
> qryclsimp value to QRYCLSIMP_SERVER_CHOICE. Only the values of YES or NO will
> ever be stored internally.
> e.g.
> DRDAResultSet.setOPNQRYOptions(int blksize, int qryblkctl, int maxblkext, int
> outovropt, int qryrowset,
> int qryclsimpl) {
> this.blksize = blksize;
> setQryprctyp(qryblkctl);
> this.maxblkext = maxblkext;
> this.outovropt = outovropt;
> this.qryrowset = qryrowset;
> this.qryclsimp = (qryclsimpl == CodePoint.QRYCLSIMP_SERVER_CHOICE)
> ? DRDAResultSet.QRYCLSIMP_DEFAULT : qryclsimpl;
> }
> Thereafter change to the DRDAStatement.setOPNQRYOptions() to a delegation
> method which calls the method in DRDAResultSet
> e.g.
> DRDAStatement.setOPNQRYOptions(int blksize, int qryblkctl,
> int maxblkext, int outovropt,int
> qryrowset,int qryclsimpl)
> {
> currentDrdaRs.setOPNQRYOptions(blksize, qryblkctl, maxblkext,
> outovropt, qryrowset, qryclsimpl);
> }
> ###
> Step 3:
> Add org.apache.derby.impl.drda.DRDAResultSet.isRSCloseImplicit() which will
> test to see if the resultset should close implicitly
> e.g.
> boolean DRDAResultSet.isRSCloseImplicit() {
> return currentDrdaRs.qryclsimp == CodePoint.QRYCLSIMP_YES &&
> stmt.getQryprctyp() != CodePoint.LMTBLKPRC
> }
> Then add a corresponding delegation method in
> org.apache.derby.impl.drda.DRDAStatement()
> boolean DRDAStatement.isRSCloseImplicit() {
> return currentDrdaRs.isRSCloseImplicit();
> }
> ###
> Step 4:
> Remove org.apache.derby.impl.drda.DRDAStatment.setQryclsimp(int value)
> ###
> Step 5:
> Remove all references to
> if (qryclsimp == CodePoint.QRYCLSIMP_YES &&
> stmt.getQryprctyp() != CodePoint.LMTBLKPRC) { ...
> logic and replace with
> if (drdaStatement.isRSCloseImplicit()) { ...
> This should remove all references to
> org.apache.derby.impl.drda.DRDAStatment.getQryclsimp() which can in turn be
> removed.
> ###
> Step 6:
> In org.apache.derby.drda.impl.DRDAResultSet change:
> protected int qryclsimp
> to
> private int qryclsimp;
> ###
> Step 7:
> In org.apache.derby.drda.impl.DRDAConnThread.parseOPNQRY() change the line
> int qryclsimp = CodePoint.QRYCLSIMP_DEFAULT;
> to
> int qryclsimp = DRDAResultSet.QRYCLSIMP_DEFAULT
> ###
> Step 8:
> In org.apache.derby.drda.impl.CodePoint remove
> static final int QRYCLSIMP_DEFAULT = QRYCLSIMP_SERVER_CHOICE;
> ###
> Step 9: Insure that the new methods and changed methods have appropriate java
> documentation.
> ###
> Step 10: Organize the import for the DRDAConnThread, DRDAStatement and
> DRDAResultSet classes found in the org.apache.derby.drda.impl package.
--
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-314) eclipse plugin needs improved network server process handling
[ http://issues.apache.org/jira/browse/DERBY-314?page=all ] Andrew McIntyre resolved DERBY-314: --- Fix Version: 10.1.0.0 Resolution: Fixed Committed attached patch, revision 189829. > eclipse plugin needs improved network server process handling > - > > Key: DERBY-314 > URL: http://issues.apache.org/jira/browse/DERBY-314 > Project: Derby > Type: Bug > Components: Tools > Versions: 10.0.2.0 > Environment: windows, eclipse 301, jdk142 > Reporter: Myrna van Lunteren > Assignee: Susan Cline > Priority: Minor > Fix For: 10.1.0.0 > Attachments: plugins_networkserver.diff > > The eclipse plugin allows you to create multiple network server processes > within the same project through a gap in the checking mechanism, but you > can't close all those you create that way from within eclipse. > To duplicate do the following: > - setup the plugin and apply the eclipse nature to a project > - start network server on the default port. > - switch the port number using the derby preferences e.g. to 1528 > - go to the derby task - you see that the networkserver start/stop is a > toggle, and because last time you started a networkserver process, it is now > on 'stop'. Run the 'stop Networkserver. This will fail, because network > server is not running on port 1528, so cannot be stopped. > The toggle will now go back to 'start'. > - start networkserver on port 1528. > - trying this 'trick' in reverse - i.e. for the start - does not work, if the > start fails, the toggle remains on 'start'. -- 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-338) Move checks for referential constraints from DDL execution time to DML execution time
[ http://issues.apache.org/jira/browse/DERBY-338?page=all ] Andrew McIntyre updated DERBY-338: -- Fix Version: 10.2.0.0 (was: 10.1.0.0) It appears patch will not be ready to make 10.1 release timeframe. Moving Fix version to 10.2.0.0. > Move checks for referential constraints from DDL execution time to DML > execution time > - > > Key: DERBY-338 > URL: http://issues.apache.org/jira/browse/DERBY-338 > Project: Derby > Type: Improvement > Components: SQL > Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.0.0 > Reporter: Andrew McIntyre > Assignee: Jack Klebanoff > Fix For: 10.2.0.0 > Attachments: refConstraint2005-06-07.diff, refConstraint2005-06-08.diff > > Description for this bug from Jack Klebanoff: > The attached patch fixes a problem that Derby had with conflicting > referential constraints. Consider the following DDL: > create table t2( ref1 int references t1(id) on delete cascade, >ref2 int references t1(id) on delete set null) > If both the ref1 and ref2 columns of the same t2 row refer to the same t1 row > and that t1 row is deleted then the two referential constraint actions > conflict. One says that the t2 row should be deleted, the other says that the > ref2 column should be set to null. According to the SQL2003 spec an exception > should be thrown when the t1 row is deleted. That is what Derby does after > the attached patch is applied. > Without the patch Derby disallows the DDL statement that creates a constraint > whose action may conflict with other constraint actions. This is a mistake. > Derby cannot tell at DDL time whether there will actually be a conflict. > Derby rejects the DDL statement in the example above. However if none of the > t2 rows refer to the same t1 row then there is no conflict. Derby rejects > some DDL that will work perfectly well. As, I said above this is contrary to > the SQL standard which requires that the checks be made at DML execution time > not at DDL execution time. > The patch changes iapi/sql/dictionary/DDUtils.java to remove the DDL time > checks and changes impl/sql/execute/DeleteCascadeResultSet.java, > DMLWriteResultSet.java, and UpdateResultSet.java to add the DML execution > time checks. The execution time checks are implemented by building a hash > table of all the rows that are changed as the result of referential > constraint actions. An exception is thrown if any row is entered into the > hash table twice with different actions. The hash table is implemented with > BackingStoreHashtable in case it is too large to fit into memory. -- 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 ] Andrew McIntyre updated DERBY-247: -- Attachment: simpleapp.diff Hi Lance, For this release, I would like to support JCC as an option in the demos. I have attached a diff for SimpleApp as an example, kindly provided to me by Stan Bradbury. > 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: Andrew McIntyre > Assignee: Lance Andersen > Priority: Minor > Fix For: 10.1.0.0 > Attachments: simpleapp.diff > > 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] Closed: (DERBY-247) Network Server demo program should support Derby network client driver
[ http://issues.apache.org/jira/browse/DERBY-247?page=all ] Andrew McIntyre closed DERBY-247: - Fix Version: 10.2.0.0 Resolution: Fixed Committed this patch to 10.1 (190802) and trunk (190803). Also updated sample output in nserverdemo html files. > 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: Andrew McIntyre > Assignee: Lance Andersen > Priority: Minor > Fix For: 10.1.0.0, 10.2.0.0 > Attachments: demo.txt, simpleapp.diff > > 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-156) Delete with alias on column fails
[ http://issues.apache.org/jira/browse/DERBY-156?page=all ] Andrew McIntyre updated DERBY-156: -- Fix Version: 10.2.0.0 (was: 10.1.0.0) Description: 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-) was: 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-) Version: 10.2.0.0 Environment: > 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.0, 10.0.2.1, 10.0.2.2, 10.2.0.0, 10.1.0.0 > Reporter: Bernd Ruehlicke > Priority: Critical > Fix For: 10.2.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-104) Get rid of the Max lenght of 18 for constraint names
[ http://issues.apache.org/jira/browse/DERBY-104?page=all ] Andrew McIntyre updated DERBY-104: -- Component: SQL Fix Version: 10.1.0.0 Version: 10.0.2.1 10.0.2.0 10.1.0.0 10.0.2.2 Environment: > Get rid of the Max lenght of 18 for constraint names > > > Key: DERBY-104 > URL: http://issues.apache.org/jira/browse/DERBY-104 > Project: Derby > Type: Wish > Components: SQL > Versions: 10.0.2.1, 10.0.2.0, 10.1.0.0, 10.0.2.2 > Reporter: Bernd Ruehlicke > Assignee: Bernt M. Johnsen > Priority: Minor > Fix For: 10.1.0.0 > Attachments: derby-id-plus-renames-v2.patch > > If not unlimited than we should at least make them 80 (just to pick a > abitrary number) -- 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-104) Get rid of the Max lenght of 18 for constraint names
[ http://issues.apache.org/jira/browse/DERBY-104?page=all ] Andrew McIntyre reopened DERBY-104: --- reopening to set Affects and Fix In. > Get rid of the Max lenght of 18 for constraint names > > > Key: DERBY-104 > URL: http://issues.apache.org/jira/browse/DERBY-104 > Project: Derby > Type: Wish > Components: SQL > Versions: 10.0.2.1, 10.0.2.0, 10.1.0.0, 10.0.2.2 > Reporter: Bernd Ruehlicke > Assignee: Bernt M. Johnsen > Priority: Minor > Fix For: 10.1.0.0 > Attachments: derby-id-plus-renames-v2.patch > > If not unlimited than we should at least make them 80 (just to pick a > abitrary number) -- 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-104) Get rid of the Max lenght of 18 for constraint names
[ http://issues.apache.org/jira/browse/DERBY-104?page=all ] Andrew McIntyre closed DERBY-104: - Resolution: Fixed > Get rid of the Max lenght of 18 for constraint names > > > Key: DERBY-104 > URL: http://issues.apache.org/jira/browse/DERBY-104 > Project: Derby > Type: Wish > Components: SQL > Versions: 10.0.2.1, 10.0.2.0, 10.1.0.0, 10.0.2.2 > Reporter: Bernd Ruehlicke > Assignee: Bernt M. Johnsen > Priority: Minor > Fix For: 10.1.0.0 > Attachments: derby-id-plus-renames-v2.patch > > If not unlimited than we should at least make them 80 (just to pick a > abitrary number) -- 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-394) Fix for doc formatting, presentation, overall quality
[ http://issues.apache.org/jira/browse/DERBY-394?page=all ] Andrew McIntyre resolved DERBY-394: --- Resolution: Fixed Committed, revision 202296. > Fix for doc formatting, presentation, overall quality > - > > Key: DERBY-394 > URL: http://issues.apache.org/jira/browse/DERBY-394 > Project: Derby > Type: Improvement > Components: Documentation > Environment: all > Reporter: Jeff Levitt > Assignee: Jeff Levitt > Fix For: 10.1.1.0 > Attachments: fixpatch.diff > > I will soon be attaching a patch that will desacribe the changes I want to > make in more detail... -- 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-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
[ http://issues.apache.org/jira/browse/DERBY-254?page=all ] Andrew McIntyre updated DERBY-254: -- Fix Version: 10.2.0.0 (was: 10.1.1.0) Description: SQLExceptions generated from the client tend to have a null SQLState. An evaluation of the SQLExceptions thrown by the client needs to be performed and match embedded where possible. If this does not happen before the 10.1 release, it would be good to document that SQLStates in the client will change for future releases was: SQLExceptions generated from the client tend to have a null SQLState. An evaluation of the SQLExceptions thrown by the client needs to be performed and match embedded where possible. If this does not happen before the 10.1 release, it would be good to document that SQLStates in the client will change for future releases Version: 10.2.0.0 Environment: Moving this issue to 10.2 - will add comment about this issue to doc review issue for the reference manual. > SQLStates for SQLExceptions thrown from the client should not be null and > should match embedded where possible > -- > > Key: DERBY-254 > URL: http://issues.apache.org/jira/browse/DERBY-254 > Project: Derby > Type: Improvement > Components: Network Client > Versions: 10.2.0.0, 10.1.1.0 > Reporter: Kathey Marsden > Fix For: 10.2.0.0 > > SQLExceptions generated from the client tend to have a null SQLState. An > evaluation of the SQLExceptions thrown by the client needs to be performed > and match embedded where possible. > If this does not happen before the 10.1 release, it would be good to document > that SQLStates in the client will change for future releases -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-382) Doc Review (CLOSED TO FURTHER COMMENTS): Derby Reference Manual
[ http://issues.apache.org/jira/browse/DERBY-382?page=comments#action_12314692 ] Andrew McIntyre commented on DERBY-382: --- Please add a note concerning DERBY-254 to the section regarding SQLStates. Here's the DERBY-254 description: SQLExceptions generated from the client tend to have a null SQLState. An evaluation of the SQLExceptions thrown by the client needs to be performed and match embedded where possible. If this does not happen before the 10.1 release, it would be good to document that SQLStates in the client will change for future releases. > Doc Review (CLOSED TO FURTHER COMMENTS): Derby Reference Manual > --- > > Key: DERBY-382 > URL: http://issues.apache.org/jira/browse/DERBY-382 > Project: Derby > Type: Improvement > Components: Documentation > Environment: all > Reporter: Jeff Levitt > Priority: Minor > Fix For: 10.1.1.0 > > This issue tracks comments for the Derby Reference Manual. The deadline for > posting comments was Tuesday, June 28, noon Pacific time. > PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have > additional comments, please open a JIRA issue for a fixin in a future > release, as there is not enough time to incorporate additional comments. > Some guidelines to follow when posting comments to this issue are: > - Try to make clear and concise comments about what you want changed whenever > possible. Provide concrete comments that say "Please change to > " instead of generic comments like "This section needs to be > rewritten." > - If you're reviewing the HTML Files copy, include the URL for the page in > the review comment. Obtain the URL like this: > * highlight the topic in the left frame > * right click > * choose "Properties" > * copy and paste the address in the pop up box. > - If you're reviewing the PDF copy, in the review comment: > * Include the page number for the PDF, and indicate whether the number is > the PDF sheet number or the printed page number. > * Include the title of the section that the problem occurs in. If it's in > a subsection, try to include the hierarchy of titles. > - Please don't review the HTML Book copy -- it'll be time consuming to match > up that copy with the underlying DITA source. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-381) Doc review (CLOSED TO FURTHER COMMENTS): Derby Server and Admin Guide
[ http://issues.apache.org/jira/browse/DERBY-381?page=comments#action_12314693 ] Andrew McIntyre commented on DERBY-381: --- For the record, regarding item #8 of Susan Cline's comments, I do plan to compile the demo classes and include them in the -bin distribution, so this portion of the doc is actually correct and does not need to be changed. > Doc review (CLOSED TO FURTHER COMMENTS): Derby Server and Admin Guide > - > > Key: DERBY-381 > URL: http://issues.apache.org/jira/browse/DERBY-381 > Project: Derby > Type: Improvement > Components: Documentation > Environment: all > Reporter: Jeff Levitt > Priority: Minor > Fix For: 10.1.1.0 > > This issue tracks comments for the Derby Server and Administration Guide. The > deadline for posting comments WAS Tuesday, June 28, noon Pacific time. > PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have > additional comments, please open a JIRA issue for a fixin in a future > release, as there is not enough time to incorporate additional comments. > Some guidelines to follow when posting comments to this issue are: > - Try to make clear and concise comments about what you want changed whenever > possible. Provide concrete comments that say "Please change to > " instead of generic comments like "This section needs to be > rewritten." > - If you're reviewing the HTML Files copy, include the URL for the page in > the review comment. Obtain the URL like this: > * highlight the topic in the left frame > * right click > * choose "Properties" > * copy and paste the address in the pop up box. > - If you're reviewing the PDF copy, in the review comment: > * Include the page number for the PDF, and indicate whether the number is > the PDF sheet number or the printed page number. > * Include the title of the section that the problem occurs in. If it's in > a subsection, try to include the hierarchy of titles. > - Please don't review the HTML Book copy -- it'll be time consuming to match > up that copy with the underlying DITA source. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-374) Invalid URL with Derby Client when connecting to Network Server causes protocol exception.
[ http://issues.apache.org/jira/browse/DERBY-374?page=all ] Andrew McIntyre updated DERBY-374: -- Fix Version: 10.2.0.0 (was: 10.1.1.0) Version: 10.2.0.0 Moving to 10.2. > Invalid URL with Derby Client when connecting to Network Server causes > protocol exception. > -- > > Key: DERBY-374 > URL: http://issues.apache.org/jira/browse/DERBY-374 > Project: Derby > Type: Bug > Components: Network Client, Network Server > Versions: 10.2.0.0, 10.1.1.0 > Environment: Network Server running with Derby client on Windows 2000. > Reporter: A B > Fix For: 10.2.0.0 > > If using the Derby Client to connect to the Derby Network Server, there are > some cases where an invalid URL will cause a protocol exception instead of > throwing a proper error. The two cases I've found are as follow: > 1) Use of a colon to separate attributes: > When connecting to the server with JCC, a colon is required to demarcate the > Derby attributes from the JCC attributes. For the Derby Client, however, the > colon is not a valid part of the URL, so use of it should return an error. > However, the result is a protocol exception: > ij> connect > 'jdbc:derby://localhost:1528/sample:user=someUsr;password=somePwd'; > agentThread[DRDAConnThread_9,5,main] > ERROR (no SQLState): A communication error has been detected. Communication > protocol being used: Reply.fill(). Communication API being used: > InputStream.read(). Location where the error was detected: > insufficient data. Communication function detecting the error: *. Protocol > specific error codes(s) TCP/IP SOCKETS > 2) Use of double-quotes to specify a full path to a database. > The use of double-quotes around a database path is required when connecting > to the server with JCC, but should be optional when using the Derby Client. > However, attempts to use the double-quotes doesn't work--on the contrary, it > throws a protocol exception: > ij> connect 'jdbc:derby://localhost:1528/"C:/myDBs/sample"'; > agentThread[DRDAConnThread_11,5,main] > ERROR (no SQLState): A communication error has been detected. Communication > protocol being used: Reply.fill(). Communication API being used: > InputStream.read(). Location where the error was detected: > insufficient data. Communication function detecting the error: *. Protocol > specific error codes(s) TCP/IP SOCKETS > Without quotes, the above example will work as expected. > I'm not sure if the problem is with the Derby client or the Network Server > (more investigation required). -- 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-375) Specification of incomplete server properties on command line causes NPE with NetworkServerControl when starting the server.
[ http://issues.apache.org/jira/browse/DERBY-375?page=all ] Andrew McIntyre updated DERBY-375: -- Fix Version: 10.2.0.0 (was: 10.1.1.0) Version: 10.2.0.0 Moving to 10.2 > Specification of incomplete server properties on command line causes NPE with > NetworkServerControl when starting the server. > > > Key: DERBY-375 > URL: http://issues.apache.org/jira/browse/DERBY-375 > Project: Derby > Type: Bug > Components: Network Server > Versions: 10.2.0.0, 10.1.1.0 > Environment: Running Derby Network Server and using command line API to > start the server. > Reporter: A B > Fix For: 10.2.0.0 > > When using the command line to start the Network Server, there a couple of > cases where if a property is specified on the command line but no value is > given (ex. "-Dderby.drda.maxThreads" instead of "-Dderby.drda.maxThreads=3"), > a Null Pointer Exception will result, when the correct behavior should be to > use some kind of default. > For example: > > java -Dderby.drda.maxThreads org.apache.derby.drda.NetworkServerControl > > start -p 1528 > java.lang.NullPointerException > at > org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(NetworkServerControlImpl.java) > at > org.apache.derby.impl.drda.NetworkServerControlImpl.consolePropertyMessageWork(NetworkServerControlImpl.java) > at > org.apache.derby.impl.drda.NetworkServerControlImpl.consolePropertyMessage(NetworkServerControlImpl.java) > at > org.apache.derby.impl.drda.NetworkServerControlImpl.getIntPropVal(NetworkServerControlImpl.java) > at > org.apache.derby.impl.drda.NetworkServerControlImpl.getPropertyInfo(NetworkServerControlImpl.java) > at > org.apache.derby.impl.drda.NetworkServerControlImpl.(NetworkServerControlImpl.java) > at > org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java) > Note that even though we see this NPE, it appears that the server still > starts up, although the startup may not be complete (subsequent attempts to > connect might lead to errors like "Invalid reply from network server: > Insufficient data."). > For other properties, this will just result in the default value being used, > which is the correct behavior. For example: > > java -Dderby.drda.host org.apache.derby.drda.NetworkServerControl start -p > > 1528 > Server is ready to accept connections on port 1528. -- 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-264) This enhancement to allow expressions in ORDER BY clause will require documentation changes.
[ http://issues.apache.org/jira/browse/DERBY-264?page=all ] Andrew McIntyre updated DERBY-264: -- Fix Version: 10.2.0.0 (was: 10.1.1.0) Version: 10.2.0.0 Environment: Moving to 10.2 as it appears no one is currently working on this. > This enhancement to allow expressions in ORDER BY clause will require > documentation changes. > > > Key: DERBY-264 > URL: http://issues.apache.org/jira/browse/DERBY-264 > Project: Derby > Type: Sub-task > Components: Documentation > Versions: 10.2.0.0, 10.1.1.0 > Reporter: Satheesh Bandaram > Priority: Minor > Fix For: 10.2.0.0 > > I can help if needed for documenting this enhancement. -- 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-348) example.html file for the SimpleApp does not describe the arguments accepted by the program
[ http://issues.apache.org/jira/browse/DERBY-348?page=all ]
Andrew McIntyre resolved DERBY-348:
---
Fix Version: 10.1.1.0
Resolution: Fixed
Committed to trunk with revision 202430. Will merge to 10.1 branch before
release.
> example.html file for the SimpleApp does not describe the arguments accepted
> by the program
> ---
>
> Key: DERBY-348
> URL: http://issues.apache.org/jira/browse/DERBY-348
> Project: Derby
> Type: Bug
> Components: Demos/Scripts
> Versions: 10.0.2.1, 10.0.2.0, 10.1.1.0
> Reporter: Stan Bradbury
> Priority: Minor
> Fix For: 10.1.1.0
> Attachments: derby348.zip
>
> The SimpleApp.java demo program supplied with Derby currently accepts two
> arguments and will soon (see JIRA entry: DERBY-247) accept a third that
> allows the application to run as a client to Network Server. Only 'embedded'
> is documented in the ${DERBY_INSTALL}/demo/simple/example.html file. The
> others should be added. The current undocumented argument is:
> 'jccjdbcclient' - will use the JCC client driver to access Network Server
> The new argument might be:
> 'derbyclient' - will use the Net client driver to access Network Server
> This brief description of the program using the derby client might help in
> this update:
> To use the SimpleApp in client mode only the directory containing the
> SimpleApp and the netclient.jar file are needed in the CLASSPATH. By passing
> in 'derbyclient' as an argument the program will load the client driver
> rather than start the Derby engine. The parseArguments() method (line 230)
> changes two key strings. The variables 'driver' and 'protocol' are set to
> the client driver values. With these new definitions the go() method loads
> the client driver at line 73 and creates the client URL at lines 93-94. With
> the variables expanded these lines will look like this:
> line 76: Class.forName("org.apache.derby.jdbc.ClientDriver")
> line 93-94: conn = DriverManager.getConnection("jdbc:derby://localhost:1527/"
>+ "derbyDB;create=true", props);
> As in the embedded example the connection will create the database if it does
> not exist and boot derbyDB if it has not already been loaded by the Network
> Server. Note that the application is well behaved and does not shutdown the
> database when operating as a client.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-412) Connetion toString should show type information and the meaning of the identifier that it prints
[ http://issues.apache.org/jira/browse/DERBY-412?page=all ]
Andrew McIntyre updated DERBY-412:
--
Fix Version: (was: 10.1.1.0)
Moving Fix In to 10.2.
> Connetion toString should show type information and the meaning of the
> identifier that it prints
> -
>
> Key: DERBY-412
> URL: http://issues.apache.org/jira/browse/DERBY-412
> Project: Derby
> Type: Bug
> Versions: 10.1.1.0, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: David Van Couvering
> Fix For: 10.2.0.0
>
> After the change for DERBY-243 the connection toString() output is an
> integer which correspond to SESSIONID. The output should identify the type
> and also the meaning of the identifier that it prints. Perhaps a format that
> appends the default toString output with the sessionid information as it
> prints in the derby.log would be more informative.
> [EMAIL PROTECTED] (SESSONID = 2)
> Ultimately this could be expanded to included other diagnostic information e.g
> [EMAIL PROTECTED] (XID = 132), (SESSIONID = 5), (DATABASE = wombat), (DRDAID
> = NF01.H324-940125304405039114{7})
--
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-416) Parameter in one of the error messages is not replaced by the desired value.
[ http://issues.apache.org/jira/browse/DERBY-416?page=all ]
Andrew McIntyre resolved DERBY-416:
---
Fix Version: 10.1.1.0
10.2.0.0
Resolution: Fixed
Committed, revision 202492 to trunk. Will merge to 10.1 branch before release.
> Parameter in one of the error messages is not replaced by the desired value.
>
>
> Key: DERBY-416
> URL: http://issues.apache.org/jira/browse/DERBY-416
> Project: Derby
> Type: Bug
> Components: JDBC
> Versions: 10.1.1.0
> Reporter: Rajesh Kartha
> Assignee: Mamta A. Satoor
> Fix For: 10.1.1.0, 10.2.0.0
> Attachments: Derby416FixErrorText062905.txt
>
> In one of the error messages the parameter does not get replaced with the
> actual value to make the message meaningful.
> Here is a sample message:
> ===> XJ084=Column does not correspond to a column in the base table. Cant
> issue {0} on this column.
> More info:
> Table:
> ij version 10.1
> ij> connect 'jdbc:derby:tvtm';
> ij> select * from t1;
> C1 |C2
>
> 1 |aa
> 2 |bb
> 3 |cc
> 3 rows selected
> To get the above message use the following Java snippet:
> private static void runTestXJ084(Connection conn){
> try{
> Statement stmt =
> conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE);
> ResultSet rs = stmt.executeQuery("SELECT 1, 2 FROM t1
> FOR UPDATE");
> rs.next();
> rs.updateInt(1,22);
> }catch (SQLException sqe){
> System.out.println(" ===> "+ sqe.getSQLState()+"="+
> sqe.getMessage());
> }
> }
> The message obtained is:
> ===> XJ084=Column does not correspond to a column in the base table. Cant
> issue {0} on this column.
> The {0} above should have been replaced by the appropriate operation perfomed
> - update in the above case.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (DERBY-417) Beetle6038.java store test fails on Mac OS X
Beetle6038.java store test fails on Mac OS X Key: DERBY-417 URL: http://issues.apache.org/jira/browse/DERBY-417 Project: Derby Type: Test Components: Test Versions: 10.1.1.0, 10.2.0.0 Environment: Mac OS X 10.4.1 with JDK 1.4.2 Reporter: Andrew McIntyre Priority: Trivial Fix For: 10.2.0.0 Beetle6038.java test in the storemore suite fails on Mac OS X because the test attempts to set the encryption provider for the test based on the value of the system property java.vm.vendor. It assumes that if java.vm.vendor does not start with "Sun" that the IBM JCE encryption provider should be used. See org.apache.derbyTesting.functionTests.tests.store.Beetle6038, lines 42-49. Since, in most cases, Derby can choose the correct encryption provider, I think the best solution to this particular issue is to not specify a particular implementation of the JCE provider, regardless of the JVM vendor. i.e. lines 42-49 can probably be wholly replaced by: dburl="jdbc:derby:Beetle6038Db;create=true;dataEncryption=true;bootPassword=Thursday;encryptionAlgorithm=DES/CBC/NoPadding"; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-384) Doc Review (CLOSED TO FURTHER COMMENTS): Tuning Derby
[ http://issues.apache.org/jira/browse/DERBY-384?page=all ] Andrew McIntyre resolved DERBY-384: --- Resolution: Fixed Committed, revision 208690. > Doc Review (CLOSED TO FURTHER COMMENTS): Tuning Derby > - > > Key: DERBY-384 > URL: http://issues.apache.org/jira/browse/DERBY-384 > Project: Derby > Type: Improvement > Components: Documentation > Environment: all > Reporter: Jeff Levitt > Priority: Minor > Fix For: 10.1.1.0 > Attachments: derby384.diff > > This issue tracks comments for the manual known as Tuning Derby. The deadline > for posting comments was Tuesday, June 28, noon Pacific time. > PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have > additional comments, please open a JIRA issue for a fixin in a future > release, as there is not enough time to incorporate additional comments. > Some guidelines to follow when posting comments to this issue are: > - Try to make clear and concise comments about what you want changed whenever > possible. Provide concrete comments that say "Please change to > " instead of generic comments like "This section needs to be > rewritten." > - If you're reviewing the HTML Files copy, include the URL for the page in > the review comment. Obtain the URL like this: > * highlight the topic in the left frame > * right click > * choose "Properties" > * copy and paste the address in the pop up box. > - If you're reviewing the PDF copy, in the review comment: > * Include the page number for the PDF, and indicate whether the number is > the PDF sheet number or the printed page number. > * Include the title of the section that the problem occurs in. If it's in > a subsection, try to include the hierarchy of titles. > - Please don't review the HTML Book copy -- it'll be time consuming to match > up that copy with the underlying DITA source. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-379) Doc review (CLOSED TO FURTHER COMMENTS): Getting Started with Derby
[ http://issues.apache.org/jira/browse/DERBY-379?page=all ] Andrew McIntyre resolved DERBY-379: --- Resolution: Fixed Committed modified patch, revision 208692. > Doc review (CLOSED TO FURTHER COMMENTS): Getting Started with Derby > > > Key: DERBY-379 > URL: http://issues.apache.org/jira/browse/DERBY-379 > Project: Derby > Type: Improvement > Components: Documentation > Environment: all > Reporter: Jeff Levitt > Priority: Minor > Fix For: 10.1.1.0 > Attachments: derby379modified.diff > > This issue tracks comments for the Getting Started with Derby manual. The > deadline for posting comments was Tuesday, June 28, noon Pacific time. > PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have > additional comments, please open a JIRA issue for a fixin in a future > release, as there is not enough time to incorporate additional comments. > Some guidelines to follow when posting comments to this issue are: > - Try to make clear and concise comments about what you want changed whenever > possible. Provide concrete comments that say "Please change to > " instead of generic comments like "This section needs to be > rewritten." > - If you're reviewing the HTML Files copy, include the URL for the page in > the review comment. Obtain the URL like this: > * highlight the topic in the left frame > * right click > * choose "Properties" > * copy and paste the address in the pop up box. > - If you're reviewing the PDF copy, in the review comment: > * Include the page number for the PDF, and indicate whether the number is > the PDF sheet number or the printed page number. > * Include the title of the section that the problem occurs in. If it's in > a subsection, try to include the hierarchy of titles. > - Please don't review the HTML Book copy -- it'll be time consuming to match > up that copy with the underlying DITA source. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-422) Create a new sample database for use in examples in the manuals
Create a new sample database for use in examples in the manuals --- Key: DERBY-422 URL: http://issues.apache.org/jira/browse/DERBY-422 Project: Derby Type: Improvement Components: Demos/Scripts Versions: 10.1.1.0, 10.2.0.0 Reporter: Andrew McIntyre The Derby manuals still refer to Cloudscape example databases that were unable to be contributed to Derby. A new sample database should be created which is complex enough to serve as the basis for examples in the various manuals. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-383) Doc Review (CLOSED TO FURTHER COMMENTS): Derby Tools and Utilities Guide
[ http://issues.apache.org/jira/browse/DERBY-383?page=all ] Andrew McIntyre resolved DERBY-383: --- Resolution: Fixed Committed, revision 208693. > Doc Review (CLOSED TO FURTHER COMMENTS): Derby Tools and Utilities Guide > > > Key: DERBY-383 > URL: http://issues.apache.org/jira/browse/DERBY-383 > Project: Derby > Type: Improvement > Components: Documentation > Environment: all > Reporter: Jeff Levitt > Priority: Minor > Fix For: 10.1.1.0 > Attachments: derby383.diff > > This issue tracks comments for the Derby Tools and Utilities Guide. The > deadline for posting comments was Tuesday, June 28, noon Pacific time. > PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have > additional comments, please open a JIRA issue for a fixin in a future > release, as there is not enough time to incorporate additional comments. > Some guidelines to follow when posting comments to this issue are: > - Try to make clear and concise comments about what you want changed whenever > possible. Provide concrete comments that say "Please change to > " instead of generic comments like "This section needs to be > rewritten." > - If you're reviewing the HTML Files copy, include the URL for the page in > the review comment. Obtain the URL like this: > * highlight the topic in the left frame > * right click > * choose "Properties" > * copy and paste the address in the pop up box. > - If you're reviewing the PDF copy, in the review comment: > * Include the page number for the PDF, and indicate whether the number is > the PDF sheet number or the printed page number. > * Include the title of the section that the problem occurs in. If it's in > a subsection, try to include the hierarchy of titles. > - Please don't review the HTML Book copy -- it'll be time consuming to match > up that copy with the underlying DITA source. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-381) Doc review (CLOSED TO FURTHER COMMENTS): Derby Server and Admin Guide
[ http://issues.apache.org/jira/browse/DERBY-381?page=all ] Andrew McIntyre resolved DERBY-381: --- Resolution: Fixed Committed, revision 208694. > Doc review (CLOSED TO FURTHER COMMENTS): Derby Server and Admin Guide > - > > Key: DERBY-381 > URL: http://issues.apache.org/jira/browse/DERBY-381 > Project: Derby > Type: Improvement > Components: Documentation > Environment: all > Reporter: Jeff Levitt > Priority: Minor > Fix For: 10.1.1.0 > Attachments: derby381.diff > > This issue tracks comments for the Derby Server and Administration Guide. The > deadline for posting comments WAS Tuesday, June 28, noon Pacific time. > PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have > additional comments, please open a JIRA issue for a fixin in a future > release, as there is not enough time to incorporate additional comments. > Some guidelines to follow when posting comments to this issue are: > - Try to make clear and concise comments about what you want changed whenever > possible. Provide concrete comments that say "Please change to > " instead of generic comments like "This section needs to be > rewritten." > - If you're reviewing the HTML Files copy, include the URL for the page in > the review comment. Obtain the URL like this: > * highlight the topic in the left frame > * right click > * choose "Properties" > * copy and paste the address in the pop up box. > - If you're reviewing the PDF copy, in the review comment: > * Include the page number for the PDF, and indicate whether the number is > the PDF sheet number or the printed page number. > * Include the title of the section that the problem occurs in. If it's in > a subsection, try to include the hierarchy of titles. > - Please don't review the HTML Book copy -- it'll be time consuming to match > up that copy with the underlying DITA source. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-377) There is no information available in the manuals on how to upgrade a database from 10.0 to 10.1 version.
[ http://issues.apache.org/jira/browse/DERBY-377?page=all ] Andrew McIntyre resolved DERBY-377: --- Resolution: Fixed Committed, revision 208695. > There is no information available in the manuals on how to upgrade a > database from 10.0 to 10.1 version. > > > Key: DERBY-377 > URL: http://issues.apache.org/jira/browse/DERBY-377 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.1.1.0 > Reporter: Suresh Thalamati > Fix For: 10.1.1.0 > Attachments: derby377modified.zip > > I could not find any info in the 10.1 Alpha manuals on how to upgrade a > 10.0 database to use > a 10.1 engine in full upgrade mode or software mode. I think this feature > is implemented in the > 10.1 code line , but not documented yet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-420) missing classes in published javadoc & incorrect copyright date
[ http://issues.apache.org/jira/browse/DERBY-420?page=comments#action_12314837 ] Andrew McIntyre commented on DERBY-420: --- I checked in a fix for the missing classes to the trunk and posted a copy for review on my public_html: http://people.apache.org/~fuzzylogic/publishedapi/ I'll merge this over to the branch shortly. > missing classes in published javadoc & incorrect copyright date > --- > > Key: DERBY-420 > URL: http://issues.apache.org/jira/browse/DERBY-420 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.1.1.0 > Reporter: Daniel John Debrunner > Assignee: Daniel John Debrunner > Fix For: 10.1.1.0 > > Missing classes > EmbeddedSimpleDataSource > dblook > All new client classes (driver, data source implementations) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-382) Doc Review (CLOSED TO FURTHER COMMENTS): Derby Reference Manual
[ http://issues.apache.org/jira/browse/DERBY-382?page=all ] Andrew McIntyre resolved DERBY-382: --- Resolution: Fixed Applied provided patch with revision 208698. Further comments should be attached to issue DERBY-423. > Doc Review (CLOSED TO FURTHER COMMENTS): Derby Reference Manual > --- > > Key: DERBY-382 > URL: http://issues.apache.org/jira/browse/DERBY-382 > Project: Derby > Type: Improvement > Components: Documentation > Environment: all > Reporter: Jeff Levitt > Priority: Minor > Fix For: 10.1.1.0 > Attachments: derby382.diff > > This issue tracks comments for the Derby Reference Manual. The deadline for > posting comments was Tuesday, June 28, noon Pacific time. > PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have > additional comments, please open a JIRA issue for a fixin in a future > release, as there is not enough time to incorporate additional comments. > Some guidelines to follow when posting comments to this issue are: > - Try to make clear and concise comments about what you want changed whenever > possible. Provide concrete comments that say "Please change to > " instead of generic comments like "This section needs to be > rewritten." > - If you're reviewing the HTML Files copy, include the URL for the page in > the review comment. Obtain the URL like this: > * highlight the topic in the left frame > * right click > * choose "Properties" > * copy and paste the address in the pop up box. > - If you're reviewing the PDF copy, in the review comment: > * Include the page number for the PDF, and indicate whether the number is > the PDF sheet number or the printed page number. > * Include the title of the section that the problem occurs in. If it's in > a subsection, try to include the hierarchy of titles. > - Please don't review the HTML Book copy -- it'll be time consuming to match > up that copy with the underlying DITA source. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-377) There is no information available in the manuals on how to upgrade a database from 10.0 to 10.1 version.
[ http://issues.apache.org/jira/browse/DERBY-377?page=comments#action_12314852 ] Andrew McIntyre commented on DERBY-377: --- Jeff - The patch file provided in the zip, derby377modified.diff, did not contain the source file for tdevpreupgrade.html (presumably tdevpreupgrade.dita). If you could please attach that source file to this issue, i'll commit it. > There is no information available in the manuals on how to upgrade a > database from 10.0 to 10.1 version. > > > Key: DERBY-377 > URL: http://issues.apache.org/jira/browse/DERBY-377 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.1.1.0 > Reporter: Suresh Thalamati > Fix For: 10.1.1.0 > Attachments: derby377modified.zip > > I could not find any info in the 10.1 Alpha manuals on how to upgrade a > 10.0 database to use > a 10.1 engine in full upgrade mode or software mode. I think this feature > is implemented in the > 10.1 code line , but not documented yet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-377) There is no information available in the manuals on how to upgrade a database from 10.0 to 10.1 version.
[ http://issues.apache.org/jira/browse/DERBY-377?page=comments#action_12314853 ] Andrew McIntyre commented on DERBY-377: --- Jeff - The patch file provided in the zip, derby377modified.diff, did not contain the source file for tdevpreupgrade.html (presumably tdevpreupgrade.dita). If you could please attach that source file to this issue, i'll commit it. > There is no information available in the manuals on how to upgrade a > database from 10.0 to 10.1 version. > > > Key: DERBY-377 > URL: http://issues.apache.org/jira/browse/DERBY-377 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.1.1.0 > Reporter: Suresh Thalamati > Fix For: 10.1.1.0 > Attachments: derby377modified.zip > > I could not find any info in the 10.1 Alpha manuals on how to upgrade a > 10.0 database to use > a 10.1 engine in full upgrade mode or software mode. I think this feature > is implemented in the > 10.1 code line , but not documented yet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-377) There is no information available in the manuals on how to upgrade a database from 10.0 to 10.1 version.
[ http://issues.apache.org/jira/browse/DERBY-377?page=comments#action_12314868 ] Andrew McIntyre commented on DERBY-377: --- I have added tdevpreupgrade.dita from the provided patch. thanks Jeff! > There is no information available in the manuals on how to upgrade a > database from 10.0 to 10.1 version. > > > Key: DERBY-377 > URL: http://issues.apache.org/jira/browse/DERBY-377 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.1.1.0 > Reporter: Suresh Thalamati > Fix For: 10.1.1.0 > Attachments: derby377addendum.diff, derby377modified.zip > > I could not find any info in the 10.1 Alpha manuals on how to upgrade a > 10.0 database to use > a 10.1 engine in full upgrade mode or software mode. I think this feature > is implemented in the > 10.1 code line , but not documented yet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-380) Doc Review (CLOSED TO FURTHER COMMENTS): Derby Developer's Guide
[ http://issues.apache.org/jira/browse/DERBY-380?page=all ] Andrew McIntyre resolved DERBY-380: --- Resolution: Fixed Committed, revision 208734. Additional comments should be attached to DERBY-425. > Doc Review (CLOSED TO FURTHER COMMENTS): Derby Developer's Guide > > > Key: DERBY-380 > URL: http://issues.apache.org/jira/browse/DERBY-380 > Project: Derby > Type: Improvement > Components: Documentation > Environment: all > Reporter: Jeff Levitt > Priority: Minor > Fix For: 10.1.1.0 > Attachments: derby380.diff > > This issue tracks comments for the Derby Developer's Guide. The deadline for > posting comments was Tuesday, June 28, noon Pacific time. > PLEASE DO NOT POST ADDITIONAL COMMENTS TO THIS JIRA ISSUE. If you have > additional comments, please open a JIRA issue for a fixin in a future > release, as there is not enough time to incorporate additional comments. > Some guidelines to follow when posting comments to this issue are: > - Try to make clear and concise comments about what you want changed whenever > possible. Provide concrete comments that say "Please change to > " instead of generic comments like "This section needs to be > rewritten." > - If you're reviewing the HTML Files copy, include the URL for the page in > the review comment. Obtain the URL like this: > * highlight the topic in the left frame > * right click > * choose "Properties" > * copy and paste the address in the pop up box. > - If you're reviewing the PDF copy, in the review comment: > * Include the page number for the PDF, and indicate whether the number is > the PDF sheet number or the printed page number. > * Include the title of the section that the problem occurs in. If it's in > a subsection, try to include the hierarchy of titles. > - Please don't review the HTML Book copy -- it'll be time consuming to match > up that copy with the underlying DITA source. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-420) missing classes in published javadoc & incorrect copyright date
[ http://issues.apache.org/jira/browse/DERBY-420?page=comments#action_12314908 ] Andrew McIntyre commented on DERBY-420: --- Merged to 10.1 branch with 208776 > missing classes in published javadoc & incorrect copyright date > --- > > Key: DERBY-420 > URL: http://issues.apache.org/jira/browse/DERBY-420 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.1.1.0 > Reporter: Daniel John Debrunner > Assignee: Daniel John Debrunner > Fix For: 10.1.1.0 > > Missing classes > EmbeddedSimpleDataSource > dblook > All new client classes (driver, data source implementations) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1) Can't create a new db on OS X
[ http://issues.apache.org/jira/browse/DERBY-1?page=comments#action_12315055 ] Andrew McIntyre commented on DERBY-1: - There is a regression of DERBY-1 in the J2SE 5.0 Release 1 JVM for Mac OS X 10.4. The issue has been fixed in the JDK 1.4.2 JVM for Mac OS X 10.4, which is the default JVM, but identical errors to those seen on Mac OS X 10.3 with JDK 1.4.2 wiill be encountered with the 5.0 JVM for Mac OS X 10.4. > 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.D
[jira] Assigned: (DERBY-440) derby.jar has directory (package) entries in it which are not required
[ http://issues.apache.org/jira/browse/DERBY-440?page=all ] Andrew McIntyre reassigned DERBY-440: - Assign To: Andrew McIntyre > derby.jar has directory (package) entries in it which are not required > -- > > Key: DERBY-440 > URL: http://issues.apache.org/jira/browse/DERBY-440 > Project: Derby > Type: Bug > Components: Build tools > Versions: 10.1.1.0 > Reporter: Daniel John Debrunner > Assignee: Andrew McIntyre > Priority: Minor > > The derby.jar is correctly created by the top-level buil.xml with the > attribute filesonly=true. > However the subsequent update of the jar file to add the locale files, > partially extracted here, does not include the filesonly attribute, so the > directory entries are added in. > around line 757 > update="true" > compress="true"> > Addingfilesonly="true" to this target solved the problem. > Similar changes are probably needed for the other derby jar files and should > be addressed with this bug -- 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-440) derby.jar has directory (package) entries in it which are not required
[ http://issues.apache.org/jira/browse/DERBY-440?page=comments#action_12315890 ] Andrew McIntyre commented on DERBY-440: --- Dan: I was planning on fixing this, since it's so simple, but it looks like you beat me to it with revision 216826. :-) This should probably be fixed in the 10.1 branch as well, and maybe even 10.0. Would you like me to merge the entire fix for DERBY-419 over to 10.1, or should I just fix this particular issue there? > derby.jar has directory (package) entries in it which are not required > -- > > Key: DERBY-440 > URL: http://issues.apache.org/jira/browse/DERBY-440 > Project: Derby > Type: Bug > Components: Build tools > Versions: 10.1.1.0 > Reporter: Daniel John Debrunner > Assignee: Andrew McIntyre > Priority: Minor > > The derby.jar is correctly created by the top-level buil.xml with the > attribute filesonly=true. > However the subsequent update of the jar file to add the locale files, > partially extracted here, does not include the filesonly attribute, so the > directory entries are added in. > around line 757 > update="true" > compress="true"> > Addingfilesonly="true" to this target solved the problem. > Similar changes are probably needed for the other derby jar files and should > be addressed with this bug -- 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-440) derby.jar has directory (package) entries in it which are not required
[ http://issues.apache.org/jira/browse/DERBY-440?page=all ] Andrew McIntyre closed DERBY-440: - Fix Version: 10.1.1.1 10.2.0.0 Resolution: Fixed Merged fix for DERBY-419 and DERBY-440 into 10.1 branch with revision 219288. > derby.jar has directory (package) entries in it which are not required > -- > > Key: DERBY-440 > URL: http://issues.apache.org/jira/browse/DERBY-440 > Project: Derby > Type: Bug > Components: Build tools > Versions: 10.1.1.0 > Reporter: Daniel John Debrunner > Assignee: Andrew McIntyre > Priority: Minor > Fix For: 10.1.1.1, 10.2.0.0 > > The derby.jar is correctly created by the top-level buil.xml with the > attribute filesonly=true. > However the subsequent update of the jar file to add the locale files, > partially extracted here, does not include the filesonly attribute, so the > directory entries are added in. > around line 757 > update="true" > compress="true"> > Addingfilesonly="true" to this target solved the problem. > Similar changes are probably needed for the other derby jar files and should > be addressed with this bug -- 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-409) ClientDataSource setConnectionAttributes("create=true") fails with "An attempt was made to access a database, mydbcreate=true, which was not found."
[ http://issues.apache.org/jira/browse/DERBY-409?page=all ]
Andrew McIntyre updated DERBY-409:
--
Fix Version: (was: 10.1.1.0)
(was: 10.1.1.1)
Setting Fix in to 10.2.0.0 only, as the fix has only gone into the trunk.
> ClientDataSource setConnectionAttributes("create=true") fails with "An
> attempt was made to access a database, mydbcreate=true, which was not found."
> --
>
> Key: DERBY-409
> URL: http://issues.apache.org/jira/browse/DERBY-409
> Project: Derby
> Type: Bug
> Versions: 10.1.1.0, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Philip Wilder
> Fix For: 10.2.0.0
> Attachments: ConnectionAttributes.java, Derby409.patch
>
> ClientDataSource setConnectionAttributes("create=true") fails with "An
> attempt was made to access a database, mydbcreate=true, which was not found."
> The method does not seem to insert a semicolon before the attributes.
> run attached repro to produce the error below
> $java ConnectionAttributes
> embedded setConnectionAttributes
> client setConnectionAttributes
> org.apache.derby.client.am.DisconnectException: The application server
> rejected establishment of the connection. An attempt was made to access a
> database, mydbcreate=true, which was not found.
> at
> org.apache.derby.client.net.NetConnectionReply.parseRDBNFNRM(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.initialize(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.(NetConnection.java)
> at
> org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java)
> at
> org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java)
> at ConnectionAttributes.main(ConnectionAttributes.java:28)
> $
--
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-426) documentation need to be modified to reflect the derby-390 fix(once it is committed) , schem , table , column names need to be in case-sensitive form.
[ http://issues.apache.org/jira/browse/DERBY-426?page=all ] Andrew McIntyre resolved DERBY-426: --- Fix Version: 10.1.1.0 10.1.1.1 10.2.0.0 Resolution: Fixed Committed to trunk (225427) and 10.1 doc branch (225428). > documentation need to be modified to reflect the derby-390 fix(once it is > committed) , schem , table , column names need to be in case-sensitive form. > --- > > Key: DERBY-426 > URL: http://issues.apache.org/jira/browse/DERBY-426 > Project: Derby > Type: Sub-task > Components: Documentation > Versions: 10.1.1.0 > Reporter: Suresh Thalamati > Fix For: 10.1.1.0, 10.1.1.1, 10.2.0.0 > Attachments: derby426modified.zip > > Tools utilities Guide: Using bulk import/export chapter: > BulkImport/ Arguments to the import procedure section: add the following in > the end: > If you created a schema, table or column name as a non-delimited identifier, > you must pass the name in all upper case. If you created a schema, table or > column name as a delimited identifier, you must pass the name in the same > case as it was created. > BulkExport/Arguments to the export procedure: add the following in the end: > If you have created a schema or table name as a non-delimited identifier, > you must pass the name in all upper case. If you created a schema or table > name as a delimited identifier, you must pass the name in the same case as it > was created. > Examples of bulk import and export section: Add the following two examples > to this section: > The following example shows how to import data into the Order table (this > table was created using delimited quotes to specify the name becuase the > word 'Order' is a SQL reserved word) table in a sample database from the > myfile.del file. > CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE > (null,'Order','myfile.del',null,null,null,0); > The following example shows how to export data from the Order table (this > table was created using delimited quotes to specify the name becuase the > word 'Order' is a SQL reserved word) in a sample database from the > myfile.del file. > CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE (null,'Order','myfile.del',null,null,null); > Modify the table name 'staff' to all upper case 'STAFF' > for all import/export statements except for EXPORT_QUERY example. > for example: > CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE (null,'staff','myfile.del',null,null, > null,0); > toCALL SYSCS_UTIL.SYSCS_IMPORT_TABLE > (null,'STAFF,'myfile.del',null,null,null,0); > Importing into tables with identity columns section : modify table name > 'tab1' to 'TAB1' and all column names > also to upper case: > CALL SYSCS_UTIL.SYSCS_IMPORT_DATA (NULL, 'tab1', 'c1,c3,c4' , null, > 'myfile.del',null, null,null,0) > to > CALL SYSCS_UTIL.SYSCS_IMPORT_DATA (NULL, 'TAB1', 'C1,C3,C4' , null, > 'myfile.del',null, null,null,0) > CALL SYSCS_UTIL.SYSCS_IMPORT_DATA (NULL, 'tab1', 'c1,c3,c4' , > '1,3,4','empfile.del',null, null,null,0) > to > CALL SYSCS_UTIL.SYSCS_IMPORT_DATA (NULL, 'TAB1', 'C1,C3,C4' , > '1,3,4','empfile.del',null, null,null,0) > Executing import/export procedures from JDBC: modify > ps.setString(2,"staff"); > to > ps.setString(2,"STAFF"); > CODESET values for import/export section: > CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE > (NULL,'staff','staff.dat',NULL,NULL,'UTF-8') > to > CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE(NULL,'STAFF','staff.dat',NULL,NULL,'UTF-8') > and > CALL > SYSCS_UTIL.SYSCS_IMPORT_TABLE(NULL,'STAFF','staff.dat',NULL,NULL,'UTF-8',0) > In the REFERENCE Book Please do the following changes to import/export > procedures: > SYSCS_UTIL.SYSCS_EXPORT_TABLE: > add the following before the example: > If you have created a schema or table name as a non-delimited identifier, > you must pass the name in all upper case. If you created a schema or table > name as a delimited identifier, you must pass the name in the same case as it > was created. > modify tablename 'staff' to upper case 'STAFF' > CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE (null, 'staff', 'myfile.del', null, null, > null) > to > CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE (null, 'STAFF', 'myfile.del', null, null, > null) > SYSCS_UTIL.SYSCS_IMPORT_TABLE section: > add the following before the example: > If you created a schema or table name as a non-delimited identifier, you > must pass the name in all upper case. If you created a schema or table name > as a delimited identifier, you must pass the name in the same case as it was > created. > modify table name 'staff' to 'STAFF' > CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE(null, 'staff', 'c:/output/myfile.del', > ';', '%', null,0); > to > CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE(null, 'STAFF', 'c:/output/myfile.del', > ';', '%', null,0); > SYSCS_UTIL.SYSCS_I
[jira] Created: (DERBY-490) Derby release pages should utilize the mirrors to distribute the downloads
Derby release pages should utilize the mirrors to distribute the downloads -- Key: DERBY-490 URL: http://issues.apache.org/jira/browse/DERBY-490 Project: Derby Type: Task Components: Web Site Versions: 10.0.2.0, 10.1.1.0 Reporter: Andrew McIntyre Priority: Minor Fix For: 10.2.0.0 The Derby releases pages on the downloads page should use the Apache mirrors for distributing the actual downloads. See http://www.apache.org/dev/mirrors.html and http://www.apache.org/dev/mirror-step-by-step.html for more information. -- 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-489) Improvements to the related links for the Getting Started Guide
[ http://issues.apache.org/jira/browse/DERBY-489?page=all ] Andrew McIntyre resolved DERBY-489: --- Fix Version: (was: 10.1.1.1) Resolution: Fixed Committed to trunk (revision 227515). > Improvements to the related links for the Getting Started Guide > --- > > Key: DERBY-489 > URL: http://issues.apache.org/jira/browse/DERBY-489 > Project: Derby > Type: Improvement > Components: Documentation > Environment: all > Reporter: Jeff Levitt > Assignee: Jeff Levitt > Priority: Minor > Fix For: 10.2.0.0 > Attachments: derbygsreltableupdates.diff > > Creating an entry to submit the patch discussed here: > http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/[EMAIL > PROTECTED] > With no negative feedback and approval from some as discussed here: > http://mail-archives.apache.org/mod_mbox/db-derby-dev/200508.mbox/[EMAIL > PROTECTED] > View the output here: > http://derby.mylevita.com/getstart/ -- 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_12317732 ] Andrew McIntyre commented on DERBY-1: - Barnet, Are you sure you are setting the property derby.storage.fileSyncTransactionLog=true *every* time you start up Derby and connect to the database? You must set this system property every time you start up Derby in order for it to work properly on Mac OS X 10.4 with J2SE 1.5 (JDK 1.5). I am able to create a database and insert data into tables in subsequent sessions so long as I set that system property every time. FYI, I reported the regression to Apple about a month ago, so they are aware of the problem. > 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.(Embed
[jira] Resolved: (DERBY-490) Derby release pages should utilize the mirrors to distribute the downloads
[ http://issues.apache.org/jira/browse/DERBY-490?page=all ] Andrew McIntyre resolved DERBY-490: --- Fix Version: 10.1.1.0 (was: 10.2.0.0) Resolution: Fixed Assign To: Andrew McIntyre Updated 10.1.1.0 release page to use the Apache mirrors instead of a local copy of the distributions with revision 231076. Will close once I verify that downloads from the mirrors are working. > Derby release pages should utilize the mirrors to distribute the downloads > -- > > Key: DERBY-490 > URL: http://issues.apache.org/jira/browse/DERBY-490 > Project: Derby > Type: Task > Components: Web Site > Versions: 10.0.2.0, 10.1.1.0 > Reporter: Andrew McIntyre > Assignee: Andrew McIntyre > Priority: Minor > Fix For: 10.1.1.0 > > The Derby releases pages on the downloads page should use the Apache mirrors > for distributing the actual downloads. See > http://www.apache.org/dev/mirrors.html and > http://www.apache.org/dev/mirror-step-by-step.html for more information. -- 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-490) Derby release pages should utilize the mirrors to distribute the downloads
[ http://issues.apache.org/jira/browse/DERBY-490?page=all ] Andrew McIntyre reopened DERBY-490: --- Problems with the mirror script have forced me to return the website to the previous state. Will try again tomorrow. > Derby release pages should utilize the mirrors to distribute the downloads > -- > > Key: DERBY-490 > URL: http://issues.apache.org/jira/browse/DERBY-490 > Project: Derby > Type: Task > Components: Web Site > Versions: 10.0.2.0, 10.1.1.0 > Reporter: Andrew McIntyre > Assignee: Andrew McIntyre > Priority: Minor > Fix For: 10.1.1.0 > > The Derby releases pages on the downloads page should use the Apache mirrors > for distributing the actual downloads. See > http://www.apache.org/dev/mirrors.html and > http://www.apache.org/dev/mirror-step-by-step.html for more information. -- 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-490) Derby release pages should utilize the mirrors to distribute the downloads
[ http://issues.apache.org/jira/browse/DERBY-490?page=all ] Andrew McIntyre closed DERBY-490: - Resolution: Fixed derby_downloads now redirects to release-10.1.1.0.cgi, which is working correctly. Downloads from the 10.1.1.0 page point to the mirror and work properly. http://db.apache.org/derby/releases/release-10.1.1.0.cgi Closing. > Derby release pages should utilize the mirrors to distribute the downloads > -- > > Key: DERBY-490 > URL: http://issues.apache.org/jira/browse/DERBY-490 > Project: Derby > Type: Task > Components: Web Site > Versions: 10.0.2.0, 10.1.1.0 > Reporter: Andrew McIntyre > Assignee: Andrew McIntyre > Priority: Minor > Fix For: 10.1.1.0 > > The Derby releases pages on the downloads page should use the Apache mirrors > for distributing the actual downloads. See > http://www.apache.org/dev/mirrors.html and > http://www.apache.org/dev/mirror-step-by-step.html for more information. -- 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-188) Update derby web site to forrest 0.7
[ http://issues.apache.org/jira/browse/DERBY-188?page=all ] Andrew McIntyre reassigned DERBY-188: - Assign To: Andrew McIntyre > Update derby web site to forrest 0.7 > > > Key: DERBY-188 > URL: http://issues.apache.org/jira/browse/DERBY-188 > Project: Derby > Type: Task > Components: Web Site > Reporter: Jean T. Anderson > Assignee: Andrew McIntyre > Priority: Minor > > Activity on dev@forrest.apache.org indicates that forrest 0.7 will be > released soon. See the thread starting at: > http://mail-archives.eu.apache.org/mod_mbox/forrest-dev/200503.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-188) Update derby web site to forrest 0.7
[ http://issues.apache.org/jira/browse/DERBY-188?page=all ] Andrew McIntyre updated DERBY-188: -- Attachment: derby188-stat.txt Made a pass at upgrading to Forrest 0.7, everything looks good. I'm only attaching the svn stat output of this change, because I cleaned up a lot of old files while I was at it (e.g. the manuals under build/site/manuals), and the svn diff output was huge (>15MB). Details of any particular change available on request. If there are no objections, I'd like to check this in tomorrow or Monday. > Update derby web site to forrest 0.7 > > > Key: DERBY-188 > URL: http://issues.apache.org/jira/browse/DERBY-188 > Project: Derby > Type: Task > Components: Web Site > Reporter: Jean T. Anderson > Assignee: Andrew McIntyre > Priority: Minor > Attachments: derby188-stat.txt > > Activity on dev@forrest.apache.org indicates that forrest 0.7 will be > released soon. See the thread starting at: > http://mail-archives.eu.apache.org/mod_mbox/forrest-dev/200503.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-188) Update derby web site to forrest 0.7
[ http://issues.apache.org/jira/browse/DERBY-188?page=all ] Andrew McIntyre resolved DERBY-188: --- Resolution: Fixed Checked in upgrade to 0.7 with svn revision 232402. > Update derby web site to forrest 0.7 > > > Key: DERBY-188 > URL: http://issues.apache.org/jira/browse/DERBY-188 > Project: Derby > Type: Task > Components: Web Site > Reporter: Jean T. Anderson > Assignee: Andrew McIntyre > Priority: Minor > Attachments: derby188-stat.txt > > Activity on dev@forrest.apache.org indicates that forrest 0.7 will be > released soon. See the thread starting at: > http://mail-archives.eu.apache.org/mod_mbox/forrest-dev/200503.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-188) Update derby web site to forrest 0.7
[ http://issues.apache.org/jira/browse/DERBY-188?page=comments#action_12318688 ] Andrew McIntyre commented on DERBY-188: --- By the way, for HTML content that you want Forrest to process as raw, include the file with the extension '.htm'. Forrest will not attempt to skin the HTML file and will include it as-is in the build output. > Update derby web site to forrest 0.7 > > > Key: DERBY-188 > URL: http://issues.apache.org/jira/browse/DERBY-188 > Project: Derby > Type: Task > Components: Web Site > Reporter: Jean T. Anderson > Assignee: Andrew McIntyre > Priority: Minor > Attachments: derby188-stat.txt > > Activity on dev@forrest.apache.org indicates that forrest 0.7 will be > released soon. See the thread starting at: > http://mail-archives.eu.apache.org/mod_mbox/forrest-dev/200503.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-507) 10.1 docs on the web does not reflect derby-426 checked into 10.1
[ http://issues.apache.org/jira/browse/DERBY-507?page=all ] Andrew McIntyre reassigned DERBY-507: - Assign To: Andrew McIntyre > 10.1 docs on the web does not reflect derby-426 checked into 10.1 > --- > > Key: DERBY-507 > URL: http://issues.apache.org/jira/browse/DERBY-507 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.1.1.0 > Reporter: Suresh Thalamati > Assignee: Andrew McIntyre > > code changes for derby-390 went into the 10.1 release , but documenetion > related to it does not seem to > have made it to the docs on the website. But it seems to have been checked > into 10.1 branch > comments by andrew in derby-426: > committed 10.1 doc branch (225428). -- 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-507) 10.1 docs on the web does not reflect derby-426 checked into 10.1
[ http://issues.apache.org/jira/browse/DERBY-507?page=all ] Andrew McIntyre resolved DERBY-507: --- Resolution: Fixed I have updated the 10.1 documentation on the website. It should become visible in the next 3-4 hours. Suresh, please check that the documentation reflects the DERBY-426 change after that time and close this issue if the update succeeded. > 10.1 docs on the web does not reflect derby-426 checked into 10.1 > --- > > Key: DERBY-507 > URL: http://issues.apache.org/jira/browse/DERBY-507 > Project: Derby > Type: Bug > Components: Documentation > Versions: 10.1.1.0 > Reporter: Suresh Thalamati > Assignee: Andrew McIntyre > > code changes for derby-390 went into the 10.1 release , but documenetion > related to it does not seem to > have made it to the docs on the website. But it seems to have been checked > into 10.1 branch > comments by andrew in derby-426: > committed 10.1 doc branch (225428). -- 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-487) Getting Started Guide has reference to incubator URL
[ http://issues.apache.org/jira/browse/DERBY-487?page=all ] Andrew McIntyre resolved DERBY-487: --- Fix Version: (was: 10.1.1.1) Resolution: Fixed Committed to trunk with revision 233397. > Getting Started Guide has reference to incubator URL > > > Key: DERBY-487 > URL: http://issues.apache.org/jira/browse/DERBY-487 > Project: Derby > Type: Task > Components: Documentation > Versions: 10.1.1.0 > Environment: all > Reporter: Jeff Levitt > Priority: Trivial > Fix For: 10.2.0.0 > Attachments: derbyinc.diff > > On http://db.apache.org/derby/docs/getstart/cgsinstallingderby.html > we have a reference to an incubator URL. Even though it will redirect, it > should probably be changed to the new URL format. -- 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-488) DatabaseMetaData.getColumns() fails on iSeries JDK 1.4 with verfier error on generated class.
[ http://issues.apache.org/jira/browse/DERBY-488?page=all ] Andrew McIntyre updated DERBY-488: -- Fix Version: 10.1.1.1 (was: 10.1.1.0) changing fixin to 10.1.1.1 > DatabaseMetaData.getColumns() fails on iSeries JDK 1.4 with verfier error on > generated class. > - > > Key: DERBY-488 > URL: http://issues.apache.org/jira/browse/DERBY-488 > Project: Derby > Type: Bug > Components: SQL > Versions: 10.1.1.0 > Reporter: Daniel John Debrunner > Assignee: Deepa Remesh > Fix For: 10.2.0.0, 10.1.1.1 > Attachments: patch488.txt > > Analysis shows that > -- > The problem is occurring starting at offset 2007 in method e23. There is an > invokeinterface to method setWidth(int, int, boolean) of class > VariableSizeDataValue. This invoke returns a value of class > DataValueDescriptor. That value is in turn stored in field e142 at offset > 2015 in method e23. The problem is that field e142 is a NumberDataValue, and > DataValueDescriptor is not a valid subclass of NumberDataValue. Thus the > store is not allowed. > -- > Looking at the generated setWidth() calls I see one in BinaryOperatorNode > where the return (DataValueDescriptor) is not cast to the type of the field > it is stored in. -- 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-448) delete on an empty table generates warning
[ http://issues.apache.org/jira/browse/DERBY-448?page=all ] Andrew McIntyre updated DERBY-448: -- Component: Tools (was: Build tools) > delete on an empty table generates warning > -- > > Key: DERBY-448 > URL: http://issues.apache.org/jira/browse/DERBY-448 > Project: Derby > Type: Bug > Components: Tools > Versions: 10.0.2.1 > Environment: Solaris > Reporter: simmi iyer > > 1. Launch ij to connect to Derby using embedded driver. > 2. Issue delete command at ij prompt > ij>delete from table ; > 3. This generates a warning > 0 rows inserted/updated/deleted > WARNING 02000: No row was found for FETCH, UPDATE or DELETE; or the result of > a query is an empty table. > There are two issues here: > 1. It should say 0 rows deleted instead of 0 rows inserted/deleted/updated. > 2. WARNING should not be shown. > thx > Simmi. -- 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-190) Derby build should be incremental
[ http://issues.apache.org/jira/browse/DERBY-190?page=comments#action_12319425 ] Andrew McIntyre commented on DERBY-190: --- David: you should commit your patch for this now. :-) > Derby build should be incremental > - > > Key: DERBY-190 > URL: http://issues.apache.org/jira/browse/DERBY-190 > Project: Derby > Type: Improvement > Components: Build tools > Versions: 10.0.2.2 > Reporter: David Van Couvering > Attachments: BUILDING.diff > > You should not have to clobber and rebuild from scratch each time you update > or modify your source. This is time-consuming and affects overall > productivity. -- 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-330) Many files do not have correct svn-properties
[ http://issues.apache.org/jira/browse/DERBY-330?page=comments#action_12319427 ] Andrew McIntyre commented on DERBY-330: --- Dyre: if you post your script, I'll look at committing the changes. > Many files do not have correct svn-properties > - > > Key: DERBY-330 > URL: http://issues.apache.org/jira/browse/DERBY-330 > Project: Derby > Type: Bug > Components: Build tools > Environment: Any > Reporter: Dyre Tjeldvoll > Priority: Trivial > > There are two problems with svn properties in Derby: > 1) A number of non-binary files do not have the svn:eol-style=native property > set. Some of these currently has CRLF (Windows-style) line terminators, > Example: > [EMAIL PROTECTED]/local/DERBY/d_rby-138$ file > ./plugins/eclipse/org.apache.derby.ui/src/org/apache/derby/ui/popup/actions/RemoveDerbyNature.java > ./plugins/eclipse/org.apache.derby.ui/src/org/apache/derby/ui/popup/actions/RemoveDerbyNature.java: > ASCII C program text, with CRLF line terminators > [EMAIL PROTECTED]/local/DERBY/d_rby-138$ svn proplist -v > ./plugins/eclipse/org.apache.derby.ui/src/org/apache/derby/ui/popup/actions/RemoveDerbyNature.java > whereas others have LF(Unix-style). > Example: > [EMAIL PROTECTED]/local/DERBY/d_rby-138$ file > ./plugins/eclipse/org.apache.derby.ui/src/org/apache/derby/ui/actions/SysInfoAction.java > ./plugins/eclipse/org.apache.derby.ui/src/org/apache/derby/ui/actions/SysInfoAction.java: > ASCII C program text > [EMAIL PROTECTED]/local/DERBY/d_rby-138$ svn proplist -v > ./plugins/eclipse/org.apache.derby.ui/src/org/apache/derby/ui/actions/SysInfoAction.java > Some of the files that don't have this property do instead have a property > called "snv:eol-style". I'm guessing this is a typo. > Example: > [EMAIL PROTECTED]/local/DERBY/d_rby-138$ svn proplist -v > java/testing/org/apache/derbyTesting/unitTests/crypto/T_CipherOFB.java > Properties on > 'java/testing/org/apache/derbyTesting/unitTests/crypto/T_CipherOFB.java': > snv:eol-style : native > 2) A seemingly arbitrary collection of files have the svn:executable property > set. To my knowledge, the only files in the Derby respository that should > have this property are the *.ksh and perhaps the *.bat scripts, (I don't know > if Windows cares about this property when the file has the .bat suffix). > Currently none of the *.ksh scripts have this property, but a number of java > source files (not all) have it. (If there is some reason to have this > property on other files, it should at least be done consistently throughout > the repository). > Example: > [EMAIL PROTECTED]/local/DERBY/d_rby-138$ svn proplist -v > java/drda/org/apache/derby/drda/NetworkServerControl.java > Properties on 'java/drda/org/apache/derby/drda/NetworkServerControl.java': > svn:executable : > svn:eol-style : native > [EMAIL PROTECTED]/local/DERBY/d_rby-138$ svn proplist -v > java/testing/org/apache/derbyTesting/unitTests/crypto/T_CipherOFB.java > Properties on > 'java/testing/org/apache/derbyTesting/unitTests/crypto/T_CipherOFB.java': > snv:eol-style : native > If I understand correctly it is not possible to create a patchfile that > contains property changes, so I guess a committer will have to do this. I'm > willing to create a script file containing all the svn commands that must be > run, as a "pseudo 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-140) complie derby on redhat9
[ http://issues.apache.org/jira/browse/DERBY-140?page=all ] Andrew McIntyre closed DERBY-140: - Resolution: Fixed Further questions about the build or regarding using or working with Derby should be directed at the derby-user or derby-dev mailing lists instead of JIRA. thanks! > complie derby on redhat9 > > > Key: DERBY-140 > URL: http://issues.apache.org/jira/browse/DERBY-140 > Project: Derby > Type: Test > Components: Build tools > Versions: 10.0.2.2 > Environment: redhat 9 , java 1.4 , java 1.3 > Reporter: mohame abd elsamei > > when trying to build a derby useing > > ant > i got these errors > i am new here and please some help :) > Thanks all > compile_iapi_jdbc_stmt: > [javac] Compiling 1 source file to > /export/prj/incubating-derby-10.0.2.1-src/classes > [javac] > /export/prj/incubating-derby-10.0.2.1-src/java/engine/org/apache/derby/iapi/jdbc/BrokeredStatement.java:384: > execute(java.lang.String) in java.sql.Statement cannot be applied to > (java.lang.String,int) > [javac] return getStatement().execute( sql, autoGeneratedKeys); > [javac] ^ > [javac] > /export/prj/incubating-derby-10.0.2.1-src/java/engine/org/apache/derby/iapi/jdbc/BrokeredStatement.java:392: > execute(java.lang.String) in java.sql.Statement cannot be applied to > (java.lang.String,int[]) > [javac] return getStatement().execute( sql, columnIndexes); > [javac]^ > [javac] > /export/prj/incubating-derby-10.0.2.1-src/java/engine/org/apache/derby/iapi/jdbc/BrokeredStatement.java:399: > execute(java.lang.String) in java.sql.Statement cannot be applied to > (java.lang.String,java.lang.String[]) > [javac] return getStatement().execute( sql, columnNames); > [javac]^ > [javac] > /export/prj/incubating-derby-10.0.2.1-src/java/engine/org/apache/derby/iapi/jdbc/BrokeredStatement.java:406: > executeUpdate(java.lang.String) in java.sql.Statement cannot be applied to > (java.lang.String,int) > [javac] int retVal = getStatement().executeUpdate( sql, > autoGeneratedKeys); > [javac] ^ > [javac] > /export/prj/incubating-derby-10.0.2.1-src/java/engine/org/apache/derby/iapi/jdbc/BrokeredStatement.java:414: > executeUpdate(java.lang.String) in java.sql.Statement cannot be applied to > (java.lang.String,int[]) > [javac] return getStatement().executeUpdate( sql, > columnIndexes); > [javac] ^ > [javac] > /export/prj/incubating-derby-10.0.2.1-src/java/engine/org/apache/derby/iapi/jdbc/BrokeredStatement.java:422: > executeUpdate(java.lang.String) in java.sql.Statement cannot be applied to > (java.lang.String,java.lang.String[]) > [javac] return getStatement().executeUpdate( sql, columnNames); -- 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-427) An error message when running in XA environment says cloudscape.LOG rather than derby.log
[ http://issues.apache.org/jira/browse/DERBY-427?page=all ] Andrew McIntyre resolved DERBY-427: --- Fix Version: 10.2.0.0 Resolution: Fixed Committed revision 233562 (trunk). > An error message when running in XA environment says cloudscape.LOG rather > than derby.log > - > > Key: DERBY-427 > URL: http://issues.apache.org/jira/browse/DERBY-427 > Project: Derby > Type: Bug > Components: Unknown > Versions: 10.2.0.0 > Reporter: Mamta A. Satoor > Priority: Minor > Fix For: 10.2.0.0 > > While trying to connect in ij under XA environment, I get an error message > which talks about looking into cloudscape.LOG rather than derby.log Here are > the steps to reproduce > Just have derbytools.jar in the classpath and try to connect using ij as > follows > java -Dij.exceptionTrace=true org.apache.derby.tools.ij > xa_datasource 'c:/dellater/db1drda'; > The ij window throws following exception > IJ ERROR: org.apache.derby.impl.tools.ij.ijException: EmbeddedXADataSource > not in classpath, please put derby.jar file in your classpath : > EmbeddedXADataSource not in classpath, please put derby.jar file in your > classpath (see cloudcape.LOG) > The error message should say (see derby.log) rather than (see cloudscape.LOG) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
