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?
Here's something to start with (see "IMPORTANT NOTICE"):
http://db.apache.org/derby/releases/release-10.3.3.0.cgi
There is more info under the Jira issue.
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...
Sounds more and more like a Derby bug to me.
Are there any indexes/constraints on the newly created table?
--
Kristian
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
