[AccessD] Building classes for tables

Steve Conklin developer at ultradnt.com
Wed Nov 16 12:07:24 CST 2005


>>custom instance of the class

I guess my actual question to John is - 
Is this intended for runtime or a design time "helper"? 

Steve


-----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:48 PM
To: Access Developers discussion and problem solving
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




More information about the AccessD mailing list