Why do it this way when you can bind directly to the RS? This seems like lots of unneeded work.


>Russell,
>
> We've been playing about with this (just experimenting, looking at feasibility of moving to n-tier with ADO). We have a lot of forms with controls bound to fields in a table (clients.cust_id etc.), The idea was to make as few changes as possible to these screens, so we played about trying to bind these controls to fields in an ADO recordset. You can fake this by wrapping an ADO recordset in an object.
>
> In our example, OraRecordset is a class which creates an ADO recordset, and holds a reference to it (oRecordset). The OraRecordset is then subclassed and properties are defined for every field in Recordset (here we have cust_id and cust_name as fields we want to bind to. Then, if you define access and assign properties for each of these "field" properties, you can bind controls in a form to "clients.cust_id", and "clients.cust_name" (properties of the clients object), as if it was a table.
>
> Here's the code for the clients class :
>
>DEFINE CLASS Clients AS OraRecordset
>
> cust_id = ""
> cust_name = ""
> Name = "clients"
>
>
> PROCEDURE cust_id_access
> RETURN THIS.orecordset.fields('cust_id').value
> ENDPROC
>
>
> PROCEDURE cust_id_assign
> LPARAMETERS vNewVal
> THIS.orecordset.fields('cust_id').value = m.vNewVal
> ENDPROC
>
>
> PROCEDURE cust_name_access
> RETURN THIS.orecordset.fields('cust_name').value
> ENDPROC
>
>
> PROCEDURE cust_name_assign
> LPARAMETERS vNewVal
> THIS.orecordset.fields('cust_name').value = m.vNewVal
> ENDPROC
>
>
>ENDDEFINE
>
> Not sure if this is the way we'll go, but it may be a promising start.
>
>Best wishes,
>Neil