I agree on all points. i can see where a data layer could appear backend agnostic to a business tier (and in it should ) but under the hood there is still translation and optimization being done between the data tier and the data store - whether coded by the developer or built into something like EF

It sounded cool in 1996 when we were thinking "someday" it might be nice to upsize our DBCs to SQL, but when the time came to actually do it (by then end of the decade) even well designed n-tier apps with frameworks like vfe that used remote views exclusively and you didn't have to change anything else, still required analyzing each view for compatibility and efficiency against SQL Server. The lv_ rv_ thing just didn't work in anything serious.

>I've done the switch over thing with lost-common denominator queries, but I really think it does the customer a disservice. By not optimizing the query for the environment, it makes queries that don't run as quickly for the customer, hurting their business. Now, one might say that a few milliseconds here and there don't hurt, but add that all up, and you can get quite a hit.
>
>It's interesting that many in the VFP world pushes query ubiquity while it seems to me that the rest of the industry has moved past that to coding the query for the best possible performance, even it if means rewriting code. Can we honestly say that we NEED a single application to talk to DB2, Oracle, VFP, SQL Server, Informix, MySQL, Advantage, Access, and all other databases? That just doesn't make sense to me. I've never seen an application that touts that. And if you did, you'll use none of them effectively and all them crappily.. I've seen applications that say, "You can choose between Oracle or SQL Server", or that require specific database, but never one that says, "BYODB". What happens if your customer wants to go NoSQL?
>
>Really, the best design for supporting multiple databases is one that has a DataAccess layer that is designed specifically for each back end database, and then the result is either mapped directly or transformed to an internal schema that will be common to the application. And guess what....you can change it all with a couple of configuration lines once the DataAccess layer for the specific database is written.
>
>
>>PMFJI -
>>
>>I came from the YAG Codebook tree and VFE began there in its approach to using remote views. We believed at one time that with lv_ and rv_ and the stuff we had in the framework we had acheived "all you gotta do is" for switching from local ( against VFP tables ) views to remote ( SQL database ) views. Our cursors would work against v_ remote views and with the flip of a switch we could go from local to remote. Great theory and in fact with three lines of code we could have the views look at VFP data or SQL data quite easily. And in carefully crafted demos it looked really cool, like the stuff one dazzles crowds with in "all you gotta do" demos at conferences. ( remember just dragging a table onto a VFP form and having the audience go "Ooooh" :-)
>>
>>Spent the last 10 years of my VFP development doing all my own development against SQL databases and mentoring a lot of projects and doing a lot of conversions of DBC/DBF projects to SQL Server and I never saw a case where anything but the simplest remote views worked against either backend. Syntax just too different for anything beyond very basic stuff. Typically out of 200 remote views written against VFP tables I could use 30-50 without syntax changes. Yes, two different views DBCs - one for VFP and one for SQL could work but I just never was able to get around some very basic stuff about VFP vs TSQL remote view syntax.
>>
>>Have you really figured out how to get around this? When you say you can switch to any backend with three lines of code you are describing something I never saw in practice.
>>