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).
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... ;)]