>JVP,
>
>We did our first Oracle interface in 1995 and have maintained since. It all seems quite straight-forward, to be honest.
>

Do you use stored procs - to return result sets? Do you use the native Oracle cursor functions to do what is traditonally done on Fox/Client side? Do you use Oracle Functions to run the many-side of data as a varchar2? Do you use the Oracle Driver or the MS/Oracle Driver. There are big differences between the two.

If you are rendering client-side sql, then yes, it is straight-forward. As you know, when I implement an RDBMS back-end, I tend to go far beyond the basics - for the purpose of exploiting what the RDBMS has to offer..

>
For the Oracle-specific stuff there are vast numbers of excellent articles and white papers in the public domain by gurus with a decade of full-on Oracle experience, though possibly not in MS-oriented magazines for VFP or dotNET, which I assume is the niche you have identified for your article?
>

Actually, there is little in the way of practical stuff.. Lots on the latest techniques, and isolated topics. Little on "putting it all together..."

Just at FYI, one the folks that consulted for the firm I worked at look at some of my PL/SQL Code. When I told him I only had 6 months of experience with PL/SQL, well...his jaw dropped... When I told him what I was doing with SQL Server and that I had experience with other - strong-typed langauges, it clicked with him.

Nice try on the knock though JR...< s >...

>
So what will you article be about? In the interests of harmony I will not even pretend that I think your article must have been about how easy it is to use Remote Views against Oracle, even though that might explain the events of which you complain ;-)
>

RV's and Oracle...what a joke... Why would I bother with a technique, that in the best of light, cannot be considered a suggested practice in light of more compelling alternatives. I have seen ONE RV implementation that actually worked - because they worked outside the box. In the process, while it worked - it required way much more effort than what was required. At the surface, it may seem like an advantage that because you can do tableupdates -and have your updates "magically" go to the back-end, upon a more deeper/through analysis, it is an illusory advantage at best. Either in performance, maintanance, budget, reach, etc - RV's don't scale.


No, it won't mention RV's. And, thanks to Dave, it won't cater to the specific issues that are/would be of interest to VFP (which there are more than a few). No...it will be in the .NET context.