>Hi Roxanne,
> Glad you started this thread. I have looked at the article and sample code and have a few observations:
> 1.) As I note in my reply to Wayne Myers, although the authors purpose was to simplify client-server applications it appears that their design is by no means limited to client server. The same structure works admirably to control access to local data. Indeed, it hides all details of the data source from its clients including if it is local or remote.

I agree, my review of the source code for the sample app led me to believe that you could easily make some modifications to provide the same flexibility these classes offer for local data.

> 2.) The sample code does not appear to be able to handle memo fields.

Didnt really notice that, but then again all my data comes from a Unix billing system and I never deal with memo fields.

> 3.) I could not find any multiuser support. The cursors that are produced are buffered, but as they are table cursors they cannot be tied to a target table for updates as a view could. Where do you specify the buffering mode for the target table of the cursor?

I assumed this point was kinda of glazed over by the authors to keep their sample app simple. I hoping to implement these abstract classes with views instead of cursors, which is why at the end of my initial post on this thread I stated an interest for input on adapting the Data Manager to meet other needs. If you look at just the functionality each major component in their model (diagram pg. 36) it seems logical to me that you could perhaps replace cursors with views by only modifying the Cursor Manager. The connection Manager, Behavior Manager, and Data Environment classes should still work pretty much the same I would think... what do you think?

> Finally a couple of possibilities:
> I experimented with USE DBF("Query") AGAIN and found that the resultant cursor is still read-write(as in FPW) and that it can be buffered. This approach could certainly handle memo fields and would be extremely fast. It should also be possible to buffer the target table for updates from the cursor, and gain access to VFP's native update conflict detection and resolution. Hopefully someone will chime about the USE AGAIN if there is any problem (as it is not exactly a documented feature).

Thats a real good point Ned, I had printed out that Thread from last week (I think) knowing it would be useful somewhere. Do you think USE DBF(...) might be a more viable adaptation to build in better multi-user support for an app based on these classes then going with my original thought of modifying the scope to use views instead of cursors?

-Rox