ADO Recordset interface?

[Craig Buchanan]

I'd like to make a class that would appear to be an recorset for the purpose
of binding it to a Access form, yet still be able to create custom
properties and methods. Is there an interface exposed by ADO that would
allow me to do this?

Thanks,

Craig Buchanan

 

[rkc]

I'd like to make a class that would appear to be an recorset for the purpose
of binding it to a Access form, yet still be able to create custom
properties and methods. Is there an interface exposed by ADO that would
allow me to do this?

Custom properties and methods for the purpose of doing what?

You can create a class that has a recordset as a member and then
create methods in the class that act on that recordset.

 

[Craig Buchanan]

thanks for the response. I would like to insulate the client layer from
direct interaction with ADO objects. I would like my application's API to
only expose 'business' classes.

 

[rkc]

thanks for the response. I would like to insulate the client layer from
direct interaction with ADO objects. I would like my application's API to
only expose 'business' classes.

Well a bound form is going to have direct interaction with a
recordsource of some type. There's no getting around that.
That doesn't mean you have to write all your code in the
form class modules. You can create a class that handles the
creation of an ado.recordset based on the needs of your business
classes. The recordset object can be exposed as a property of that
class which can then be used to set the recordset of a form.

 

[Craig Buchanan]

my thought was that if i build a class that implements the recordset object,
then i could bind the form to the class directly, yet still mantain my
encapsulation. the code won't allow an object to implement an
ADODB.Recordset, but maybe a lower-level interface is available.