Bill Benson
bensonforums at gmail.com
Sat Jan 17 22:47:55 CST 2015
Thank you for this offer Charlotte, however I believe the point you made about myself doing the heavy lifting is just the price I have to (and have learned how to) pay. Access's default Save button would just, as you say, process the unbound controls "unprocessed" - without my using their individual Afterupdate commands to set bound form fields. So now I use those to set values on the form's bound controls (probably could have just set the fields but I wanted to watch the changes taking place) - and then Save would do what it is supposed to. I know John ... what's his last name, he hasn't posted in soooo long ... :) would tell me to use class modules. Once I understand the nature of the beast it is not so hard. Thank you. On Sat, Jan 17, 2015 at 11:13 PM, Charlotte Foust <charlotte.foust at gmail.com > wrote: > You're trying to mix too many things together to keep them straight. The > dirty property only applies to a bound form and before update only occurs > with a bound recordsource and bound controls. If you use unbound forms, > you have to do the heavy lifting yourself in code. Calling a form save > will save the record and the values of the unbound controls in the form > itself. If you ever want to see an example of doing it all unbound, I've > got one in Roger's Access Library. It's called No Tables and opens > recordsets on an unlinked database using ADO. I built it originally in > 2000, so depending on the version of Access you're using you might have to > open and save as to make it run, > > Charlotte > > On Sat, Jan 17, 2015 at 7:41 PM, Bill Benson <bensonforums at gmail.com> > wrote: > > > Using my own noodle, here is what I determined: The Beforeupdate event > is > > apparently bypassed if the form is not "dirty". If the Help says that, I > am > > not able to see anything about it. Since the controls driving this > exercise > > were unbound, changing them and expecting that a Form Save would call the > > BeforeUpdate event was apparently unreasonable (!) on my part... so my > > update routines were not firing. I have since added some bound controls > on > > the form, and updated those when the unbound controls change - and this > is > > enough to make the form feel dirty, and then saving is calling the > > BeforeUpdate event (which I no longer even need, ha ha - since the bound > > controls are taking on the value of the unbound controls)... however this > > still makes me want to peeuuke. > > > > On Sat, Jan 17, 2015 at 10:14 PM, Bill Benson <bensonforums at gmail.com> > > wrote: > > > > > I am getting nearly work out with Access not behaving as I would > expect - > > > and in this case, as Help tells me it should. I have a process which > > needs > > > to save an order record then create an invoice. The invoice will have > > > amounts for various types of fees calculated as either based on an > amount > > > entered per bottle, or a flat amount; but if a field FeeTypeid is set > to > > a > > > value such that looking up that feetypeid in the FeeType table yields a > > > feeType of 'N/A', I do not want the amount to be calculated (ie, should > > be > > > zero). > > > > > > This determination is to be made in the Beforeupdate event. > > > > > > However, upon saving the record, that event is not firing. I have > > verified > > > in the form property sheet that this event is set to fire. > > > > > > Any help out there? Arrrggghghhgg! > > > > > -- > > 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 >