>>First of all, let's decide that this is not detailed procedural approach, ok?
>
>OK, how do you write non-procedural xBASE?
>
>>The maintainability usually means that all minor changes to a system can be done simply enough. SImplicity here usually means that application design allows to make these changes seamlessly. This, in its turn, usually goes to OO-design of the application. IMO, changing of data engine cannot be considered as minor change and should not be included into maintainablity notion. Do you agree with this? I use the word 'usually' because it's really elastic definition.
>
>How does the use of VFP's SQL constructs make the data services class more difficult to write and cumbersome than xBASE approaches? Does the mid-tier operate against the native tables, or does it ask the data services layer to present the working subset it needs. The UI layer? What interfaces should be provided by the data services layer, and should it be acceptable to bypass this layer entirely?
>
>My premise is that the UI and data services do not retrieve and alter the database tables directly. They ask the data service layer to act on their behalf, at least in the case where the data may be altered. They act on cursors and views; their operations have fixed and distinctly specified scope. Does this differ significantly from what you expect and how your application interacts with its data?

It also interacts through cursors, better say through mix of objects and cursors. One record is held by object, recordsets are held by cursors.
Could you tell me: is cursor XBASE or SQL notion? I ask you because IMO we spend too much ardor on definitions and this may harm other considerations.