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

Yep I have. The trick is to be sure to setup all your tables properly at the onset. One example is the date and time fields types - in SQL server there is only datetime so you'll want your VFP tables designed the same way. Oracle there is no boolean datatype. Little things like that will cause headaches and make you write code specific to the backend you're using IF you don't plan things out properly from the onset.

The 3 lines to switch backends (via the remote view's connection string) is like this:

llDataSourceSet = DBSETPROP(mydatasourcename, 'CONNECTION', 'DataSource', mydatasourcevalue))
llUserIdSet = DBSETPROP(mydatasourcename, 'CONNECTION', 'UserID', myuseridvalue))
llPasswordSet = DBSETPROP(mydatasourcename, 'CONNECTION', 'PassWord', mypasswordvalue))

One thing I do not do is use local views on the VFP tables - just the remote views - and the syntax between backends will work.

...now there are some places where I'll use a local view to join multiple remote views - sometimes even ones with different backends.
You can have a remote view that connects to DB2, another that connects to SQL Server, and then join them both in one local view. I soon expect to hear people out here saying I'm crazy for doing that too - but I've done it 100's of times and even made these updateable across different backends and thus far I've never had a problem.

I'd say I have about 25 or 30 apps I've written using this approach and another 8 or so that I've updated to use different backends. Only real gotcha I've run into

...I should really write a whitepaper or big article on how I'm doing this with some examples - I've had excellent success with it.

>>>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 :)