Re: Database corruption problem

[kais haddadin]

I noticed that running a select statment only works when it is limited to a number, There are some corropted records,

SELECT count(*) FROM BIKER_ETL.ORDERS2 where "#id"<'70212' //this works

SELECT count(*) FROM BIKER_ETL.ORDERS2 where "#id"<'70213' //this gives an error


On Wednesday, October 17, 2012 10:46:29 AM UTC+2, kais haddadin wrote:

Hello!

I am trying to run a simple delete on a table. This error comes up:

Allgemeiner Fehler: "java.lang.ArrayIndexOutOfBoundsException"
General error: "java.lang.ArrayIndexOutOfBoundsException"; SQL statement:
delete from "BIKER_ETL"."ORDERS2" [50000-169] HY000/50000 (Hilfe)
org.h2.jdbc.JdbcSQLException: Allgemeiner Fehler: "java.lang.ArrayIndexOutOfBoundsException"
General error: "java.lang.ArrayIndexOutOfBoundsException"; SQL statement:
delete from "BIKER_ETL"."ORDERS2" [50000-169]
    at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
    at org.h2.message.DbException.get(DbException.java:158)
    at org.h2.message.DbException.convert(DbException.java:281)
    at org.h2.command.Command.executeUpdate(Command.java:234)
    at org.h2.jdbc.JdbcStatement.executeInternal(JdbcStatement.java:177)
    at org.h2.jdbc.JdbcStatement.execute(JdbcStatement.java:152)
    at org.h2.server.web.WebApp.getResult(WebApp.java:1311)
    at org.h2.server.web.WebApp.query(WebApp.java:1001)
    at org.h2.server.web.WebApp$1.next(WebApp.java:964)
    at org.h2.server.web.WebApp$1.next(WebApp.java:953)
    at org.h2.server.web.WebThread.process(WebThread.java:166)
    at org.h2.server.web.WebThread.run(WebThread.java:93)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ArrayIndexOutOfBoundsException

I can not make any query after that. Then I disconnect,connect again, run the simple select query, and it works. Delete does not work though.

[Thomas Mueller]

Hi,

The database was created with H2 version 1.3.158 (the CREATE_BUILD is 158). There was a known bug in this version, which was fixed in version 1.3.166 (2012-04-08), see also the change log. Possibly this was the reason for the problem, but I'm not sure. This problem could also be related to the usage of SET LOCK_MODE 0 (see the FAQ), or class loader issues listed in the .trace.db file (for example ClassNotFoundException: org.h2.store.PageStreamTrunk$Iterator when closing the database).

I suggest to upgrade to version 1.3.166 or newer, and not use LOCK_MODE 0 if possible (you need to explicitly set it to 3 to use the default setting).

To recover / migrate the existing data, you can use the Recover tool (see the docs).

Regards,

Thomas

On Wednesday, October 17, 2012, kais haddadin wrote:

Hello!

I am trying to run a simple delete on a table. This error comes up:

Allgemeiner Fehler: "java.lang.ArrayIndexOutOfBoundsException"
General error: "java.lang.ArrayIndexOutOfBoundsException"; SQL statement:
delete from "BIKER_ETL"."ORDERS2" [50000-169] HY000/50000 (Hilfe)
org.h2.jdbc.JdbcSQLException: Allgemeiner Fehler: "java.lang.ArrayIndexOutOfBoundsException"
General error: "java.lang.ArrayIndexOutOfBoundsException"; SQL statement:
delete from "BIKER_ETL"."ORDERS2" [50000-169]
    at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
    at org.h2.message.DbException.get(DbException.java:158)
    at org.h2.message.DbException.convert(DbException.java:281)
    at org.h2.command.Command.executeUpdate(Command.java:234)
    at org.h2.jdbc.JdbcStatement.executeInternal(JdbcStatement.java:177)
    at org.h2.jdbc.JdbcStatement.execute(JdbcStatement.java:152)
    at org.h2.server.web.WebApp.getResult(WebApp.java:1311)
    at org.h2.server.web.WebApp.query(WebApp.java:1001)
    at org.h2.server.web.WebApp$1.next(WebApp.java:964)
    at org.h2.server.web.WebApp$1.next(WebApp.java:953)
    at org.h2.server.web.WebThread.process(WebThread.java:166)
    at org.h2.server.web.WebThread.run(WebThread.java:93)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ArrayIndexOutOfBoundsException

I can not make any query after that. Then I disconnect,connect again, run the simple select query, and it works. Delete does not work though.

--
You received this message because you are subscribed to the Google Groups "H2 Database" group.
To view this discussion on the web visit https://groups.google.com/d/msg/h2-database/-/CqBs3kbU9kkJ.
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,

The database was created with H2 version 1.3.158 (the CREATE_BUILD is 158). There was a known bug in this version, which was fixed in version 1.3.166 (2012-04-08), see also the change log. Possibly this was the reason for the problem, but I'm not sure. This problem could also be related to the usage of SET LOCK_MODE 0 (see the FAQ), or class loader issues listed in the .trace.db file (for example ClassNotFoundException: org.h2.store.PageStreamTrunk$Iterator when closing the database).

I suggest to upgrade to version 1.3.166 or newer, and not use LOCK_MODE 0 if possible (you need to explicitly set it to 3 to use the default setting).

To recover / migrate the existing data, you can use the Recover tool (see the docs).

Regards,

Thomas

--

You received this message because you are subscribed to the Google Groups "H2 Database" group.

To view this discussion on the web visit https://groups.google.com/d/msg/h2-database/-/lpoP8VGlrl4J.

[Thomas Mueller]

Hi,

> it is still bad if I use LOCK_MODE=0 for this?

It is a potential problem, so I wouldn't use it unless it is really necessary (due to performance problems). See the FAQ.

Regards,

Thomas

On Thu, Oct 18, 2012 at 9:22 AM, kais haddadin <kaisha...@gmail.com> wrote:

Hi,

Thanks for the quick response. I will upgrade the database as suggested. Using LOCK_MODE=0 should be faster though than the other Modes,right? that is why am using it. In my use case, table locking is done in the program directly.

Do you think, it is still bad if I use LOCK_MODE=0 for this?

Thanks,

Kais