jrgchip wrote:
oysteing wrote:
Have you tried to run the Derby consistency checker?
Yes...it reports all 44 tables as OK per SYSCS_CHECK_TABLE.
Kristian Waagan-4 wrote:
Be aware that 10.3.1.4 and 10.3.2.1 had a corruption bug, mostly (or
only) seen on Windows.
Can you point me to information about that corruption bug?
Please see the release notes for 10.3.3.0 (
http://db.apache.org/derby/releases/release-10.3.3.0.cgi ) Detailed
information can be found on the associated bug report:
http://issues.apache.org/jira/browse/DERBY-3347 The symptoms in that bug
report do not match your bug report but maybe the bug manifests itself
in other ways. Upgrading to 10.3.3.0 will remove this theory from
consideration.
Hope this helps,
-Rick
Derby-3 wrote:
If you reload the data, the problem goes away. This would imply that it's
a data issue.
The data is from an ASCII file (with no special chars) and is loaded with
SYSCS_IMPORT_TABLE. But I conclude the load, itself, is not the problem
because the data is retrievable after initial load. It is only after the DB
is used for a while that something becomes unreadable...in this case the
HG15497 record noted in my post.
Derby-3 wrote:
Since your database is in a 'broken' state, what happens if you create a
copy of the table and select the rows that match your like 'xxxx%' clause
and insert them in to your temp duplicate table.
I am able to copy the table and select the "bad" row from the copy per the
following sequence...
ij> CREATE TABLE app."ProductCopy" AS SELECT * FROM app."Product" WITH NO
DATA;
0 rows inserted/updated/deleted
ij> insert into app."ProductCopy" select * from app."Product";
34536 rows inserted/updated/deleted
ij> select "Num" from app."Product" where "Num" = 'HG15497';
Num
----------------
0 rows selected
ij> select "Num" from app."ProductCopy" where "Num" = 'HG15497';
Num
----------------
HG15497
1 row selected
