You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Mike Matrigali (JIRA)" <ji...@apache.org> on 2010/01/06 18:47:56 UTC

[jira] Updated: (DERBY-4038) On Z/OS store/access.sql fails with encryptionAES and encryptionDES

     [ https://issues.apache.org/jira/browse/DERBY-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Matrigali updated DERBY-4038:
----------------------------------


I would be fine getting the test to run without that property.  I did some investigation and don't see any reason for it for the validity of the test.  My best guess is this is one way a long time ago we used to try to avoid intermittent query plan / ordering problems.

Looking at the original test I see one of the results is as follows.  Any chance what you are seeing is not "different" lengths but different orders.  In that case I would say just throw an order by in and don't worry about the property:

ij> select LENGTH(a) from long2;
1
-----------
3240
3240
3240
3240
3240
3240
3240
3240
3240
3240
3024
3024
3024
3024
3024
3024
3024
3024
3024
3024

> On Z/OS store/access.sql fails with encryptionAES and encryptionDES
> -------------------------------------------------------------------
>
>                 Key: DERBY-4038
>                 URL: https://issues.apache.org/jira/browse/DERBY-4038
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 10.3.3.0
>         Environment: java version "1.6.0"
> Java(TM) SE Runtime Environment (build pmz6460sr3-20081108_01(SR3))
> IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 z/OS s390x-64 jvmmz6460-20081107_25433 (JIT enabled, AOT enabled)
> J9VM - 20081105_025433_BHdSMr
> JIT  - r9_20081031_1330
> GC   - 20081027_AB)
> JCL  - 20081106_01
> $ pwd
>            Reporter: Kathey Marsden
>            Priority: Minor
>         Attachments: access.diff, access.out, DERBY-4038.diff_1, DERBY-4038.diff_2, DERBY-4038.diff_3, runaccess.out
>
>
> On Z/OS access.sql fails for encryptionAES and encryptionDES. The diff is big but I can't quite make out what the problem is. Maybe just a change of query plans.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.