I agree, Craig.

Mainly because, except for switching from VFP to SQL Server, which I've seen and done frequently, I've NEVER seen a company even think about changing from one backend to another.
In the small to mid size space where we work, SQL Server is the overwhelming choice of most companies for too many reasons to go into here.
I saw one accounting software manufacturer that sells to our market go thru hoops and denigrate performance to handle multiple backends and fewer than a handful of installations, out of tens of thousands, have used backends other than SQL Server.
If they had done what you suggest, they'd have save millions and had a much better product with no perceptible loss of revenue.





>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.
>>