Exception ver 1.2.140

Hi, I am getting this exception org.h2.jdbc.JdbcSQLException: General error: java.lang.RuntimeException: File ID mismatch got=0 expected=18 pos=1420361 false org.h2.store.DiskFile:/u/users/framewrk/mfwscc/flow/ tomcat/apache-tomcat-6.0.20/mfui/db/mfui_h2_db.index.db blockCount:0; SQL statement:

Exception ver 1.2.140

Hi, I am getting this exception org.h2.jdbc.JdbcSQLException: General error: java.lang.RuntimeException: File ID mismatch got=0 expected=18 pos=1420361 false org.h2.store.DiskFile:/u/users/framewrk/mfwscc/flow/ tomcat/apache-tomcat-6.0.20/mfui/db/mfui_h2_db.index.db blockCount:0; SQL statement:

Re: Binary Primary Key

I would stick to INT, SMALLINT, BIGINT for primary keys. Depending on the numbers or rows in the table I need to store. /Andreas On Mon, Aug 30, 2010 at 1:39 AM, jms.cer...@gmail.com jms.cer...@gmail.comwrote: Hi, I would like some insight/opinions on using binary types for primary keys -

Re: Exception ver 1.2.140

Hi, Is it a different client and server version? The error indicated version 1.1.119, not 1.2.140 ? I think somewhere along the line there was an issue where with different client and server versions. It outputs an error that doesn't make sense like what you are getting. So I think the

Deadlock and MULTI_THREADED

Hi, the test program (sometimes) produces JdbcSQLExceptions due to deadlocks. As I've read in other threads this seems to be not fixable? Although I was wondering that I've never seen such a problem before in other database systems?! This is a VERY nasty problem because I cannot expect that all

CHECK CONSTRAINT

Hi, In the docs it is stated:The check condition must evaluate to true or to |NULL Does this mean that the following constraint is not allowed CONSTRAINT SELF_MUST_NOT_BE_PARENT CHECK (PARENT_ID APID) because it can evaluate to false? Or is it just that the documentation should say

Re: INFORMATION_SCHEMA.FUNCTION_ALIASES with AggregateFunction throws error

Hi, Thanks a lot! You are right, this is a bug (exactly at the place where you originally wrote). I will fix it in the next release. Regards, Thomas On Sun, Aug 29, 2010 at 11:18 PM, michaelm michael.mich...@free.fr wrote: Hi Thomas, Here it is : SELECT * FROM

Re: Thread safety of insert / sequence generation

Hi, I don't know how DBCP works exactly in this case. To find out what JDBC methods DBCP called, and what SQL statements were executed, you can append ;TRACE_LEVEL_FILE=3 to the database URL, then run the test case. After that you get all information in the .trace.db file. I'm getting

Re: Binary Primary Key

Hi Andreas, Lets assume, for argument sake, that the data types you mentioned just wouldn't meet the specified requirements. On 30 August 2010 08:51, Andreas Henningsson andreas.hennings...@gmail.comwrote: I would stick to INT, SMALLINT, BIGINT for primary keys. Depending on the numbers or

Re: Binary Primary Key

Binary data types as keys would make using database tools for adhoc queries practically impossible. That alone is enough to throw out the idea for me. In my world primary keys should always be meaningless, so an INT should always be just fine. Your binary fields don't sound meaningless to me, so