Skip to content

Error Code: 50000 Unable to read page at position <number> after connecting to DB with Intellij Database Tool #2204

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Tagman opened this issue Oct 24, 2019 · 15 comments

Comments

@Tagman
Copy link

Tagman commented Oct 24, 2019

Problem: I am executing some Unit-Tests using JPA and H2 that are persisting objects inside the DB. After that I connect to the local database via the Intellij Database Tool. After disconnecting and running the Unit-Tests again. I get the following exception:

Internal Exception: org.h2.jdbc.JdbcSQLNonTransientException: General error: "java.lang.IllegalStateException: Unable to read the page at position 1099511637450 [1.4.200/6]" [50000-200]
Error Code: 50000

Downgrading the H2 dependency in maven from 1.4.200 to 1.4.199 fixes the problem.

Now I can run the tests again after connecting and disconnecting from the DB.

@katzyn
Copy link
Contributor

katzyn commented Oct 24, 2019

Could you check what version of H2 that tool actually uses?

@katzyn
Copy link
Contributor

katzyn commented Oct 26, 2019

This issue was reported here #2078 (comment) and on the SO.

1.4.196 and 1.4.200 were used together.

@grandinj
@andreitokar
Maybe we shouldn't allow write access to a newer database from an older H2, unless some flag is set?

@katzyn
Copy link
Contributor

katzyn commented Oct 26, 2019

Unfortunately, the create version is available only on late stages of database initialization, so it can be complicated.

@katzyn
Copy link
Contributor

katzyn commented Oct 26, 2019

Also the newer versions don't upgrade the database format and version in metadata.

@andreitokar
Copy link
Contributor

Unfortunately, the create version is available only on late stages of database initialization, so it can be complicated.

There is no "create version" in the header or elsewhere. Instead "format" and "formatRead" should be used and related logic is already in place. Unfortunately hard-coded constants, that fields compared against, were not incremented when they probably should've been.
One case, I am aware of, is a change in undo log (split into per-transaction), but it only manifest itself when there are open transactions, which should not be the case with normal upgrade or downgrade. FORMAT_WRITE (or both) should have been incremented in 1.4.197. 😞

Also the newer versions don't upgrade the database format and version in metadata.

Field "format" is written into the header of a newly created databases with value of FORMAT_WRITE, and it's never updated afterward, because it is a format of a database itself.
Maybe it need to be overwritten in some cases, but that would depend on the nature of incompatibility introduced.

@katzyn
Copy link
Contributor

katzyn commented Oct 26, 2019

There is no "create version" in the header or elsewhere.

I meant H2 database, not the standalone MVStore / TransactionStore. H2 database has a CREATE_BUILD (196, 200, etc.) in the metadata.

@katzyn
Copy link
Contributor

katzyn commented Oct 26, 2019

In some cases incompatibilities can be caused by the database itself. For example, there was an incompatible change between 1.4.196 and 1.4.197 in foreign key constraints that affects both PageStore and MVStore. (We fixed upgrade procedure of MVStore in more recent versions.)

We can't fix the behavior of already released versions, but we can improve it for a new releases.

Some other database systems perform an automatic or semi-automatic upgrade of old database files. I think we need to do the same when we know that new version is not fully compatible with older one that was used to create the database. And database should at least reject writes to a database file that was created by a newer version to avoid its corruption.

@grandinj
Copy link
Contributor

And database should at least reject writes to a database file that was created by a newer version to avoid its corruption.

Agreed

SantaMinus added a commit to SantaMinus/InfoSec that referenced this issue Nov 2, 2019
SantaMinus added a commit to SantaMinus/InfoSec that referenced this issue Nov 2, 2019
* Create a DB connection

* - make Authenticator polymorphic (XML & DB)
- start writing DB auth

* Use DBAuthenticator, experiment with DBs (connection established, table not found)

* Add the simplest check

* Downgrade h2 to 1.4.196 to avoid h2database/h2database#2204

* Post-merge changes
@Koooooo-7
Copy link

I met the same problem and when I changed 1.4.200 to 1.4.199,it worked.
After I used the tool to connected database as u did , I couldn't login the h2-console site either.
BTW: it seems the same as #2078 .

@ztkmkoo
Copy link

ztkmkoo commented Jan 22, 2020

@Koooooo-7
I met the same problem with h2 1.4.200 + spring boot 2.2.4.RELEASE + intellij + h2 console.
Thx. change to 1.4.199 works for me.

@ploober
Copy link

ploober commented Feb 2, 2020

I had just connected with the intellij db console to one of my h2 databases, and upon starting my spring boot app again I was greeted with h2 General error: java.lang.IllegalStateException: Unable to read the page at position....

Downgrading from 1.4.200 back to 1.4.199 worked for me too.

@arseny-tl
Copy link

Got same error.

Downgrading h2 version from 1.4.200 back to 1.4.199 worked for me too.

@ferhad266
Copy link

I met the same problem with h2 1.4.200 + spring boot 2.2.4.RELEASE + intellij + h2 console.
Thx. change to 1.4.199 works for me.

Please , how to does h2 version from 1.4.200 back to 1.4.199 ?

@oskarv
Copy link

oskarv commented May 11, 2021

@ferhad266 I guess you are working with spring - maven project, to downgrade just make sure to have explicit versioning for h2 dependency in you pom.xml file
Something like:

<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <version>1.4.199</version>
</dependency>

@katzyn
Copy link
Contributor

katzyn commented Jun 4, 2022

This issue is fixed in 2.0.202 and later versions. They don't try to read files in incompatible formats and they mark own files as incompatible with old unsupported versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants