[AccessD] Building classes for tables

John Colby jwcolby at ColbyConsulting.com
Tue Nov 15 21:03:06 CST 2005


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/




More information about the AccessD mailing list