By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,987 Members | 997 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,987 IT Pros & Developers. It's quick & easy.

On Current fires 5 times successively

P: n/a
I admit my form is pretty complex and may need a total overhaul -

I have two subforms synchronized on a form through an unbound text box.
When I enter a new record in the second subform it used to complain
about nulls and then about 'can't repeat an index'.

To solve this I wrote code on the main form's subform enter event (I'm
surprised I found it. I must have spent an hour trying to program the
enter and exit events from the subform itself!) to swap the
child/master link fields - pulling it off the unbound text box sync
when it encounters a null.

So now I want to use the On Current even to do formating on the subform
based on a field value in the same form. Funny thing is - when I click
outside of that subform it cycles through 5 On Current events for that
same subform.

I can see it jumping through a few records as it does this, but I'm not
sure what I'm observing.

It's obviously cycling through records when I swap out the child/master
link fields but I'm not sure if it's because of my code, or because I'm
just moving to a different form anyway when it does that.

I have reason to believe it's the latter only because it hits that
OnCurrent X5 when I open the form or switch records anyway.....

Actually, it does it 3 times when I change records. ? Why? Hmmm. Maybe
it's because I have the form linked on 3 master/child fields?...

..... If that is so, then when I do the master/child swap, it cyles
through On Current 5 times because on subform one, I use three
master/child links (each) and on subform two I only use two. 3+2=5.

Is there an easier way to do what I'm doing? I don't want to use dao to
create a new record because if the user doesn't select anything, I
don't want to keep the record.

Maybe I can use a parameter query for that subform instead.
Christian

Oct 18 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Christian, Access can fire the Current event multiple times for a record. In
some cases,it can even get into an endless loop and keep firing it, while
the Status bar continues to read "Calculating".

In your case, I suspect the sequence is like this. The records in the
subform are determined by whatever is in the
LinkMasterFields/LinkChildFields. Access reloads the subform whenever these
values change, and whenever it reloads, the subform's Current event fires.
If LinkMasterFields involves a calculated control, Access recalculates it at
different times. It may well be that clicking on the main form triggers
something that causes Access to recalc the form, and so the side effect is
that the subform reloads and its Current event fires again.

Now, if something else also triggers a recalc, the process is triggered
again. That something could be one of the other calculated controls being
updated, or it is sometimes connected with Access working out how to display
controls with conditional formatting (CF.) Particularly in Access 2000 and
2002, the CF can actually trigger another recalc of the form, which
re-triggers the recalc, which ... And each time the subform is reloading and
so its Current event fires.

Another case would be if a field named in LinkMasterFields is actually
dependent on a field in the subform. In this case, the recalc of the main
form causes the subform to reload which triggers its Current event and
changes the data in the subform. At this point, Access realises the
calculated control on the main form is no longer up to date (the subform
data changed), so it recalcs it, which reloads the subform, which changes
the data so the calculated control is now updated again, which...

There was a nasty bug in Access 97 and earlier (bookmark bug) that meant the
form was not synching correctly with its buffer. Even after Microsoft fixed
it, A97 would still report the wrong data in the form's AfterUpdate and
AfterInsert events. Microsoft fixed this bug in Access 2000, but a
side-effect of the fix was the multiple triggering of Form_Current in some
cases, even without CF or a calculated LinkMasterFields control.

Hope that's at least of some value in identifying what's happening, the
first step towards finding a workaround.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

<ch************@yahoo.comwrote in message
news:11**********************@i3g2000cwc.googlegro ups.com...
>I admit my form is pretty complex and may need a total overhaul -

I have two subforms synchronized on a form through an unbound text box.
When I enter a new record in the second subform it used to complain
about nulls and then about 'can't repeat an index'.

To solve this I wrote code on the main form's subform enter event (I'm
surprised I found it. I must have spent an hour trying to program the
enter and exit events from the subform itself!) to swap the
child/master link fields - pulling it off the unbound text box sync
when it encounters a null.

So now I want to use the On Current even to do formating on the subform
based on a field value in the same form. Funny thing is - when I click
outside of that subform it cycles through 5 On Current events for that
same subform.

I can see it jumping through a few records as it does this, but I'm not
sure what I'm observing.

