How is cDelete defined?
is MARKER | Delete a field of type text?
And can you document all the details of your relationship? I see no reason why this would disallow "allow creation..." on the portal side of the relationship unless MARKER | Delete is a calculation field. Even if it did, this should not prevent your find from working, but there could be an issue if cDelete is not a stored/indexed field. (It doesn't have to be stored and indexed to work for displaying data in the portal, but it can affect how a find works.)
"filtering" related level at the data level remains a useful approach that can make it a better option that filtering the portal in many cases.
And a filtered portal might also have issues for your find...
The relationship is as follows:
SalesID = SalesID MATCH FIELD
cDelete (not equal to) MARKER | Delete
SalesID is an indexed auto-serial field of type number
SalesID MATCH FIELD is an indexed field of type number
cDelete is an index calculation field of type text as you would expect.
MARKER | Delete is an index field of type text.
Just noticed that SalesID MATCH FIELD was accidentally set to text but I've been using that relationship without the delete for years without any issues. To be sure I switched it to number and saw no difference. Still broken with the delete.
Is this what you have? Note that I can enable "allow creation" with no problem...
Edit Note: scratch that. Once I clicked save, the allow creation option dims. That actually makes sense, but shouldn't affect your find behavior.
Ok, here's what I found after further testing of my demo file:
The relationship as specified doesn't work when MarkDelete is empty. It has to have data in it. When I added the text "Keep" in the auto-enter Data box and update existing records in the Child table to have the same text, then I could see related records in the portal to Child. I used a second table occurrence of Child without the added pair of match fields in order to have a control for adding new records.
Then I entered find mode and tried finding records by specifying text in the Name field in the original portal. It worked each time as it should.
If you examine the individual records in child you'll find that "keep" is never removed from the field. Instead, if you click the check box for Delete, this value is appended to the existing text with a return separating it from the original value. This does not create an issue for the relationship due to how FileMaker works with return separated lists in match fields, and it illustrates how a value list format can hide data not matching the current value list values from view.
Here's a download link to my demo file that you can examine for yourself: https://dl.dropboxusercontent.com/u/78737945/PortalSearchTest.fmp12
I see! OK, strange that the portal would still display all the information correctly though. Just a side note, my relationship is slightly different, please see the photo and the grayed out create option.
Sorry I failed to mention the difference. The second symbol between cDelete and MARKER | Delete is NOT EQUAL TO ...
There is no difference. Take a look at the demo file. The screen shot was taken before I clicked "change" and thus the not equals symbol hadn't updated in the lower part of the dialog yet though you can see it selected in the drop down.
The fact that your relationship matches suggests that Mark | Delete is never empty, that it has some other value in the field.
Thanks Phil, I added the word "Keep" to all the empty MARKER | Delete fields as well as added the auto entry for all future records. This has fixed the problem.
Always a great help, cheers.