>I am attempting to design a 3-Tier design (first time for me) & I am coming up with lots of questions, especially as relates to the data access (using parameterized views & cursors):
>
>1. Are the source table & the view/cursor generated from it, BOTH part of the data layer, or is the cursor part of the interface or business layer?

A cursors is an object in the layer it's used. It could be part of one or all three, depending on how you need to use this object. For example, you retrieve a customer record. Depending on how you access the data and what kind of data it is, the cursor may exist in the data layer immediately after retrieval. You then may convert the cursor to XML or ADO and pass it to the biz layer that then simply passes it directly to the UI where it is converted to a cursor again to bind to the form controls.

The user then clicks the Save button. The cursor is then converted to ADO or XML and passed to the biz layer, where it is converted again to a cursor for data validation.

Here, the cursor exists in all three layers...it just isn't the same cursor.


>
>2. Are the form's grid & controls to be controlsourced to the cursor, or linked somehow via a "data object", or what?

A VFP grid can only bind to a cursor, table, or view. Other controls can bind directly to and ADO record set or properties of an object.

>
>3. Can the interface directly address the data layer (such as, for lookup data in other tables, or other non-edit uses of data), or does it always have to access it via a business object layer?

The UI should never directly access the data (if it does, it is two-tier).

>
>4. Can interface controls store "oldvalue" values to compare to user input, to detect if values have changed, or should this always be deferred to either the business or data layer (via "GetFldState" or such?)

I don't do it that way at all. When the value of a field changes (detected in InteractiveChangeEvent), it changes the value of a facade object (this object fits between the UI and the biz) to say "EDITMODE".

>
>Thanks,
>Randy W.