It's obviously cycling through records when I swap out the child/master
link fields but I'm not sure if it's because of my code, or because I'm
just moving to a different form anyway when it does that.

I have reason to believe it's the latter only because it hits that
OnCurrent X5 when I open the form or switch records anyway.....

Actually, it does it 3 times when I change records. ? Why? Hmmm. Maybe
it's because I have the form linked on 3 master/child fields?...

.... If that is so, then when I do the master/child swap, it cyles
through On Current 5 times because on subform one, I use three
master/child links (each) and on subform two I only use two. 3+2=5.

Is there an easier way to do what I'm doing? I don't want to use dao to
create a new record because if the user doesn't select anything, I
don't want to keep the record.

Maybe I can use a parameter query for that subform instead.

Oct 18 '06 #2

P: n/a
Thanks Allen,

I decided to use a parameter query. This works up to a point until I
decide to add a record, then it refuses to go back in sync. To fix, I
toggle the subforms 'Allow Additions'. This allows the other form to
sync back up after requery.

I use defaults for the FKs because it won't update them on it's own
when I add a new record.

I have three buttons which each add a new record with different
defaults - so it has a fit when I try to add a new record before I
complete the first. So I on error resume next.

So now I don't need to place that extra control on the main form and I
don't need to set a child/master link. The on current even fires twice
on main form load and once each record change.

The one problem with this is that the subform will only update after it
recieves a requery on enter. I tried to fix this by requerying the
subform from the other subforms on current event (and additionally the
save record button). This does not work for some odd reason. I've also
tried to requery from the after update event of the triggering subform
but that doesn't fire as I'd suspect.

I liked the fact that when I did have the child/master link code setup
- the other form would automatically update as soon as I changed
anything - except for the add new record...
Of course, I do have one subform in non editable mode..............

Christian

Oct 18 '06 #3

P: n/a
"Allen Browne" <Al*********@SeeSig.Invalidwrote in
news:45***********************@per-qv1-newsreader-01.iinet.net.au:
There was a nasty bug in Access 97 and earlier (bookmark bug) that
meant the form was not synching correctly with its buffer. Even
after Microsoft fixed it, A97 would still report the wrong data in
the form's AfterUpdate and AfterInsert events.
Um, with a requery after deletes, the bookmark bug would never
strike, no?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Oct 18 '06 #4

P: n/a
Right, David. Forcing a requery after each deletion was a workaround.

Of course, the Requery results in the Current event firing again. It's
interesting that's the side effect of whatever MS did in A2000 too.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...
"Allen Browne" <Al*********@SeeSig.Invalidwrote in
news:45***********************@per-qv1-newsreader-01.iinet.net.au:
>There was a nasty bug in Access 97 and earlier (bookmark bug) that
meant the form was not synching correctly with its buffer. Even
after Microsoft fixed it, A97 would still report the wrong data in
the form's AfterUpdate and AfterInsert events.

Um, with a requery after deletes, the bookmark bug would never
strike, no?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Oct 19 '06 #5

P: n/a
"Allen Browne" <Al*********@SeeSig.Invalidwrote in
news:45***********************@per-qv1-newsreader-01.iinet.net.au:
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...
>"Allen Browne" <Al*********@SeeSig.Invalidwrote in
news:45***********************@per-qv1-newsreader-01.iinet.net.au:
>>There was a nasty bug in Access 97 and earlier (bookmark bug)
that meant the form was not synching correctly with its buffer.
Even after Microsoft fixed it, A97 would still report the wrong
data in the form's AfterUpdate and AfterInsert events.

Um, with a requery after deletes, the bookmark bug would never
strike, no?

Right, David. Forcing a requery after each deletion was a
workaround.
Huh, I wouldn't call it a workaround. I agree with MichKa's judgment
back when the bookmark bug struck that you shouldn't be navigating a
RecordsetClone unless you know it has current data in it. The
requery recreates the RecordsetClone and brings the edit buffer and
the form back in synch with each other. It makes sense to me that
you'd be required to do the requery after a delete as a matter of
proper programming practice.
Of course, the Requery results in the Current event firing again.
It's interesting that's the side effect of whatever MS did in
A2000 too.
It's too bad the hit is there even when you aren't using bookmark
navigation, which was required to get the edit and display buffers
out of synch with each other.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Oct 19 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.