Hi Everyone,

I am wanting to know if it is possible to build a custom object /
class 'on the fly'. I am hoping to create a class that has elements
for each field in a recordset - wihtout knowing the fields before
retreiving the recordset. I would then use a collection of these
objects to 'pool' the data. The reason behind this is that I am
pulling data from multiple sources, and not all of them are known
beforehand.

At the moment I am using arrays to do the job of holding the data (in
a collection), and a separate collection of arrays that holds the
recordsets' definitions (name, type, definedsize). I would prefer to
do this with 'objects' but I am guessing I can only do this if I know
the definitions beforehand.

Any thoughts are appreciated.

Cheers

The Frog

On Fri, 19 Mar 2010 03:29:22 -0700 (PDT), The Frog
<mr.frog.to.you@googlemail.com> wrote:

This has already been built for you: a DAO.Recordset object has a
Fields collection. Would that do it?

-Tom.
Microsoft Access MVP


>Hi Everyone,
>
>I am wanting to know if it is possible to build a custom object /
>class 'on the fly'. I am hoping to create a class that has elements
>for each field in a recordset - wihtout knowing the fields before
>retreiving the recordset. I would then use a collection of these
>objects to 'pool' the data. The reason behind this is that I am
>pulling data from multiple sources, and not all of them are known
>beforehand.
>
>At the moment I am using arrays to do the job of holding the data (in
>a collection), and a separate collection of arrays that holds the
>recordsets' definitions (name, type, definedsize). I would prefer to
>do this with 'objects' but I am guessing I can only do this if I know
>the definitions beforehand.
>
>Any thoughts are appreciated.
>
>Cheers
>
>The Frog

Hi Tom,

Not really. I was thinking more of working with stacks and ques. I am
not aware of any way to achive this except with classes (for complex
objects). I am thinking that it might be easier to build a simple
object heirarchy, effectively simulating the recordset object - but
without all the database specific functions. Just a data holder in
effect. Its for a set of rather complex analyses where the recordset
itself isnt suitable. I need to be able to manipulate each object
individually and feed them into different parts of the analysis
independantly.

Cheers

The Frog

On Mon, 22 Mar 2010 01:24:52 -0700 (PDT), The Frog
<mr.frog.to.you@googlemail.com> wrote:

OK, I re-read your OP and did get a different impression. Sure you can
build your own objects, and put them in collections. If you think
about the Properties collection for example it is built on-the-fly and
you can add new elements to it at any time.

-Tom.
Microsoft Access MVP


>Hi Tom,
>
>Not really. I was thinking more of working with stacks and ques. I am
>not aware of any way to achive this except with classes (for complex
>objects). I am thinking that it might be easier to build a simple
>object heirarchy, effectively simulating the recordset object - but
>without all the database specific functions. Just a data holder in
>effect. Its for a set of rather complex analyses where the recordset
>itself isnt suitable. I need to be able to manipulate each object
>individually and feed them into different parts of the analysis
>independantly.
>
>Cheers
>
>The Frog

Hi Tom,

Thats a great example. I didnt think of that. Its perfect. Create a
basic 'atom' of information as an object, and create a 'molecule'
object that has a collection of 'atoms'. That will do nicely :-)

Thanks for kicking this around with me Tom, I appreciate it.

Cheers

The Frog