>>
>>>If I'm working with ADO I find it very confusing being in a 3-tier app, if I had the UI working with ADO recordsets, that are based on tables in the data-tier, isn't that creating a direct-link between the UI and the Data? Or have I got this method of working wrong?
>>
>>I don't know how sophisticated this is, but in my mind ADO recordsets are a data layer, sorta. As are stored procedures. If a UI talks to an ADO recordset then that's a client/server, or 2 tier model, right? You're bypassing the business layer. But you haven't coupled data with the UI. (The ADO is inbetween.)
>
>I don't see ADO as two-tier because the ADO can easily be passed through multiple components, unlike a View or SQL Pass Through. I see ADO as a way to pass the data.

I suppose it will depend how the presentation layer is actually reading/writing the data, if it is directly to an ADO then surely this will be going directly back to the data-layer.

I think this is where I'm getting confused. The way I'm picturing it is the presentation layer receives an ADO from the business-layer, changes are made to some of the fields, then the Update/Cancel methods in the ADO are executed from the business object (upon validation), is that how it would work?

Thanks
Kev