Correct: separate, identical (at table and field level) DBC's. That was the ProMatrix approach (the framework we used, which we chose because it was easily modifiable, which we did a lot of).

The views in the remote DBC are generated, however, not written by hand (as indicated, can be done by hand if conversion fails).

And yes, this is an Enterprise-level ISV situation, where we could be called on to support Oracle or DB2. We do not support DBF's at this point; they are used in development, because our devs don't have to change the SQL DB to do development. The data lead runs xCase2VPM, and that model gets distributed to other devs. A library routine updates their DD to the latest and moves their data over.

Hank

>But this is not the old Codebook approach of using a common views DBC which would translate all lv_ and rv_ to v_ in the cursor class layer?
>
>As I understand what you are saying here, you do have different views for DBC data vs views for SQL server data and are deciding at run-time which to use?
>
>I also see where xCase would be useful in designing and maintaining this approach - especially at the level you use xCase, having read some stuff you've written in that area. ( I was always very ham-fisted with xCase - my own style was too ecclectic and ADD in the days when I was first exposed to it :-)
>
>I assume the business case for this multiplicity of back-end sources is to allow a commercial vertical to choose between SQL and Oracle? Or did you do all this so people could still use DBC/DBFs instead of SQL? ( and I grant you I do remember when that would have been quite a selling feature - especially for those currently using DBCs who were ready to go to SQL as it became more practical for smaller setups - I am thinking of how Accountmate could have benefitted greately in the 90s)
>
>>Hi Charles,
>>
>>we do it with no lines of code: throw an ini-file flag and everything switches over. The DBC gets changed in DataEnvironments in the BeforeOpenTable event. The ConnString gets added in the 1 routine that opens a view.
>>
>>Our way consists of designing in xCase; from which we generate the local DBC. We use the local DBC to generate a remote DBC, massaging the SQL of the local DBC to fit SQL Server -- that process itself is data-driven, although the data in this case is a template in a memofield that controls what we call the function substitution engine. We have an app with 650 tables; and about 1400 custom views (and a set of generated views for each table and table/relationship). Out of all those there are 1 or 2 views that are hand-coded (the code for local and remote gets put in xCase, and the right code gets put in the right DBC).
>>
>>Frank Camp did most of the work on making this work, BTW. Brilliant guy.
>>
>>Hank
>>
>>>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.
>>>
>>>>>No, I understand what you're saying, but I think it's more of a disadvantage than an advantage. I just don't see why you think it's such a great idea.
>>>>
>>>>ummmm...because by running 3 lines of code I can have my app connect to any backend I want without ANY extra work. That's a really nice sales pitch when you're dealing with a client or potential client.
>>>>
>>>>>One other thing...you have to keep SQL statements to the lowest common denominator. That means you also can't take advantage of many features in the backend server.
>>>>
>>>>Yes that is indeed a disadvantage...but I've never run into a situation where it mattered. (yet)....and for me it's worth dealing with the lowest common denominator to have the flexibility of multiple backend choices. If you were selling a vertical market type of application having this advantage is an outstanding benefit.
>>>>
>>>>
>>>>>>I just don't get it??
>>>>>>
>>>>>>From what I see there is no simple way to switch all of your local views to remote views without creating another set of views. There is not some simple 3 line property change like what I can do to switch connection strings to do this - your stuck creating another set of views...thus doubling the workload anytime you make structure changes.
>>>>>>
>>>>>>>Oh my, no. Tables/database, etc should be opened in one location. Again, your way will have slower data access and limits you to VFP 6 and earlier features. It also takes more memory.
>>>>>>
>>>>>>What do you mean by "one location" ??
>>>>>>And yes I realize that using the remote views limits me to VFP6 features - but that's not been a problem for me and by doing so I've made switching backends seamless. The slower data access is so miniscule (if there actually is any) that's it not even noticeable to the user. As for the memory - well if the views are designed properly it's not that much memory and PC's these days come with more than enough memory to handle these things without having to worry about it. And how does a remote view use more memory than a local view anyway?
>>>>>>Sorry to keep pestering you but I really want to understand all this :)