Jim Dettman
jimdettman at verizon.net
Sun Jan 18 09:11:43 CST 2015
<<I know John ... what's his last name, he hasn't posted in soooo long ... :) would tell me to use class modules.>> Actually the questions is, should you be using Access at all? The whole point of Access is that it does many things for you. The minute you start walking away from that, then you might as well use something else and not have all the baggage that Access carries. BTW the more "heavy lifting" you do, the more Access will get in your way. Jim. PS. Yeah John hasn't been around much since going to work for IBM. He may even have retired at this point...anyone hear from him as of late? -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bill Benson Sent: Saturday, January 17, 2015 11:48 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] doCmd.SaveRecord not firing Form_Before_Update event 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 > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com