Dan Waters
dwaters at usinternet.com
Wed Mar 1 07:28:31 CST 2006
AND, the name of the autonumber field MUST be the same as the table name. For example, tblMyTable has a PK Autonumber of MyTableID. It MUST be this way! ;-) Dan -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Colby Sent: Tuesday, February 28, 2006 10:59 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Assistance ROTFLMAO. Some things are just worth doing, always. Because of my dictatorial methods I am able to just look at my tables and see the relationships, know what tables a field is in etc. Works for me. Most of my subjects don't dare speak up anymore, knowing my "out the door, without a parachute" mentality. ;-) John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin - Beach Access Software Sent: Tuesday, February 28, 2006 11:15 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Assistance Well, thanks to you and your dictatorial methodology I find I am now completely unable to create a new table without defining an autonumber PK as the very first field. With ID as the suffix of the field name. Thanks a lot. And I mean that. Rocky John Colby wrote: > LOL, 99% of my forms are bound. 99% of my forms do some pretty "fancy" > stuff via my framework as well. > > For example, I have a "REC_ID" text box on every form which is bound > to the PK of the table the form collects data for. The REC_ID on the > opening form is bound to the PK so it has information on the field > name for the PK which I can use in building "move to" code. If a combo > on another (child) form is displaying a record, the combo has the PK > VALUE of a specific record in the parent table. If a user dbl clicks > a combo box, my framework can cause a data entry form to open > displaying data from the parent table that the combo is displaying. > Since I know the PK from the combo that was double clicked, and I know the table and field of that PK from the REC_ID control, I can > instruct the form to "find" that PK. I therefore have all the pieces > needed to open the form and move to the record that the combo was > displaying. If the combo back on the calling form was on the new > record, it will NOT be displaying data. That is a signal to the > opening form to move to a new record so that the user can enter data. > I use the same basic logic for the "not-in-list" event of the combo to > allow the user to automatically open the data entry form for a combo, > move to the new record, and enter new data in the table. When the > form closes, the combo requeries and now contains the newly entered data in the list table. > > That kind of stuff. > > My framework provides dozens of "behaviors" that are just there if I > want to use them. In the OnOpen of a form, when I set up the form > class, I can specify that "this combo is dependent on that combo". > When the class for this combo is requeried, it automatically requeries > all "dependent" object classes. I can have subforms, combos, list > boxes etc. all "dependent on" a given object. As long as each of these dependent objects has a "requery" > method, I can just iterate the colDependentObject collection of the > class, requerying all dependent objects. The current event of a > subform can cause the form class to requery all "dependent objects" > dependent on that current record of the subform. Of course all > dependent objects have to have feedback in the query that allows it to > display different data depending on the current row of a form, or the > selected item in a combo etc. But if you set it all up, and "inform" > the framework (objects) that other objects are dependent on them, then > they all get requeried when the master object is requeried. A combo > can have a dependent combo, which can itself have a dependent combo. Change the first combo, it requeries the second combo. > The second combo then requeries the third combo etc. The third combo > could requery 5 subforms. Your imagination is the limit. > > This kind of stuff can make the creation of dependent combos and > subforms a snap. > > Just one of dozens of behaviors built in to the framework. > > Yea, I use bound forms, I use autonumber PKs, I use a framework, and I > make good use of all of the above. > > John W. Colby > www.ColbyConsulting.com > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky > Smolin - Beach Access Software > Sent: Tuesday, February 28, 2006 9:15 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Assistance > > Bound or unbound forms? > > Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com