>
Where was SQL Server ever mentioned? Everything I posted was prefaced with "if you're accessing native VFP data...". Don't change the subject.
>

You replied to Terry Voss who mentioned SQL2000. One thing you will learn about me. I pull nothing out of thin air. Also, the discussion of Remote Views implies non-VFP Data. The Non-VFP data in this discussion is SQL Server.

No subject change here....< bg >...


<<
I don't believe anyone ever questioned that.
<<


The question asked of you by Terry Voss was this:

If one is using SQLserver2000 from vfp6 do the advantages of using ADO increase?

Your reply was this:


Not in my opinion, no. You've still got the problem of binding to controls. Remote views and SPT work just fine, and you can bind to the results. Unless you've got to use something like RDS, the extra work involved outweighs any advantage ADO might have.

Since VB and VC++ have no easy, native way to access data, technologies such as ADO are necessary to make data access possible and easy. VFP developers already have an easy, native way to access data. Why switch just because something else is the hot new technology to use?



Let us disect this.


The question dealt with the relative advantage of ADO use in VFP with respect to using VFP Data or SQL Server Data. Specifcally, is there more of an advantage to using ADO in VFP when SQL is involved.

Your reply was that no advantage existed. You cited the issue of bindng controls. Binding controls is a very non-crtitical function. At design time, it is "nice" to have the whole drag and drop thing there for you. But, it is a trivial task to get around. So, as far as being a major decision factor on whether to use RV's vs. ADO, it does not stack up. WHy? Because there are more crtical factors facing the developer.

You go on to state that Remote Views and SPT work fine. Well, with SPT, you have to manually code. So, the whole binding issue is not automatic. With RV's, yes, you can do the whole drag and drop thing. However, with RV's, you cannot use Stored Procedures. For the best scaleability, security, and so forth, stored procs are a must. This pretty much rules out RV's.

So, we are left with either SPT or ADO. SPT = ODBC. ADO = OLE DB. With SQL Server, working with the OLE-DB provider is light years ahead of working with ODBC. For starters, I am working with objects. Second, it is the platform/paradigm that is being innovated by MS. Finally, it flat out performs better. Based on that analysis, ADO/OLE-DB wins.

As a MS person, I am surprised you are on-record here preferring ODBC over OLE-DB....< bg >...

As far as Fox developers already having an easy/native way to access data - I gather then that you are referring to RV's or SPT. SPT is not bad, but for the reasons enumerated above, it is not as preferrable to ADO. For multi-row results, you do get a VFP cursor back. And, that advantage cannot be discounted. However, working with ADO recordsets is not that difficult. Now, folks at times will then trot out - "Gee, what if you get back 10,000 rows, how does ADO stack up". I would reply that in the normal course of a C/S app, you should not be getting 10,000 rows back. In the C/S world, that is a flawed argument. At best, it is trying to superimpose something that Fox does will LOCALLY. However, you still have to get the data back. Again, it is flawed argument.

Anyway, again, as far as Fox developers having this "easy/native" way, you at least impling that it is just as good - perhaps a substitute, one that is on equal footing with ADO/OLE-DB.

Remember, the context got shifted to SQL Server, not native DBF's. Go back to Mr. Voss's post. ADO/OLE-DB, for the most part, is the better way. That point can be debated and argued on a number of levels.

In my not-so-humble opinion, you did not give the question the requisite analysis it required.


>
It has merit if the person posting the original question is accessing DBFs. The pros and cons of DBFs vs. a more costly backend DBMS were not mentioned in the original question. What was asked was whether or not they should use ADO. If they are accessing DBFs, I would think it difficult to argue that ADO is the best choice for accessing that data.
<

As opposing counsel here, I'll take that argument..< g >...

If I am building COM Components, ADO is the best way to both access and pass data around - and to update data.

If you are not building COM Components, but you are performing automation operations, ADO is still the best way to access data since you can then pass the ADO recordset to the automation server. Of course, the automation server could also access the data directly - using ADO. It is a matter of how you are going to architect the scenario. Each has its own pros and cons.

Difficult to argue? I don't think so. I just found 2 ways to successfully argue that point. I could probably formulate more, but there is no need...


Back to you...