See also http://vstfdevdiv:8080/DevDiv2/DevDiv/_workitems#_a=edit&id=240698 which describes a situation where a user took manual control of the connection but had it prematurely closed for him by EntityConnection code.

Checked in some baseline tests to record the status of the EntityConnection vs the store connection as of now - #86c59d6

Using opened connection would be very useful when using EF with System.Data.SQLite.

This provider have a function "SetPassword" which allow to open encrypted database without putting the password into the connection string. This must to be call before Open().

I have found no way to use this function outside or inside my DbContext.
The only way is to include the password into the connection string.

I've tried to use SetPassword:

• before the DbContext constructor: fail
• after on mySQLiteConnection object: fail
• after on dbContext.Database.Connection: fail
  

One thing could work, I need a callback (event) on the DbContext when EF open the connection (OnBeforeOpen) so I could call SetPassword here.

Thanks.

Pease also consider the following scenario. A model-centric application is built around a public, “customer-owned” entity model using the EF model-first approach. It primarily deals with the entities defined in the model (e.g. Products, Suppliers, Orders, and so on). The core data processing is performed by means of ObjectContext. There are some supporting facilities in the application, however, which require their data to be stored in the same database and even within the transactions originated in the core data layer (e.g. diagnostic/audit logs, license checks and so on). The data structures for those facilities should not (and cannot) be declared in the main entity model. Moreover it makes much more sense to build those facilities using EF code-first approach (DbContext), since their data are just a serialized state of their run-time objects and the program code is the central design/maintenance aspect in this case (not the data model).

Currently, for this to work, a separate connection has to be made each time some DbContext-based facility needs to participate in the core transaction. Besides the inconvenience of re-establishing a connection by borrowing all its settings instead of re-using the connection itself, it leads to promoting the transaction to distributed and thus to those infamous “DTC not available” problem in (the most usual) case of a single database/server.
Given this scenario, a seamless connection transitioning between ObjectContext and DbContext is badly needed. Any cooperation on this (real) scenario goes without saying.

Checked in change #56e510c. Updated EntityConnection State so it now tracks the underlying store connection State. This is a breaking change as we will now report a different (but more consistent) state for the EntityConnection.

Checked in change #6869eba. Couple of updates to tests and testing that StateChangeEvents are fired at the correct time.

Changed sync mechanism to subscribe to events on underlying store connection. Commit #5d14eca.

ANother small commit #1198350. Just to update an error message.

@mzhg - I think this is outside the scope of this bug. However it is worth considering - there is an ongoing discussion about lifetime hooks in general here http://entityframework.codeplex.com/discussions/399192 which you may want to join.

The latest changes seem to comply with the scenario described below. Just make sure the current behavior is not changed until the official release.

Checked in and verified