NullPointerException

[Kris]

Trying to compress a database named "Local" using the SCRIPT and
RUNSCRIPT sql commands. The SCRIPT command is getting the error:

05-18 10:47:49 jdbc[4]: SQLException
org.h2.jdbc.JdbcSQLException: General error:
"java.lang.NullPointerException"; SQL statement:
script drop to 'Local.sql' [50000-128]
at org.h2.message.Message.getSQLException(Message.java:110)
at org.h2.message.Message.convert(Message.java:287)
at org.h2.message.Message.convert(Message.java:248)
at org.h2.command.Command.executeQuery(Command.java:134)
at org.h2.jdbc.JdbcStatement.executeInternal(JdbcStatement.java:172)
at org.h2.jdbc.JdbcStatement.execute(JdbcStatement.java:151)

...

Caused by: java.lang.NullPointerException
at org.h2.index.PageDataIndex.getPageOverflow(PageDataIndex.java:201)
at org.h2.index.PageDataLeaf.getRowAt(PageDataLeaf.java:329)
at org.h2.index.PageDataCursor.nextRow(PageDataCursor.java:103)
at org.h2.index.PageDataCursor.next(PageDataCursor.java:55)
at org.h2.command.dml.ScriptCommand.query(ScriptCommand.java:241)
at org.h2.command.CommandContainer.query(CommandContainer.java:81)
at org.h2.command.Command.executeQuery(Command.java:132)
... 20 more


Is this a H2 bug? or an database corruption?

Thanks,
Kris

--
You received this message because you are subscribed to the Google Groups "H2 Database" group.
To post to this group, send email to h2-da...@googlegroups.com.
To unsubscribe from this group, send email to h2-database...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.

[Thomas Mueller]

Hi,

This looks like a database corruption. A workarounds is: use the tool
org.h2.tools.Recover to create the SQL script file, and then re-create
the database using this script. Does it work when you do this?

As far as I see, you are using version 1.2.128. An important
corruption problem was fixed in version 1.2.135 (see the change log).
Known causes for corrupt databases are:

- If the database was used with a version older than 1.2.135, and the
process was killed while the database was closing or writing a
checkpoint.

- Using the transaction isolation level READ_UNCOMMITTED (LOCK_MODE 0)
while at the same time using multiple connections.

- Disabling database file protection using (setting FILE_LOCK to NO in
the database URL).

It could also be caused by areas that are not fully tested, which are:

- Platforms other than Windows XP, Linux, Mac OS X, or JVMs other than
Sun 1.5 or 1.6

- The feature MULTI_THREADED

- The features AUTO_SERVER and AUTO_RECONNECT

- The file locking method 'Serialized'

Regards,
Thomas

[Kris]

Hi,

> This looks like a database corruption. A workarounds is: use the tool
> org.h2.tools.Recover to create the SQL script file, and then re-create
> the database using this script. Does it work when you do this?

Just tried it. The Recover tool created a SQL script file but one
SQL
command was missing a field and another SQL command created a
duplicate record. I hand correct the data to get the database
reloaded.

That implies the database was corrupted but it would be handy if the
recover tool could generate clean SQL commands and ignore bad data.

> - If the database was used with a version older than 1.2.135, and the
> process was killed while the database was closing or writing a
> checkpoint.

Most likely that was the situation since this was running on a
computer
in another state/office so anything could happen.

I ask the question because NPE sometimes means program error.

Thank you for your time,

[Thomas Mueller]

Hi,

> I hand correct the data to get the database reloaded.

Yes, I'm afraid this is the only solution for this case.

> That implies the database was corrupted but it would be handy if the
> recover tool could generate clean SQL commands and ignore bad data.

Database file should never get corrupt, even if the process is killed
while writing. Unfortunately it turned out there were still some bugs
up to version 1.2.134. Actually, database files should not get corrupt
even on power failure, but so far I don't have enough test cases to
verify this (I do test it from time to time, in the past with FAT32
and NTFS and currently with Ext2, but it would be much better to test
with many files system).

Regards,
Thomas