Weird relation problem

[Tpaairman]

I have two tables - one for bills due, the other for pay cycles. Very simply on the bill side there is a due date. On the cycle side there is a start and end date, and the portal shows all bills with a due date anywhere from the start to end dates.

I had it set to a different date in cycles and it worked fine, but I changed it to this for several reasons, and after the change is when I'm having a problem.

The relation is set up as follows:

Bills: Due Date ≥ Start Date

(And)

Bills:Due Date ≤ End Date.

When I create a new record in the portal, and I type in the date, at first it was wiping out the bill date and changing it to whatever the DAY was in the start date - i.e. the start date is 11/14/07, the end date is 11/20/07. When I type in the date in the portal, no matter what date it type, as soon as I tab to the next field the date would change to "14" - no other numbers, no month or year.

The relation all looked fine, but I noticed that bills that had already been entered were not showing up, but their dates were not affected in their own records. So I cleared out the relation, and reentered it, and now when I type in the date it changes the date to whatever the end date is. Although now it is a complete date with month, day and year, and any bill created in the bill table (not in the portal) do show up properly.

[comment]

This type of relationship is suitable for viewing related records, but not for creating them. Whenever you create a new related record by typing into the last portal row, Filemaker automatically places the parent value/s into the child's matchfield/s.

[jumpysven]

Thanks. but how do I fix that? I have the same problem.

[comment]

It's not something to be fixed. You simply cannot create new records by entering them into this kind of portal (the relationship should never have been allowed to create new records). Just pick another way to create new records - there must be a dozen of them.

If it must be from the same layout, you could enter the data into some global fields, and have a script go over to the child table, create a new record, set the fields to the globals, and come back. Or use another relationship to create a new record. Or...

The point here is that you create records in a portal when you don't want to enter data into the child record's matchfield/s manually. Filemaker does it for you, automatically. When the parent matchfields are a range, this method just doesn't make sense.