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

Ah, okay. Missed the context here, sorry. I thought you were referring to the original query.


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

I don't know if I'd call it trivial, but I'd agree that it's far from an insurmountable problem. Still, it is something that needs to be worked around vs. VB's capabilities in that area.



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

I think in its current form, most people might prefer ODBC in VFP. I very well could be wrong, but I think the extra effort might keep people in ODBC until VFP work with ADO a little better. I certainly don't prefer it. Who do you think is doing testing on the VFP OLE DB provider? <g>

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

Umm, actually, no. I was referring to DBFs.

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

This is probably the main reason for my response: you get back something VFP well knows how to handle.

> However, working with ADO recordsets is not that difficult.

Of course not, but it is some development overhead.

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

I would agree. If you're dragging rows across a wire, don't be dragging 10K of them, or you're defeating the purpose of a C/S app.

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

If it's easy and native vs. not-quite-as-easy and not native...hmm, I'd have to think about that one. <g>

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

I'd plead guilty to that. It's been busy around here lately, and I sometimes don't spend the time necessary to lay out detailed responses. Just like the rest of you, I'd don't get paid to do this either. <g>

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

Now, John, that's cheating. <g> That's the reason I responded with the caveat along the lines of, "it depends on what the app is being developed for". If you're going to be passing data through COM, well of course you'd want to use ADO. COM clients sure aren't going to like it if you pass them much else.

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

I think we could agree (or maybe not :-) that for your everyday, monolithic app that a lot of folks are still writing, USE MyTable is still the way to go. Start throwing in client/server, COM, etc., and all bets are off. It's a tough question to answer without having a lot more detail than what we've been given, MO, though I get the feeling you don't share my sentiments. <g> To me, it's kind of like asking, "should I upsize my app to SQL Server?" Well, that really depends.

Mike Stewart