Accessing database from new application


Similar to 13850

I have an application that has been radically upgraded, and the new application is to use the same databases that the original one did. However, the application name is different, which causes a "FileNotFoundException".

Is there any easy way to preserve the data in the original databases? I'd rather not export to CSV then import the data again.

file attachments


mthorp wrote Oct 13, 2016 at 7:14 PM

Did you move the database files around at all? When you open an existing database, the database engine will look at the log files, and these include the path of the database they were generated for, so if you've moved the database files you have to use a set of parameters to indicate this to the database engine.

The way you'd do this will depend on whether your application uses a PersistentDictionary or is just creating a database using the ManagedEsent APIs.

blelacheur wrote Oct 13, 2016 at 9:12 PM

I haven't moved the files at all.

When I do a binary compare of the files, I find that in the Globals table of the edb database file there is an embedded copy of the application name. Both applications tell the persistent dictionary where to look, for the database, but I suspect that there is a validity check to ensure that table creator is the only one that can access it.

To be clear -- I'm not so much modifying the application as I am changing it's build process, which involved (among other things) changing the applications output file name, hence the problem...

Why it shows up as a file not found exception, I can't tell you. I took a quick look at the source, and I could not easily determine where it was coming from. I am using V 1.9.2 of the library, and I'm in the process of upgrading to 1.9.4 to get access to the configuration, but I'm not entirely sure that will buy me much.



mthorp wrote Oct 13, 2016 at 11:22 PM

PersistentDictionary does not check for the application name, it only checks that the schema is correct - i.e. that you are using the same types for Key and Value. Do you have the full text of the FileNotFoundException?

I just wrote a set of test applications that open a shared PersistentDictionary to make sure there is no bug here, and it worked fine. However, I did hit some FileNotFoundException in one of them because I had made a mistake in setting up the proper dependencies on one of the test applications. If you changed the build, is it possible you're missing one of the dependencies (Esent.Collections, Esent.Isam, Esent.Interop)?

blelacheur wrote Oct 14, 2016 at 2:38 PM


The schema should be correct -- I am using the same C# class to wrap access to the Persistent Dictionary.

The exception message is : {"Could not load file or assembly 'DefaultName, Version=1.0.6130.28748, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.":"DefaultName, Version=1.0.6130.28748, Culture=neutral, PublicKeyToken=null"}

The application that created the dictionary was called "DefaultName". The new application is called "SoloPack Test and Calibration".

If I let the new application just create the databases it can access them happily. However, the old application can not.

The old app, access the new DB, throws the exception message: {"Could not load file or assembly 'SoloPack Test and Calibration, Version=, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)":"SoloPack Test and Calibration, Version=, Culture=neutral, PublicKeyToken=null"}

I've attached a zip with the C# class, and the two databases that each application creates, along with a file containing the exception details.

Thank you!


mthorp wrote Nov 8, 2016 at 10:35 PM

Sorry it took me a while to come back to this. So the short answer is that at this time, this is an unfortunate byproduct of how the PersistentDictionary works. The data types used for the key and value are serialized into the dictionary as a way of maintaining a consistent schema. With the current scheme, there's just no way to change the namespace and match that schema as the serializer used takes into account the assembly.

Migrating the data is unfortunately your best bet to remove the dependency on the old assembly.

blelacheur wrote Nov 16, 2016 at 1:26 PM

Thanks for getting back to me.

Okay, I will add a data migration component into my update process.