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