Mapping disparate EF data providers to separate EntityManager's in the same process

I believe all you need is a separate SSDL for the other provider as the article on infinitecodex suggests.  You can do this statically if you know that the path to the other provider will be constant (e.g. localhost).  DevForce doesn't interfere with the CSDL, SSDL, MSL bootstrap that the Entity Framework uses, so any solution that works for raw EF should work with DevForce.

I think we are getting closer to being on the same page, ;) but my lack of brevity must make this difficult.

By 'replace' are you referring to the connection string in my key resolver, or physically overwriting the EDMX SSDL file output? If replace means updating a connection string, I am pretty sure that is easy to do (using the IDataSourceKeyResolver we already have in play), if replace means playing with files based on the moment of need... I think I will need to find another way to solve this problem...

---
I should stop here. The above really is my follow up question... The remaining wall of text is another colorful attempt to convey of what I was hoping to accomplish and little more detail of how given what I know of DevForce implementation. My hope is this somewhat more concrete example clears up my original intentions once I got past the SSDL issue...
---

What I really want to do is create two separate instances of an EntityManager. The first to fetch pages (skip/take, etc) from the SQL Server database and then put those pages into the second EntityManager which is writing down to a VistaDB database engine. The database engines don't matter so much other than they give the example some concrete starting point (which happens to be my starting point). But those are the technologies at my current disposal. I can't change SQL Server 2005/2008 but I might 'influence' the local DBMS engine we use, as long as it fits the requirements of the deployment limitations.

Is that even possible in one process? Heck, I was hoping to do it in the same method call per query against the server ;). Fetch a page, dump a page, make sure nothing is in cache, repeat till the customer's enormous query completes filling the local data store... or the hard drive runs out of space. Both are acceptable conditions... crazy, but true. This is simplified since there is no CUD happening at all with this data on the server ever (at this point in time).

Sorry for being all weird with the framework. I really need to control what is in memory at any given moment in time. The desire to put it into a local DBMS engine with no size limitation (and is 100% encapsulated in the application) is a very large motivation here. It also makes querying after the fact a lot easier to achieve (especially if I don't have to span multiple persisted files or databases that have size limitations). Not every query result fills the hard drive. This is hardly the common case, but it has become less of an edge case and the support calls are increasing. I would say 80% of the time this is not an issue (SWAG estimate).

Luckily not every customer situation does this, but it happens a lot these days, especially as they add more and more into the collection plans of their telemetry, simulation, and instrumentation data. Occasionally it is a just a mistake on the part of the query maker, but sometimes it is desirable to grab everything and go 'offline' with it. Every time we improve the capability, they just find the new higher limit and push up against it to the breaking point(Moore's law comes to mind). So now the new limit is to be their hard drive size. And they think that is very acceptable way to limit the operations. right or wrong... (I keep saying that...)

I hope this makes sense by the end... (wall of text incoming)

I am trying to produce one set DevForce/EF entity classes to work seamlessly across two separate disparate data providers (in my case a SQL Server 2005/2008 and a VistaDB DBMS) in the same application instance, essentially at the same time (one model to rule them all). With the end goal that allows me to 'easily' move entity data between two instances of the EntityManager's from one manager into the next (using the DevForce API, which is the easy part) as I fetch from the server into the local server. This also allows me to dodge a nasty out of memory scenario I am battling with (a large motivation for considering this approach). I can't keep all my data in client system memory (this is a critical point), but I need to bring it client side for additional processing. This is not a normal grid app (are they really ever?).

If I had the same data provider (E.G., System.Data.Sql) at both ends this is pretty moot, but thats not the path I have been put on at this time. It's a solution on the table, but we want to explore the DevForce framework's support of this EF concept to see if can provide that flexibility, without dictating what EF supported data providers when we are using DevForce in this dual, but disparate, data provider scenario. It works flawlessly in the opposite scenario (a dual, non-disparate, data provider). SQL Server to SQL Server works like you would expect.

To further complicate the scenario. All of our keys are created dynamically (IDataSourceKeyResolver). If this is as simple as adding the second ssdl to the declaration, we are done! I know how that looks... but Ward's blog post warning of name parts disparity has me concerned now... does this tank this effort? Or is the connection string going to win out with dynamically created data source keys? (the latter of which we be doing anyway).

Ward's Warning

Is there no way around it with the DevForce API? Is there a way I can achieve this goal I present? If name parts are ignored and the EDMX naming always wins out, I am wondering if I am just 'simply' out of luck???

I can provide some more details over email/phone (Derick Chung from sales has my contact info, and Albert (last name unknown) was briefed of my situation at the sales call) or just send me an email to reply to. There is some reasoning behind this crazy approach and often I have to remind myself... to ignore the little red flags posted all over the path I am on as I trudge down this rabbit hole. But it really is the last thing keeping me from adopting DevForce as our plumbing framework with wild abandon 100%. It really has worked swimmingly well this far. ;)

-I am using DevForce Universal Express, atm, as I develop a prototype to prove out the working theory in case that makes a difference.

And I am very open to input in case I missed an angle that gets me my end goal (no out of memory condition (server or local) , a seamless EntityManager experience, the ability to quickly search enormous amounts of data locally cached by a DBMS (controlling what is in memory), and one file persisted as a side effected for storage/transfer from client to client later [in that order]). DAL work is pretty new to me, so I have little experience/bias (so far). Although some are forming quickly as I research technologies and methods. ;) But I get to initially explore it in the currently evolved state (I am glad to have missed the hassles of yesterday). I believe there may be something from a seasoned experience I can glean a solution from.

[Please feel free to move this item to an appropriate forum location. I didn't feel this was a 100% appropriate category, but was the closest bucket considering what we are trying to accomplish is mostly done disconnected, but against a local DBMS. Maybe this is all about EntityManager's... Connection Strings... or EDMX EF limitations... you tell me... ;)]