开发者

Esent database engine limited to specific page sizes?

开发者 https://www.devze.com 2023-02-10 22:07 出处:网络
I had a problem opening an esent database (Windows.edb) due to some problem with the page size. The pagesize of the Windows.edb on my system is 32K. When I set this via JET_paramDatabasePageSize JetIn

I had a problem opening an esent database (Windows.edb) due to some problem with the page size. The pagesize of the Windows.edb on my system is 32K. When I set this via JET_paramDatabasePageSize JetInit would return the error -1213 (The database page size does not match the engine). Laurion Burchall suggested to turn off JET_paramRecovery once I need only a ReadOnly access to the database. That solved my problem.

Until now. I have a not perfectly shutdown database. I assume that, with JET_paramRecovery=On, JetInit would automagically do the recovery and let me read the database. But if I try that I get that old -1213 error.

Now I can fix my file with ESENTUTL but the dummy user of my app won't be able to. Is there some way to have recovery on and still be able to define ANY DatabasePageSize? There are no log files present at the location of the database (and I set the Lo开发者_StackOverflow中文版gpath to the same directory to make sure they aren't written anywhere else).

Does this mean that the engine on my machine does not support the page size or the database? Or could I solve the problem with setting another magic switch?


Running recovery on another application's database is tricky. ESENT is an embedded engine and each application can have its own settings. Before you run recovery you need to know:

  1. Where the logfiles are located (JET_paramLogFilePath)
  2. The logfile size (JET_paramLogFileSize)
  3. The database page size (JET_paramDatabasePageSize)
  4. The logfile basename (JET_paramBaseName)

If you set all those parameters correctly then recovery will work properly. If you don't do that properly then the other application may have problems recovering its database!


There is a simple (but tricky) way to "fix" an EDB database which wasn't shut down gracefully. There is the state flag in the header at offset 52. It's a 4Byte Integer which should be set to 3 (if not closed gracefully the value you will find is be probably 2).

You will probably need to repeat this entry at the 2nd database page which contains a copy of the database header. You can find that page simply be the page size of the database (usually 4096, 8192, etc).

As this is really a hack, you should use it at your own RISK!

0

精彩评论

暂无评论...
验证码 换一张
取 消