Is it possible to manipulate the base tables and/or the btree indexes in a way to cause inconsistencies
It's hard to do this reliably, or easily. But I encourage you to try, it sounds like a good project, and a good way to explore Derby internals and improve your knowledge of Derby. Here's a possible idea: take part, but not all, of your Derby database "back in time". A base table and its indexes are each stored in separate physical files, which Derby calls "conglomerates". So if you define a table with a number of secondary indexes, and then insert some rows into that table, Derby will populate the table and its indexes. Then, shut down Derby cleanly and make a copy of the entire database folder. Then, start Derby back up and add some more rows into that table. Then, shut down Derby cleanly again. Then, try (using yet another copy of the Derby database folder) copying some of the table's index conglomerates from your first backup copy into your master copy. This will cause the base table rows to be "missing" some index entries because you have essentially "rolled back" the index conglomerates to an earlier time, causing them to be missing the index entries that were created by your second batch of insert statements. Then see how the consistency-checking tools behave on that artifically-damaged database. Similar experiments are possible using other types of integrity constraints (unique constraints, foreign key constraints, etc), and using other types of "back-in-time" intentional damage, such as rolling an index back to before an update of an indexed column, or rolling an index back to before a delete of a row, or rolling back one table but not other table, when the tables have a referential integrity constraint. These are the sorts of consistency violations that a consistency-checking tool is intended to catch, so it would be good to know if you are able to provoke such types of damage and then observe the tools helping you to diagnose the problem. Regarding internal sorts of Btree integrity, that is a harder problem, but it would be good for you to verify that you can detect the simpler problems first. thanks, bryan
