[AccessD] Building classes for tables

Charlotte Foust cfoust at infostatsystems.com
Wed Nov 16 12:15:43 CST 2005


I should have known you would have done it, Shamil! ;-}  But since you
can't contribute the code to John, it amounts to the same thing as
nobody having done it here.

Charlotte


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil
Salakhetdinov
Sent: Wednesday, November 16, 2005 10:06 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Building classes for tables


<<<
 I don't think anyone has done it here
>>>
I did that Charlotte in autumn 1999 while in Belgium.
I have the code.
But this code was paid by the customer.
Therefore I think I don't have copyright on this code and I can't post
it here?

Just wanted to note that there are no probably MS Access related subject
areas somebody from this group didn't work in. :)

Shamil

----- Original Message ----- 
From: "Charlotte Foust" <cfoust at infostatsystems.com>
To: "Access Developers discussion and problem solving"
<accessd at databaseadvisors.com>
Sent: Wednesday, November 16, 2005 8:47 PM
Subject: Re: [AccessD] Building classes for tables


> Right, and I'm saying use the dot net typed dataset as a model for the

> class template, give the class a recordset property, and build a 
> wizard or simply the code to create a custom instance of the class for

> each table you pass in.  I don't think anyone has done it here or you 
> would have had someone fess up before this.
>
> Charlotte Foust
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Colby
> Sent: Wednesday, November 16, 2005 9:38 AM
> To: 'Access Developers discussion and problem solving'
> Subject: Re: [AccessD] Building classes for tables
>
>
> I started the thread asking whether anyone had build such a widget for

> ACCESS.
>
> John W. Colby
> www.ColbyConsulting.com
>
> Contribute your unused CPU cycles to a good cause: 
> http://folding.stanford.edu/
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte 
> Foust
> Sent: Wednesday, November 16, 2005 12:31 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Building classes for tables
>
>
> Huh?  Are you talking dot net or Access?  In dot net, typed datasets 
> model the data source, but they aren't "connected", they're a sort of 
> interface to the table or tables that inherits the dataset object.  
> You can build one by hand for tables that don't exist and you can add 
> expressions that pull data from related tables and stick it into the 
> primary table in the dataset.
>
> In Access, there's no reason you couldn't give the table class a 
> recordset property.
>
> Charlotte Foust
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Colby
> Sent: Tuesday, November 15, 2005 7:03 PM
> To: 'Access Developers discussion and problem solving'
> Subject: Re: [AccessD] Building classes for tables
>
>
> I was discussing doing it in VBA (Access).  Besides Typed datasets are

> connected correct?  If you want a disconnected object to hold the 
> record data you need a class that gets instantiated and filled, then 
> saved in a collection of a supervisor object.
>
> John W. Colby
> www.ColbyConsulting.com
>
> Contribute your unused CPU cycles to a good cause: 
> http://folding.stanford.edu/
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte 
> Foust
> Sent: Tuesday, November 15, 2005 6:38 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Building classes for tables
>
>
> You don't need an add-in for it in dot net, Drew.  That's what Typed 
> Datasets are, automagically built classes that contain all that stuff 
> for the table or tables involved in dataset that is the basis for the 
> Typed Dataset.  You can even include relationships and calculated 
> expressions as "fields".
>
> Charlotte Foust
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of 
> DWUTKA at marlow.com
> Sent: Tuesday, November 15, 2005 3:25 PM
> To: accessd at databaseadvisors.com
> Subject: Re: [AccessD] Building classes for tables
>
>
> Not really, you can get the data type of the field, the field name, 
> and even the description of the field. It would be a simple select 
> case to build a property Let and Get statement for each field.  To go 
> a bit further, you should also be able to determine if a field is an 
> ID field, or get the indexes of the field to build an ID.  I would 
> make it straightforward, that if there is an autonumber field, you 
> include a 'get and write' capability. Normally, when I build this type

> of class structure, I include a StorageOnly boolean value, that sets 
> to false when the class loads.  Then, when you set the value of the ID

> field, if StorageOnly is True, it does nothing but stores the value, 
> if it's false, then it goes and 'fills itself' with that particular 
> record. Then add a 'Save' Function.  When the class initializes, you 
> set an internal value that states the record is 'new'.  When you set 
> the ID field, it also sets that value to 'old'.  When  you run the 
> save function, it either creates a new record with said values or 
> updates the existing records of that table.
>
> That way, the second 'collection' class can set the StorageOnly 
> property to true, to pull all of the records up at once, or you can 
> create a single instance of your 'record' class and by setting it's ID

> property, it automatically retrieves it's data for you.
>
> An Add-in could use the properties of the field to create the property

> names within the class, along with comments, etc.
>
> I could build one for you, but I would do it in VBA, so it would be a 
> VB6 add-in.  I think you use .Net, which uses slightly different code 
> for properties (if I remember right, you go Property Something() then 
> have a Get and Let statement within the property....only played around

> with .Net a little bit).
>
> You could even have the Let() statements set a 'dirty' property, and 
> have a 'reset' function to restore the original values and clear the 
> dirty property.
>
> Let me know if you want me to build something like this in VB6, I 
> could send you the VB6 Add-in code then...shouldn't require too much 
> change to work in .Net.
>
> Drew
>
> -----Original Message-----
> From: John Colby [SMTP:jwcolby at colbyconsulting.com]
> Sent: Tuesday, November 15, 2005 1:05 PM
> To: 'Access Developers discussion and problem solving'
> Subject: Re: [AccessD] Building classes for tables
>
> Sure, of course except that the "information of the record" is pretty
> structured and a PITA to have to do every time.  The "records in
> the table"
> is more specific to the application, and so less can be done
> with a wizard.
>
> John W. Colby
> www.ColbyConsulting.com
>
> Contribute your unused CPU cycles to a good cause: 
> http://folding.stanford.edu/
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



More information about the AccessD mailing list