John,

I think you hit the nail on the head with a couple of the issues. Specifically, I do prefer independence from external components. I make several exceptions, but I do prefer to create my own ADO-like data objects.

Still, there's a big difference between passing a table/cursor to a function, and having one returned. I don't know if I agree that tables and cursors would have to be objects to be returned. Why not just return a work area, and have the cursor open in that work area? Also, I'm not sure I totally agree that tables and cursors are not objects. Certainly, in the literal interpretation of the word, they are not OOP objects. But I think a philosophical case can be made that they are objects, and in many ways, can be treated as such.

On a related note, I have done some reading of late on Object Oriented Databases. Though tables and cursors are not strictly objects, they certainly could be. I think that might be an incredible enhancement to the language. It seems that the fundamental elements of objects - encapsulation, inheritance and polymorphism - would be very powerful features to have in tables.

Finally, though ADO is perhaps considered an open standard, is it really open? Do I have access to the source code? Can an ADO object be implemented with Oracle running on Unix? It's not a standard like HTTP, IP, XML, etc. It is a proprietary technology available to anyone using an MS operating system. Personally, that's most of what I use, so I don't care, but I'm not entirely comfortable putting all my eggs in the MS basket.

David

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