From: The Frog on 19 Mar 2010 06:29 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
From: Tom van Stiphout on 19 Mar 2010 09:35 On Fri, 19 Mar 2010 03:29:22 -0700 (PDT), The Frog <mr.frog.to.you(a)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
From: The Frog on 22 Mar 2010 04:24 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
From: Tom van Stiphout on 22 Mar 2010 09:55 On Mon, 22 Mar 2010 01:24:52 -0700 (PDT), The Frog <mr.frog.to.you(a)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
From: The Frog on 23 Mar 2010 06:01 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
|
Pages: 1 Prev: using cdo for email Next: Sorting & Grouping limited on A2007 report based on pass-through |