[AccessD] doCmd.SaveRecord not firing Form_Before_Update event

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
>


More information about the AccessD mailing list