"Jon Lewis" <jon.lewis (AT) cutthespambtinternet (DOT) com> wrote

It does. A control's Afterupdate code can be made to fire if you call the
sub in question - I've done it previously and make use of it in another
database.

"buckskin" <buckskin (AT) mailinator (DOT) com> wrote

No, you didn't say it -- you described it. A control on the Form that is
bound to a Field in the Table is entered by one user, but automatically
recalculated for another (and when that is done, will be automatically
stored in the Table, overriding what the first user entered). If it were
not, then it would not appear in the Report -- Reports do not 'get their
data from Forms' but from a Record Source which is a Table, Query, or
Recordset.

People here are advising you, as best they can from what you've described,
but you have a 'way to do it' in mind and reject suggestions that will
work... perhaps that's because you haven't explained what the AfterUpdate
code does and why you need to do that in that particular manner. The
AfterUpdate event does not fire, nor can you make it fire, when you set the
value of the Control from code, but YES, of course, you can call the
procedure and execute the same code. This has nothing to do with "not
offending Access Gods" but just trying to understand what it really is that
you want to do, and offering suggestions to accomplish it.

I've answered tens of thousands of questions in Access newsgroups and have
no interest in "trolling" anyone. And, I just told you something that "all
your explanations" did not include, that appears to be important to what you
want to accomplish -- that is, whatever is done in the AfterUpdate event
code.

It's not my intent to try to engage you in a philosophical discussion on how
things should or should not be done, but you should understand that there
are good reasons for valid relational database design principles.

I hope that your explanations are adequate for someone to help you... my
guess is that Jon has given you the basis (perhaps with additional code in
lieu of the AfterUpdate event code), or perhaps my suggestion of basing
"SuperUsers" Report on a Query, but without your telling us WHAT you expect
to do by executing the AfterUpdate code, it's not really possible for any of
us to say.

I apologize for the irritation that I've caused, which was not my intent.
But, as my feeble attempts to assist do appear to irritate you, I suppose I
should leave further responses to someone else who doesn't 'rub you the
wrong way'.

Larry Linson, Microsoft Office Access MVP

"Access Developer" <accdevel (AT) gmail (DOT) com> wrote

I have no idea what you're talking about now. I think you're determinedly
holding onto the wrong end of a stick and refusing to let go. My data
structures are not in question here. They really are not. The report
source is based on a table not a form and always has been.

I am not rejecting suggestions that might work. But I don't need to keep
repeating myself and changing the terms of the original request just because
you demand it Larry. I have merely asked how to do something. That does
not make me capricious or close-minded.


Well up to now you're contributed nothing Larry.


This is not about database design. Clearly you are a master of that and I
bow to your Access skills among the many other experts who have helped me
out here over the years but please don't keep turning this discussion into
something it was not.

I have acknowledged Jon's contribution. What if my afterupdate code merely
pops up a msgbox saying "Hello?". Any ramifications there are down to me
and i could always post separately. My question, if it's possible to get
back to that, is merely how to automate a form, moving down one row at a
time and entering a value. The reason for doing that is, yes, i want the
afterupdate event to fire and that was my initial focus.

If I had got a reply saying how to do that it would progress me along my
learning curve and I could see what affect it had. I really did not want
anyone to go so far beyond that focus if only because I don't wish to unduly
occupy the time of others.

If you stayed within the bounds of the question instead of expanding the
scope to things that simply don't matter I would not have been irritated.
I explained the information I was after quite clearly and did not think it
would encourage someone of your enormous intellect to frown and pour scorn
on my simple request.

That's not the same as an event firing though now is it?





"buckskin" <buckskin (AT) mailinator (DOT) com> wrote

"buckskin" <buckskin (AT) mailinator (DOT) com> wrote

I certainly have not called you either of those names and I wish you the
best of luck to you in finding someone who can provide an answer that is
acceptable to you.

Larry Linson, Microsoft Office Access MVP

buckskin wrote:
There does not seem to be any need for a form for this task. Forms are user
interfaces, not code interfaces. Sure, we could tell you about Sendkeys and
other such wrong-headed, error-prone kludges, but we would not be doing you
any favors.

A simple Update query would seem to be the approach to take. I would create
a saved update query that updates the field in question and run the query
via the command button using currentdb.execute.


I've just seen this:
Budget for each line.
In the above example that would be $250. That figure is entered into the
projection textbox as though the user were there tapping away.
So why not:

currentdb.execute "update tablename " & _
"set projection = budget - actual"

Or put that sql into a saved query and use a macro to run it instead of VBA
if you're not comfortable with VBA.

No form needed.

If there is more to this calculation than a simple subtraction, tell us
about it so we can properly advise you.

I see from reading the thread that discussion of proper application design
irritates you, but I can't continue without advising against storing the
result of a calculation. If you wish for a further explanation for the
reasons this is not advised, ask and I will explain. Otherwise, simply
ignore this paragraph.