I'm running into a problem in a certain portal in my solution: When I try to create a new record by entering data, the record will not commit merely by leaving a field.

Say, I have portal fields f1, f2 and f3:

I click on f1, and enter "foo".

I click on f2, and "foo" vanishes!

I continue typing "bar" into f2.

I click on f3, or click out, or do anything to commit, and suddenly I have 3 portal rows! One with "foo" in f1, one with "bar" in f2, and the usual blank one at the end.

I have compared this portal to other portals on the same layout that are also designed for record creation, and I cannot find any differences, yet the others all work as they are supposed to (committing the record upon leaving f1). The only thing that works is if I enter "foo' into f1, then immediately commit.

I even set the serialized keyfield in the portal table to autoentry on create instead of commit, but that didn't change anything. Anything I might have missed?

Thanks!

Can you attach a sample of the problem file and indicate which layout the portal is on?

Sorry...I'd like to, but the bossman says no. I tried to replicate it on a test database, but I can't seem to repeat the anomaly, though it remains consistent on other layouts in the original database, as well. It's just that relationship. The Relationship stats: Keyfield = SecondaryKeyfield, Creation and Deletion selected, no sort.

Are all fields in the portal based on the same relationship as the portal?

Yes. In all other regards they work fine, and once I finally do have a record created it works fine, it's just the initial creation of a record upon entering the portal.

How do you select the secondarykeyfield in the child table? Is it a lookup field or calculation field? It seems that the problem is because of the relationship.

The secondarykeyfield is plain text, indexed all, not a lookup or anything, it just gets created whenever a new record is created in a portal. I use the same exact setup in another relationship, and that works fine.

In case I'm getting my nomenclature wrong, I'm talking about the field in the child table related to the Primary key in the parent table.