1

I'm making some tests using ManagedEsent interface and I wonder if someone here can clarify on this:

  • Inside a transaction I do an update(insert a record) and then rollback the transaction

If I look at the database with EseDatabaseView I can see the "uncommitted" record listed in the table. Going esent.dll again doesn't give me the record.

So, using the esent api the record is not committed (and not visible); and using EDV (I guess it reads directly from the file) the record is there.

Is this "normal" behaviour, does ESENT "always" write record into the file and if it is not committed it just does not reads it? Is it a bug in EDV showing it then? Or I'm missing something here?

Ian Boyd
  • 246,734
  • 253
  • 869
  • 1,219
Arkej
  • 23
  • 6

2 Answers2

0

As in most databases, esent is using transactions. They are stored in the LOG files that you can find in the same directory with the EDB file. If you want to access the data within the transaction LOG files, you need to flush them into the database. Use the following command to do that: eseutil /MH database.edb

More information about esent's transaction log: http://support.microsoft.com/kb/240145/en-us

Fotis MC
  • 323
  • 1
  • 2
  • 12
  • Ok, that's not what I was asking but reading it again I see it might be confusing. The api way is correct and as the transaction has been rolledback the "inserted" record is not "visible". What somehow confuses me is that EseDatabaseView(I was unable to find another tool able to show the db content) shows the same record as part of the table as if it was commited. Is this a consequence of snapshot isolation and EDV reading raw file structure or else? – Arkej Nov 27 '14 at 07:57
0

Judging by the description of EseDatabaseView ('esent.dll (The dll file of Extensible Storage Engine) is not required to read the database.'), it sounds like they try to read the database file directly, not using the ESE APIs.

Is the database shut down cleanly first? Confirm with esentutl -mh [database name], which dumps the database header. Look for something like 'Dirty Shutdown' or 'Clean Shutdown'.

Dirty Shutdown: You may see transactions that have not been committed (or rolled back). You need the information in the transaction log files to bring it to a clean state. Clean Shutdown: Everything is in a clean state. You could potentially delete the log files if you want.

My guess is that the database was shut down in a dirty state, and the tool is reading the data that hasn't yet been rolled back.

-martin

Martin Chisholm
  • 461
  • 2
  • 6
  • The state of the database is 'Clean Shutdown' as I'd expected after a transaction rolled back. That's what made me wonder in the first place. Allthough I might not have been calling JetTerm instance. I'll make a test with 'regular' instance shutdown. – Arkej Dec 01 '14 at 08:47
  • Martin, I just did a regular instance shutdown and EDV keeps showing the rolledback record. If it change anything, in the transaction there is an insert(using managed api update class) in one table and the second one in another table. The second one fails because there is already a record with specified key in the table. That's all expected. After this the whole transaction is rolledback and using esent.dll(managed api) the state in the db is correct. EDV keeps showing the first inserted record in the transaction. I guess it's a bug in EDV. – Arkej Dec 01 '14 at 09:15