>
>OK, now that I look at this again I see what your saying. Your statement here about the Abstract Data Classes kind of serve as replacement for the VFP view seems correct, although it's somewhat of a scary thought. Everything else we've seen before this article always stressed that Client-server apps should use views. And it makes me wonder, the article's title is afterall "Data Classes that make Client-server easier". So does "easier" mean cursors instead of views? hmmmmm.... don't know about you but I believe I need to think on this a little longer.

IMHO "easier" means hiding the details of data access(table names, local/remote access, back-ends, etc.) from our applications.
>
>So where we stand on this first issue (I think?) is that the downside of using the cursors the way the classes are presented in the article is that we loose the ability to do buffering and thus supporting more than one user making changes to a table. And we got two possible alternatives of adapting these classes, either use views instead of cursors, or make use of USE DBF(...) AGAIN.

Multiuser support can be provided by buffering the target table. We write changes in the cursor back to the buffered target table. TABLEUPDATE() is issued against the target table and VFP handles data contention as usual. I just didn't see any support for this in the sample.
>
>>As to USE AGAIN vs. SQL-View:
>> (IMHO) If the technique will continue to work in latter versions of VFP, it offers a simpler and more flexible way to present data to the user and collect data from the user. The only real drawback is the fact that all cursors I have been able to create are 'table cursors' whose update properties cannot be set. This means writing code to grab updated records and apply them to the target tables, whereas views handle this automatically.
>
>So ok, this technique of USE DBF('cursor') AGAIN ALIAS something is new for me and I only started playing with it this week. But what I'm seeing when I try it is that I can still set table properties to enable buffering and whatnot from the Data Session window. What do you mean by Update Properties?
I'm kind of wishing here <g>. If you look at CURSORSETPROP() in the help file you will see properties like Updatable and UpdatableFieldList, which are used for cursors which are "view cursors". The cursors that we create are "table cursors", VFP's term, not mine. If it were possible to set these properties for cursors that we create, then updates could be applied against one or more target tables automatically, just like a view, unfortunately the SourceType (see CURSORGETPROP()) is read-only. Maybe I should drop this is the VFP wishlist?
Ned