This project has moved and is read-only. For the latest updates, please go here.


Aug 28, 2010 at 6:42 AM

Hello folks, I'm writing a Windows Forms utility that is like a lightweight SQL Server Management Studio for ESE. You can open EDBs and display the schema (tables, indexes and segments), and you you open and edit table data in a grid. That's all it does so far, but I plan to add features for managing databases and their schemas as well as utility functions.

I just downloaded build 54436 and I've compiled and run all of the samples okay. My others apps that use the Inerop library are also working correctly with this build. However, my utility is failing to open any of the sample databases or my own ones. All I get is this during Instance.Init()

Error AttachedDatabaseMismatch (JET_errAttachedDatabaseMismatch, An outstanding database attachment has been detected at the start or end of recovery, but database is missing or does not match attachment info)

I've made no changes to my code, so this new error msut be a result of using the new build. I'm currently at a loss about how to get around this problem. Any advice would be most welcome. In the meantime I'll experiment with different Instance parameters.

Greg Keogh


Aug 28, 2010 at 8:22 AM

You need to set the AlternateDatabaseRecoveryPath in the InstanceParameters

You can also run:

esentutl.exe /p database_name

See here for more discussion on that:


Is you utility available anywhere?

Aug 28, 2010 at 9:31 AM

I tried setting the recovery path to the path of the database file I'm opening before Init(), but sadly it makes no difference. I've been running some tests to try and isolate the problem, and I'm getting some very strange symptoms that have me quite confused. I wrote a small Console app that runs a skeleton of the same code my large Forms app does, and it works okay. I just can't understand yet why the small version works and the larger app doesn't. The Forms app keeps dying in the instance Init() with the mismatch error. I'm guessing now that it's not an ESENT problem, but something stupid in my code, but for the life of me I just can't see it yet.

My utility is in very early development stages, but I've put a screenshot on the link below. When the structure and behaviour of the app is clarified I'll ask about how to make it a community project (I've not done that before). I'm trying to decouple all of the controls by making them broadcast messages to each other, and each piece of major functionality is extracted into abstract "services". I'm also experimenting with MEF as a way of building the whole app as a set of plugins. It's still early days, but general ideas about the app and what it could do would be welcome.

Aug 29, 2010 at 5:42 AM

A follow-up note on this: A test console app and a test Forms app can all open the databases okay, but the main Forms app continues to produce the mismatch error. I even pasted the code between the working and failing apps and it made no difference. I tried commenting out hundreds of lines of code to try and isolat the error, but it didn't work. There is something "corrupt" with my main app and I remain completely and utterly bewildered as to what the cause might be.

I've given up! I decided to create a new solution with the existing projects broken up into smaller ones. I accidentally had too much non-UI code in the UI project, so I've isolated all of the Esent related code into a single library that I can easily unit test. This more granular approach should help avoid problems like the one above, or at least it will help me diagnose what's wrong. While unit testing my refactored code I have hit a JET_errPageSizeMismatch error which I will ask about in a new thread.


Aug 29, 2010 at 7:04 AM

The problem could be the working directory of the program or a dirty shutdown. Running recovery on an arbitrary database can be tricky:

  • You have to set JET_param.LogFilePath to the location of the logfiles for the database.
  • You have to set JET_param.SystemPath to the location of the checkpoint file for the database.
  • You have to set JET_param.BaseName to the three letter prefix for the logfiles. The default is "EDB", but some applications change that.
  • The logfiles contain a hardcoded path to the database. If the database has moved you can set JET_param.AlternateDatabaseRecoveryPath, as Ayende suggests above.

Applications that create their own databases will set these parameters by default, so they don't normally have problems.

I suggest that your application always opens databases read-only. Having your application dirty the database and create logfiles can create a lot of problems.

This will require a consistent database, but is a lot safer. To open a database read-only you should

  • Set JET_param.Recovery to "off", or set InstanceParameters.Recovery to false.
  • Open the database with the OpenDatabaseGrbit.ReadOnly option.
  • Attach the database with the AttachDatabaseGrbit.ReadOnly option.


Aug 29, 2010 at 8:05 AM

You led me to the answer! I set the Log, System and Recovery paths to the same directory as the database file, and the mismatch problems goes away. I found by elimination that only the LogFilePath had any effect (but that's probably just a coincidence of how I'm using the database).

Since the author of a database will set all of the paths and parameters of their choice, it might not be possible for an arbitrary app to rediscover all of these settings and reopen the database. Is this true? If so, then my plans for a general purpose ESENT DB browser app are mostly killed.

Your comments about the "dirty" problem and read-only are rather sobering as well. I'm getting the impression that my ESENT browser app is ill conceived and will not play well with the world of ESENT.

I have an idea for something else that might be more useful: T4 templates that read ESENT databases. I've used netTiers generated data layer code and classes for many years and I was thinking that I could read an ESENT schema and generate code in a similar way. I will look into this, unless I hear from anyone about unforseen risks or problems that would make it technically infeasible.


Aug 29, 2010 at 9:39 AM

You can give the user the option to define those locations, no?  

Apr 27, 2013 at 6:08 PM
Just check the my post, you will get real solution to overcome here:
Apr 29, 2013 at 9:50 AM
admin503, how is your URL related to the topic? It seems to be promoting a separate piece of software...

Apr 29, 2013 at 10:13 AM
Sorry to post it here, but it is related to disconnected or attached mailbox that's why i refereed this.
Jun 2, 2014 at 4:44 PM
Over the past few months, there have been four separate posts about converting EDB to PST software, using four different URLs, four different one-use accounts. This reeks of 'SPAM' so I'm deleting them.

If they are legitimate, I apologize. Please re-post and explain why it's legitimate.