Jim,
Thank You. Your response got me off dead center, but I'm still grumbling.
I
added a postrecord() to one of the fields in the header file, which at
first
got the same error message. Then I tried a few other combinations (going
into and out of edit mode, adding a button to post the header record that
didn't work, etc.), and suddenly, I had a form that worked.
Unfortunately,
in my irritation, I lost track of the exact changes, and I don't know why
the
form works. I cannot reproduce the success if I start with a new copy of
the
form that produces the error message. The only change in the form that I
can
see is a postrecord command on change in value of one of the header
fields.
I've been programming on a variety of systems for longer than I care to
admit,
and this is as strange a problem as I've come across in a long time,
especially when I remember that the system has been in use for several
years,
and there never has been a postrecord in the form until now. At this
point,
I don't trust that the working copy of the form will continue to work.
With all that said, each form when it is opened starts out displaying a
different record. I do not see where in the form definition that record
Id
is stored or how to change it. Could you explain where I can see or
change
that information?
Jim Moseley wrote:
>bheavilin,
>
>Your problem is that the record at the top half of the screen hasn't been
>posted when you jump to the record at the bottom half. The 'range' is
built
>into your form's data model - the bottom record is dependant on the top
record.
>
>You've got 2 options:
>1. When you create the top record, also create a bottom record by default
>with matching master keys.
>2. When you arrive on the bottom record, first issue a postRecord() on
the
>top record. This should pre-format the bottom record's keys.
>
>HTH,
>Jim Moseley
--
Message posted via http://www.dbmonster.com
|
