>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?
>
>2. Are the form's grid & controls to be controlsourced to the cursor, or linked somehow via a "data object", or what?
>
>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?
>
>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?)
>
>Thanks,
>Randy W.

Randy,
I'm also interested in seeing replies to this message. IMHO there is no application that totally separates layers from each other (or at least I haven't seen one yet). Consider a web application, UI layer if totally relies on other layers considerable amount of round trips to server would be unavoidable. There would be objections to this I think but in my book if you're checking the data locally in any manner (say firstName is not empty implies NOT NULL, email address is in correct format implies a specific constraint etc) then UI already has some bizRules in itself. My personal POV:
1) Cursors are not part of the data layer (but they're in cases at least for they might be created in data layer and temporary tables could be considered cursors).
2) At the end controlsourced to the cursors. The techniques, language etc might define them differently but at the end 'cursor' might be considered as the recordsource. If you're using VFP (most likely < vbg >) then it might be CA, XMLAdapter, RV, SPT cursors, ADO recordsets. Since you're not directly using base tables you're doing a linkage to 'data objects' (I'm not interested with exact terms here).
3) It can and it should. However in general even those type of data is requested through bizLayer or stored procs at least in the beginning (say an asp.net asks data layer for a lookup and places it in cache). You'd request lookups from a backend and store locally to prevent round trips. If it's highly static like state list then probably keeping permanent local copies would be an option.
4)If interface controls have such a need they can do that (like checking FirstName is not empty is something done often. Updating say sum of values for a grid should be done that way on UI layer -but generally programmers go for the long way and sum all each time-. Commands like tableupdate() do that for you etc). Biz and data layers would do also anyway.
Cetin