David..

>>and I'm prefer a native object oriented solution to a proprietary technology.

What is proprietary about ADO? ADO/OLE-DB is COM after all. It works in a lot of scenarios. It is an open standard.

To do what you are asking, you need an object. Tables/Cursor are not objects. Therefore, you would need some sort of representation of a table/cursor.

Ergo - ADO!! or XML!!

I suppose if you don't like ADO, you could roll your own solution by creating a custom VFP class. But why bother? MDAC is a fairly standard thing to have anymore. And, if the machine does not have MDAC, it is a snap to install.

FWIW, in all of my ADO talks, for the past 3 years, I always started my talk with "Would'nt be cool if you could pass a table as a parameter to a function or method?" That is what ADO provides.

I think your beef about proprietary technology is a little off-base. If you don't want to rely on external components, that is one thing. I can't fault you for that. Multiple components increases the complexity of installation and management. An all-in-one solution fixes that problem, but creates problems as well. For example, an all-in-one solution is limited, a fixed space. With components, you can extend your boundaries. COM allows this. Yes, COM is a MS technology. However, I would not call it proprietary. It is an open standard after all.

With that said, you critique is well taken. You are in the right church, but the wrong pew.

< JVP >