Strange subform behaviour

  • Thread starter KenSheridan via AccessMonster.com
  • Start date
K

KenSheridan via AccessMonster.com

I've recently created a parent form with two correlated continuous subforms
linked via a hidden unbound text box control in the parent form. The first
of the subforms, whose control's LinkChildFields and LinkMasterFields
properties are references to columns in the underlying recordsets, works as
expected. In the second, however, which is correlated with the first by the
LinkMasterFields property referencing the hidden text box in the parent form,
as soon as any data is entered into a control the subform's record is saved.
This happens immediately on entering the first character, not when the
control is updated by tabbing to the next control in the subform.

Another consequence of this is that, if the record which is saved is earlier
in the underlying recordset's sort order than any previously inserted record
(s), the new row immediately moves to its correct position in the sort order.
This is very confusing of course, so I've had to remove the ORDER BY clause
from the underlying query to prevent this. Also I've had to make sure that
another column in which Null is not allowed has a default value. None of
this affects the basic functionality, but it would be better if I could order
the subform's rows and do without the default value for the other column.

As this behaviour is only experienced in the second subform I can only assume
that it derives from the fact that the second subform is referencing the
hidden text box as the LinkMasterFields property. I initially thought that
the subform was being requeried, which would explain why the row jumps to its
correct position in the sort order, but if that were the case it would be
expected that the record pointer would return to the first row in the subform
(as happens for instance when a requery is forced if a item is added to a
combo box's list by means of its NotInList event procedure in a row in a
subform), but this is not the case; the record pointer stays on the new
record.

The subform has no code whatsoever in its module, so its not that which is
causing the behaviour. The whole thing is a mystery to me.

Ken Sheridan
Stafford, England
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top