[
https://issues.apache.org/jira/browse/DERBY-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668890#action_12668890
]
Chip Hartney commented on DERBY-4032:
-------------------------------------
As I think about it more, I realize that the "corruption" in my prior scenarios
may have actually occurred during the reload process, itself. If that is the
case, then my patch would be of no use as it is designed to fix the index
before commencing with the reload. That raises the criticality of this problem
as far as I'm concerned.
And I use the term "corruption" loosely. As I understand it, one of the
following is the case (either of which is a bug):
o The index is not supposed to have duplicate records in it, but does.
o The index is allowed to have duplicate records, but the b-tree logic does
not properly allow for that.
> Record not found in some SQL
> ----------------------------
>
> Key: DERBY-4032
> URL: https://issues.apache.org/jira/browse/DERBY-4032
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.2.1
> Environment: Windows XP
> Reporter: Chip Hartney
> Attachments: OrderEntryDB-base.zip, OrderEntryDB-seg0-part1.zip,
> OrderEntryDB-seg0-part2.zip, OrderEntryDB-seg0-part3.zip,
> OrderEntryDB-seg0-part4.zip, OrderEntryDB-seg0-part5.zip,
> OrderEntryDB-seg0-part6.zip, OrderEntryDB-seg0-part7.zip
>
>
> Per discussion at
> http://www.nabble.com/Record-not-found-in-some-SQL---Bug--td21700110.html...
> I have a "Product" table with a "Num" column that contains a record that is
> only accessible by some SQL and not others. I have tested this by JDBC
> access from my Java app as well was from IJ directly.
> ij> select "Num", length("Num") as "Len" from app."Product" where "Num" like
> 'HG1549%';
> Num |Len
> ----------------------------
> HG15490 |7
> HG15493 |7
> HG15497 |7 <== Found as expected
> HG15499 |7
> 4 rows selected
> ij> select "Num" from app."Product" where "Num" = 'HG15490';
> Num
> ----------------
> HG15490 <== Found as expected
> 1 row selected
> ij> select "Num" from app."Product" where "Num" = 'HG15493';
> Num
> ----------------
> HG15493 <== Found as expected
> 1 row selected
> ij> select "Num" from app."Product" where "Num" = 'HG15499';
> Num
> ----------------
> HG15499 <== Found as expected
> 1 row selected
> ij> select "Num" from app."Product" where "Num" = 'HG15497';
> Num
> ----------------
> 0 rows selected <== Not found!!!
> What could possibly hide the 'HG15497' record from the last SELECT?
> And it's not just a matter of equality versus inequality...as the following
> SQL does return the record:
> SELECT I."STYLE" FROM TEMP."ZJVINV2" AS I INNER JOIN APP."Product" AS P
> ON I."STYLE" = P."Num" WHERE I."STYLE" = 'HG15497';
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
