Rocky Smolin - Beach Access Software
bchacc at san.rr.com
Wed Mar 1 08:54:56 CST 2006
You forgot the fld prefix! I now also put the name of the table into each field name. so each field in tblCustomer, for example, begins with fldCustomer. More self documenting. You can always see what table a field comes from. Rocky Dan Waters wrote: > 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 >> > > -- Rocky Smolin Beach Access Software 858-259-4334 www.e-z-mrp.com