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? 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 -- View this message in context: http://www.nabble.com/Record-not-found-in-some-SQL---Bug--tp21700110p21714590.html Sent from the Apache Derby Users mailing list archive at Nabble.com.
