I have the same issue. I saw no where in the documentation that this is the
behavior. This is quite severe in my opinion. We have an schema upgrade
framework that involved from DDL and DML commands. To move from one schema
version to another, you mass perform all steps successfully or non at all
/ ... or rollback to that checkpoint (this will close the database; you
> will need to re-open it)
> Statement.executeUpdate("checkpoint rollback 'version 1'");
>
> This feature would be somewhat related to "point in time recovery", for
> example as describe
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
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.RuntimeExc
Statement.java:181)
at org.h2.jdbc.JdbcStatement.execute(JdbcStatement.java:156)
On Friday, January 30, 2015 at 7:37:12 AM UTC-8, Meni Hillel wrote:
>
> 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:
>>
Hi,
I am encountering an issue with auto increment identity field. It seems
that if multiple concurrent transaction happens all at once, the number
generate is not being incremented correctly (+1). Instead, it starts at
1,then jumps to 349 if the transactions are committed 4 milliseconds apart.
Here's the link:
> http://stackoverflow.com/questions/11653892/bug-in-h2-database-the-auto-increment-field-is-incremented-by-32
> Hope this helps
>
>
> On Sunday, 24 May 2015 17:46:17 UTC-5, Meni Hillel wrote:
>>
>> Hi,
>>
>> I am encountering an issue with
>
> Could you provide a simple, small, reproducible test case please?
>
> Regards,
> Thomas
>
>
> On Monday, May 25, 2015, Meni Hillel wrote:
>
>> Thanks Jose.
>>
>> I saw this issue and I did not think it applied to me. In my case, it
>> does not ski
Using H2 v1.4.191
Trying to delete it shows:
Error: Constraint "UK_1PT73622HFCLVE5LRHRQTITBK" not found; SQL statement:
alter table subscription drop constraint UK_1pt73622hfclve5lrhrqtitbk
[90057-187]
SQLState: 90057
ErrorCode: 90057
Error: org.h2.jdbc.JdbcSQLException: Constraint
"UK_1PT7362
Is that even possible? I am using maven and clearly only one version shows
up.
On Thu, Jun 30, 2016 at 6:08 AM, Noel Grandin wrote:
> Hmmm, for starters, you are mixing and two different versions of H2 there,
> 1.4.187 and 1.4.191.
> I would fix that first and see if the problem still happens.
>
I am using embedded file. There are no clients and servers. Only one jar is
loaded.
On Fri, Jul 1, 2016 at 2:13 AM, Noel Grandin wrote:
> one version on the server side and one version on the client side.
> (which mostly works, but since you have a problem, lets eliminate this
> possibility firs
I get the confusion now Apologies. One log was produced from my app,
which used 191. The other log was produced using interactive SQL program
(SQuirreL SQL Client) which happens to use 187. Both obviously experienced
the same issue, suggesting this issue exist in both versions.
On Sat, Jul 2,
Having the same issue...
On Wednesday, June 8, 2016 at 1:49:32 AM UTC-7,
scott@digitalbarriers.com wrote:
>
> Am trying to do execute a CreateCluster operation. I have two databases on
> different machines started by:
>
> java -cp c:\h2\bin\h2-1.4.192.jar org.h2.tools.Server -tcp -tcpPort 91
Figured it out. Need to make sure the current directory must be where H2
jar file is located.
On Sun, Aug 28, 2016 at 2:21 AM, Meni Hillel wrote:
> Having the same issue...
>
> On Wednesday, June 8, 2016 at 1:49:32 AM UTC-7,
> scott@digitalbarriers.com wrote:
>>
>> A
I am creating a cluster following the steps required. When I start the
second node, I get the above error message. I've went ahead and debugged
the code and it seems the backup.sql file gets created in the source
directory and when the target wants to execute it, it would obviously not
be foun
Hi,
I am hitting an issue where joining the cluster wipes the whole database.
The scenario goes like this. I am starting an instance (source), start
generate DB traffic continuously, then, start another instance (target).
While traffic hits DB non-stop, I shutdown source, target takes over
(be
My db got corrupted. Tried the recovery tool, but got error. Would
appreciate any help.
Exception in thread "main" java.lang.IllegalStateException: File corrupted
in chunk 831690, expected page length 4..768, got 0 [1.4.193/6]
at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.ja
H2 v1.4.196 (latest)
I am hitting an issue where a foreign key is defined on a column of a table
with a cascade delete constraint.
alter table port
add constraint fk_port_network
foreign key (network_fk)
references network
on delete cascade on update casca
org.h2.jdbc.JdbcSQLException: Table "SYNONYMS" not found; SQL statement:
SELECT TABLE_CAT, TABLE_SCHEM, TABLE_NAME, TABLE_TYPE, REMARKS, TYPE_CAT,
TYPE_SCHEM, TYPE_NAME, SELF_REFERENCING_COL_NAME, REF_GENERATION, SQL FROM
(SELECT SYNONYM_CATALOG TABLE_CAT, SYNONYM_SCHEMA TABLE_SCHEM, SYNONYM_NAME
Thanks! Confirmed. Once both client and sever are on same version issue
goes away.
On Fri, Apr 13, 2018 at 2:44 AM, Noel Grandin wrote:
> there is a bug (which is fixed on master) if you mix and match different
> versions client and server side.
>
> If you upgrade the client to 1.4.197, this pro
when will fix be posted to maven?
On Fri, Apr 13, 2018 at 12:02 PM, Meni Hillel wrote:
> Thanks! Confirmed. Once both client and sever are on same version issue
> goes away.
>
> On Fri, Apr 13, 2018 at 2:44 AM, Noel Grandin
> wrote:
>
>> there is a bug (which is fixed o
@Thomas Mueller - You mentioned that file corruption may take place if
"copy the database file while it is in use, without using the online backup
command". Can you please elaborate?
Do note that we do make a file copy while DB is in use, but we make a call
to "SET EXCLUSIVE 1" before. What wou
Is there a way to safely interrupt a running thread, that may be in middle
of a transaction commit? I read that it is not recommended to use
Thread.interrupt() with h2, but I have a need to shutdown many threads and
cannot tell which thread may be in middle of a transaction. The main
motivation
I read about SHUTDOWN and it is good if I want to tear the whole thing
down. But what if I want to interrupt a single transaction?
On Thu, Jul 4, 2019 at 9:30 AM Evgenij Ryazanov wrote:
> Thread.interrupt() is a way to database corruption.
>
> Take a look on the SHUTDOWN command:
> https://h2da
I have no issue if it takes couple of seconds longer. I'm using
Hibernate... Need to research if jdbc cancel statesment is exposed...
On Thu, Jul 4, 2019, 11:47 AM Noel Grandin wrote:
> You can call cancel() on a Statement, but the way that H2 implements
> cancel() means that only some stages of
I have a DB created with older version 1.4.96 and we've upgraded to 1.4.99.
When altering a table to drop a column, it cause table to be renamed, to
something like _COPY_##_## where ## is a number. Once this happens,
it get DB to a corrupted state and it is no longer usable. Is this a known
iss
Thank you Evgenij, It seems to work.
Meni
On Tue, Aug 6, 2019 at 1:34 AM Evgenij Ryazanov wrote:
> 1.4.196 and older versions have a problem with some constraints. This
> issue was fixed in 1.4.197, but the fix isn't fully compatible with older
> databases. Execution of DDL command in 1.4.197 i
For no evident reason, we're getting a random failure on a simple query
reporting a corruption error. Program continues successfully and
consecutive transactions works fine. But has been very puzzling and we
cannot figure any root cause.
Caused by: org.h2.jdbc.JdbcSQLNonTransientException: Gen
One more piece of information that may be important - we are taking a
periodic backup hourly. We do it the proper way, using the "BACKUP TO"
command. Don't know if that could be a factor.
On Friday, January 24, 2020 at 12:45:43 PM UTC-8, Meni Hillel wrote:
>
> For no
Thank you for the comprehensive and thoughtful response.
1) It is true that we may have the potential to interrupt a thread in a
middle of a transaction, but it may happen of a very rare condition which
absolutely positively did not take place.
2) That is correct and we indeed do call SHUTDOWN.
30 matches
Mail list logo
