>I would disagree that VFP's native data handling is irrelevant. Most data manipulation done in an application is not in record based operations but in set based operations. Getting C/S data into a VFP cursor and then using VFP's native DML is far superior to VB's data handling capabilities.
>

Depending on the type of data manipulation going on, I might actually rely on stored proc's instead. Jim, I totally agree that VFP's local data handling capabilities are better than VB's. VB does not have its own ability after all. Most C/S apps don't really need a lot of data munging. Therefore, VFP's advantages in this arena are not considered that material. If they were, VFP would be playing a bigger role in the C/S arena today. And, even if data manipulation were required on a row by row basis, ADO makes it simple. Performance should'nt be much of an issue since the records drawn from the server should be minimized. Heck, if need by, T-SQL on SQL-Server can do row operations as well.


>Again, I have to disagree. While you are right that VB is better with ADO, ADO is not the end of the world. VFP is quite good at getting data from a C/S backend into a VFP cursor. Once the data is in a VFP cursor, there is no rival to munging that data for VFP.
>

Let's face it, other than the Grid, there are no other controls in VFP that require a VFP cursor of it to work. Even if I had a lot of data munging to do, I would not want to do it on the client. Rather, I would want it in the back-end, or perhaps the middle tier. In these cases, the ability to work with VFP cursors begins to break down since they cannot be passed around like ADO Recordsets. There is no question that working with VFP cursors makes working with data a snap. But, it does box you into an implementation. All I am saying is that the ability that VFP has in working with its own cursors is not the big advantage that folks make it out to be....

>So, let's see; VFP has containership, VFP has inheritence, VFP has polymorphism, VFP has aggregation, and VFP has composition. VB has composition, VB has aggregation, and VB has polymorphism.
>

I think this is more of a theorhetical distinction than a practical one. VB in fact does have a containership model of sorts. The difference is that you need to write code to surface the interfaces of the contained members. Most OO purists out there might argue that this is technically the more correct approach. While in thoery, they may be correct, it is a pain in the ass. It would be great if VB had the same containership model as VFP. In any case, it can be worked around with not too much effort, eventhough it is a bit of a PITA!

>
>Again, one must do something with the data after it is fetched, that is unless one is writing read only database systems. Once the data is in the VFP cursor, forget VB in the data munging contest.
>

In a C/S app, how much data-munging do you really do? I think a lot of munging is often the result of an app that has outgrown it's database design. Or in some cases, is implemented from the start because of a flawed design. Yes, there are times when data needs to be munged a bit. VB however, has made a lot of strides in this arena. All I am saying is that while VFP can handle much of this work better than VB, in the grand scheme of things, it is fairly insignificant.

>Remote views are not the only way to get data from a backend into a VFP cursor (as I know you are aware). SQL PT is not rocket science either.
>

SPT requires a lot more knowledge of what is going on. Most folks tend to gravitate toward RV's. SPT is very robust, and when compared to RV's, it's a no brainer as to where to go. Where it all breaks down is in thier implementation, the VFP cursor. I won't say multi-tier here because that is an architecturual distinction, not one predicated on technology. After all, you can have the first and second tiers on the workstation. That still is multi-tier. Rather, I am talking about a component, WindowsDNA architecture. Here is where the VFP cursor breaks down. You can't pass them around from component to component. Yes, we can create COM Components in VFP. However, the lack of event support really forces you to make some design decision that you would not otherwise make if you have the ability to both raise and respond to events. With VFPCOM, we can only respond to events. We still cannot raise them. And, in async operations, this becomes a real limitiation.

>Your win this one about teh events. Although, with stateless COM servers I don't necessarily see raising and responding to events as particularly critical to implementing a middle tier component.
>

Check out COM+ events and queued components. Events are at the heart of if. At some point, a component will come to life. It will fire an event to signify that something has occurred. Something needs the ability to respond. Granted, the component may go stateless again, but events are important. Heck, the component itself may use the events.

>
>Hands down for what part of the system? VB can't compete with VFP for data munging. VB has some advantages for middle tier, but not enough to "bury" VFP on that tier, and VB has no abilities in directly handling data by itself.
>

I should not have said hands down here. I agree that VFP is better than VB for data-munging. The point I was trying to make is that each area has it's own strengths. Too many folks are willing to dismiss VB on the one simple fact that VFP is a better data-munger. The fact is in most component-based apps and C/S apps, the data-munging aspect is not a primary focal point.

>I really disagree with this statement. VFP is clearly better at munging data than VB. VFP has a clearly superior development model (OOP RDBMS) than VB. Truthfully, VB has advantages and so does VFP, but finding VFP the tool of choice is no stretch.
<

I agree that VFP is a great tool. However, I disagree that inheritance and VFP's ability to munge data are reasons alone to dump a scenario when VB could be used to access SQL-Server, which is where this whole thread started...