Shamil Salakhetdinov
shamil at users.mns.ru
Wed Nov 16 12:06:13 CST 2005
<<< 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