Re: [h2] Wrong meta data returned by ARRAY_GET

In this case the documentation is wrong as ResultSet.getObject() returns an array. Kind regards Christoff Schmitz F I N A R I S Financial Software Partner GmbH Sömmerringstrasse 23 60322 Frankfurt am Main Fon: +49 (0)69 / 254 98 - 24 Mobile: +49 (0)176 / 206 34 186 Fax: +49 (0)69

[h2] Re: General error: java.lang.RuntimeException: rowCount expected 30845 got 31428

I've encountered same issue. Exception in thread main org.h2.jdbc.JdbcSQLException: General error: java.lang.RuntimeException: rowCount expected 17483 got 93586 T65.I140 [5-175] How do I recover out of this? On Friday, November 6, 2009 at 11:26:31 PM UTC-8, Thomas Mueller wrote: Hi,

[h2] Re: General error: java.lang.RuntimeException: rowCount expected 30845 got 31428

I was able to recover using recovery tool. Nice! I repeated the large deletion operation and again encountered issue which does not make any sense. I have few table with referential integrity and I delete records 'backwards' first from detail tables and then header table (where foreign key

[h2] Re: General error: java.lang.RuntimeException: rowCount expected 30845 got 31428

My URL: jdbc:h2:./vmiDCDB;MVCC=TRUE;LOCK_TIMEOUT=1; On Friday, January 30, 2015 at 7:35:52 AM UTC-8, Meni Hillel wrote: I've encountered same issue. Exception in thread main org.h2.jdbc.JdbcSQLException: General error: java.lang.RuntimeException: rowCount expected 17483 got 93586

Re: [h2] Re: H2 database: slow query although index is used

HI Just to let you know that I am looking at your patch, it's just taking me a while because I don't have much time right now. -- Noel -- You received this message because you are subscribed to the Google Groups H2 Database group. To unsubscribe from this group and stop receiving emails from

Re: [h2] Could data corruption being caused by non-accurate .lock.db information ?

At this time FILE_LOCK=FS is not supported when using AUTO_SERVER=TRUE; It generates an error: org.h2.jdbc.JdbcSQLException: Feature not supported: autoServerMode (readOnly || fileLockMethod == NO || fileLockMethod == SERIALIZED || inMemory) Is there a reason for to not support it now? --

Re: [h2] Re: H2 database: slow query although index is used

Hi, Debugging the Postgres code I saw that my idea is not so wrong. They use a similar idea to test sorted path keys. The function pathkey_is_redundant (line 130 of this file) is used by the optimization process to evaluate path keys, and if you read the comments, especially the case 1, you'll

[h2] Using synchronized in user defined functions or not

Hi, Sometimes we have noticed that executing a query which calls a user-defined table takes longer as expected when multiple instances calls this. We have got a multi threaded server application which has got multiple database connections to different database files using the properties:

Re: [h2] Wrong meta data returned by ARRAY_GET

Hi, According to the documentation, the method ARRAY_GET returns one element of an array as a string, so I think the meta information is correct. See the documentation: http://www.h2database.com/html/functions.html#array_get. Regards, Fred 2015-01-30 10:57 GMT-02:00

Re: [h2] Re: Could data corruption being caused by non-accurate .lock.db information ?

I just tried the FILE_LOCK=SOCKET. It can be used, but it is not reliable. If the lock file is not unlocked (and deleted) it is not possible to reconnect to the database. It is not accurate to detect if it can obtain the lock. Because the FILE_LOCK=SOCKET algorithm also delete en create the

Re: [h2] Re: Could data corruption being caused by non-accurate .lock.db information ?

Hi Hmmm, you are correct. I think I am going to let Thomas deal with this one, I obviously do not understand the file locking stuff sufficiently. Regards, Noel -- You received this message because you are subscribed to the Google Groups H2 Database group. To unsubscribe from this group and

Re: [h2] Re: Could data corruption being caused by non-accurate .lock.db information ?

I just tried the FILE_LOCK=SOCKET. It can be used, but it is not reliable. If the lock file is not unlocked (and not deleted) it is not possible to reconnect to the database. It is not accurate to detect if it can obtain the lock. Because the FILE_LOCK=SOCKET algorithm also delete en create

Re: [h2] Re: Could data corruption being caused by non-accurate .lock.db information ?

FILE_LOCK=SOCKET would be safer in that situation. On 2015-01-30 10:03 AM, o.vanderm...@xso.nl wrote: Hi Noel, The database file will place on a network share and will be accessed from different computers. What should the FILE_LOCK be in your opinion? Olaf -- You received this message

Re: [h2] Re: Could data corruption being caused by non-accurate .lock.db information ?

Hi Noel, The database file will place on a network share and will be accessed from different computers. What should the FILE_LOCK be in your opinion? Olaf -- You received this message because you are subscribed to the Google Groups H2 Database group. To unsubscribe from this group and stop

[h2] Could data corruption being caused by non-accurate .lock.db information ?

Hi, I think in the future (with the MVStore) we should always use native file system lock on the database file, and possibly also on the .lock.db file (if that file is used). That is, deprecate / remove the methods File Locking Method 'File' and File Locking Method 'Socket'. The auto-server mode

[h2] Wrong meta data returned by ARRAY_GET

Hi, When executing the following 2 statements, the ResultSetMetaData is wrong for the column with the ARRAY_GET expression. SET @a = ((1, 2), (2, 4)) / SELECT @a, ARRAY_GET(@a, 1) The metadata says that that column is of type VARCHAR, while ARRAY should be correct (getObject() invoked on that