>>So ok, thats my introduction of this article and my $.02 worth of why I feel this is one of the most valuable VFP class related documents I've gotten my hands on so far. Lets have some more opinions about why these classes would be useful. I'm particularly interested in anyone's insights as to when an implementation like this might not work, and how the functionality of the Data Manager component might be adapted to a developer's particular needs/situation. So lets hear it... what's everybody else think? :D)
>
> We had a very lengthy discussion about the implementation of this idea at our site.
> One question or concern that popped up was the thought that any customer we would sell to that did not want to use SQL Server or other back end would not benefit from the speed of VFP's native table access if we used ODBC to access the VFP data.
> Another problem with it (only for us) is that we already have the application somewhat completed and did not want to redesign our base data access.
>
> I too hope that others will join in with the discussion because we would like to implement something like this in our next release.
>
>
>Wayne Myers

I read the article, and I didn't see anything that required ODBC. The connection manager class could be subclassed to manage a connection to an ODBC data source, but it could also execute commands in the VFP environment. Then all access to VFP tables would be made via VFP's native table access (probably via macro-expansion of an SQL statement that the behavior manager created).
The value of the Abstract Data Classes is that all details about where the data comes from is hidden from clients (including but not limited to table names, local/remote access, location of native files, if desired even the field names) . Since none of this information is known to the client(s), any of it may be changed without affecting any clients (so long as the specified cursors are created in the appropriate data sessions).

HTH
Ned Ames