I would make sure that your date fields are all really fields of type date and not text. Then double check the design of your layout and portal. Both the portal filter you describe should work.
But please note that when using a filtered portal, editing the value of one of the fields referenced in the portal filter does not automatically update what records will appear in your portal. If you think that may be why this doesn't appear to work for you, perform a script with this script step after editing such a field:
Refresh Window [Flush Cached Join Results]
That isn't a step I usually recommend because it can really bog down screen updates in some circumstances, but it's an easy way to test for this issue. If that turns out to be the only issue, we can set up a relationship that won't need this added script step to get the same results.
The nextSendDate in table 1 is a calculation returning a date: [If (frequency = 0; emailSendDate + daysFromLaunch; emailSendDate + frequency)]... frequency and daysFromLaunch are number fields.
In table 2, the responseDate is a calculation returning a date: [Date ( Month(Date) ; Day(Date) ; Year(Date) )] where the field "Date" is a timestamp formatted as " 11/1/2013 12:00 AM "
Could my problem be related to any of this? I ran the script you suggested but no change. BTW, using FMP 12 advance, Mac OS 10.8.5. Anything else I can provide that might help?
Are any of these calculations unstored calculations? Unstored calculations can't be used on the "far" side of a relationship as a match field.
responseDate in table 2 is indexed - index all, but nextSendDate in table 1 is unstored, referencing an unstored calculation field " daysFromLaunch ". I changed daysFromLaunch to index all, then was able to changed nextSendDate to index all, flushed the cache but am still not seeing what I would expect to see.
table 1 is sorted by emailSendDate, table 2 is sorted by responseDate, the portal showing records from table 2 is sorted by responseDate.
What do you see in the portal when you remove the portal filter and just have it show the related records? (keep Campaign ID as the only match field for this test.)
I see all records in the related table by campaign_ID in the portal in each record in table 1
Which confirms that your basic relationship and the portal/layout design is working. I was rather expecting there to show an issue with your layout/portal set up here, but that appears to be ruled out now.
Taking a new look at: Table 2::responseDate >= table 1::emailSendDate and table 2::responseDate <= table 1::next_sendDate
Is your layout based on Table 1 or Table 2? Check Layout Setup | Show Records from. The name selected there should exactly match one of the two table occurrence names (the name to the left of ::) shown in your portal filter expression. Then check Portal Setup | Show Related Records from and see what name appears there. It should show the other of the two table occurrence names used in your portal filter.
IF that is not the case for either your layout or your portal, that would explain why the portal filter is not evaluating correctly.
Oh wow. You are good. The portal filter expression referencing table 1::yada was incorrect... a different relationship.