John,

Yes, I would be happy in a VFP-only world, with qualifications.
I am all for COM and ActiveX and other tools/facilities.

What I am *NOT* for is limiting VFP (apparently) in order to sell other products like SQL-Server.
No, I do not at this point use VFP Server(s), but that's because of the present limitations of such, at least as I understand them in VFP 5.
I would *love* to use VFP servers, in the sense of a server - a server which can handle *many* concurrent requests *AND* a server which can "serve-out" request data, be it as records or record-sets.

The oft-quoted Euro-Tunnel project shows that there are ways around the 2-gigs per table issue. The recently publicized JFast military application shows that SPEED and complexity are still strengths of VFP. In other words, with a VFP which FACILITATED VFP-to-VFP communication *including intrinsically doing the I/O for clients and giving clients back the record(s) they need in the "native" format expected, we could have our cake and eat it too!

Two major reason always given for going to SQL Server (or any other SQL-type back-end) are:
1) much greater protection offerred by a back-end solution;
2) much greater data sizes available.

Well, the "protection" aspect could quite well be taken care of *IF* we could run a VFP Server which would be in a controlled, power-protected environment where pulling the plug or sudden turn-off or power failures couldn't happen. It could be responsible for all database read/write actions, SERVING clients the data they request.
Sure, this might be much like what SQL provides, but it would be at a much lesser cost and it would involves far less secondary costs like education/training or overhead, etc.
There would still be a use/need for SQL Server type capabilities, but a much wider scope for VFP-style applications. Users would then have a legitimate CHOICE.

Hopefully, that clarifies where I'm coming from.

Cheers,

Jim N


>>We have a VFP Automation server capability but it won't let us do *naturally* >what VFP does best - access the data we need (and give it back to us in the >customary manner). Yes, we can get at data, but it has to be done through >parameter lists, usually with parsing of some string containing field >information. Try to pass a record set that way.
>>
>>I understand that something called ADO takes me some distance along this path. >But I also understand not all the way! What's wrong with having VFP do this??
>
>ADO does get you there - at least as far as passing data around. If you are referring to UI issues, then thats another matter all together.
>
>Jim,
>
>I get the impression you would be happy if it was a VFP-only world. Your post bascially says you like building mono-lithic VFP apps. If that is the case, then
>the toolset works well for this. You mentioned you are using VFP servers. If this is the case, you are then getting into the world of components.
>
>Are you advocating that COM conforms to how VFP does things? I think you will be in for a very long wait indeed.