[AccessD] Assistance

Jim Hewson JHewson at karta.com
Wed Mar 1 07:58:06 CST 2006


Here. Here.  
I concur!

Jim 
jhewson at karta.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 10: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
>
>
> John Colby wrote:
>   
>> Folks,
>>
>> I am looking for a "junior level" person to assist me in getting some 
>> of my back log caught up.  I need one person, able to:
>>
>> Read and program VBA, guru not required.
>> Understands and can build Access tables, queries, forms and reports.
>> Must understand data normalization and be able to correctly sort out 
>> what data goes where given a set of objects / attributes.
>> Must be able to read, understand and build relationship diagrams in 
>> the relationship window in Access (the center of my universe).
>> Has a few hours a day available (10-20 hours a week).
>> Must be self starter, blah, blah, blah.
>>
>> If anyone out there thinks they might fit the bill, please respond 
>> OFFLINE - email a resume, and introduction email with required hourly 
>> wage to jwcolby at colbyconsulting.com.  The more you know and are 
>> capable of the more work I have.
>>
>> Thanks,
>>
>> John W. Colby
>> www.ColbyConsulting.com
>>
>>
>>   
>>     
>
> --
> Rocky Smolin
> Beach Access Software
> 858-259-4334
> www.e-z-mrp.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
>   

-- 
Rocky Smolin
Beach Access Software
858-259-4334
www.e-z-mrp.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