Derby allows you a lot of freedom in configuring your system. This freedom can be confusing if you do not understand how properties work. You also have the option of not setting any and instead using the Derby defaults, which are tuned for a single-user embedded system.
Imagine the following scenario of an embedded environment:
java -Dderby.system.home=c:\system_directory MyApp
CREATE TABLE table1 (a INT, b VARCHAR(10))
Derby takes the page size of 8192 from the system-wide properties set in the derby.properties file, since the property has not been set any other way.
java -Dderby.system.home=c:\system_directory -Dderby.storage.pageSize=4096 MyApp CREATE TABLE anothertable (a INT, b VARCHAR(10))The page size for the anothertable table will be 4096 bytes.
CallableStatement cs = conn.prepareCall("CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(?, ?)"); cs.setString(1, "derby.storage.pageSize"); cs.setString(2, "32768"); cs.execute(); cs.close();
CREATE TABLE table2 (a INT, b VARCHAR(10))The page size for the table2 table is 32768 bytes.
java -Dderby.system.home=c:\system_directory MyApp
CREATE TABLE table4 (a INT, b VARCHAR(10))
Derby uses the persistent database-wide property of 32768 for this table, since the database-wide property set in the previous session is persistent and overrides the system-wide property set in the derby.properties file.
What you have is a situation in which three different tables each get a different page size, even though the derby.properties file remained constant.
Remove the derby.properties file from the system or the database from its current location (forgetting to move the file with it), and you could get yet another value for a new table.
To avoid this situation, be consistent in the way you set properties.