Can't perform find in a portal

[csharpmin]

I've looked at all similar posts, but answers my variation of this problem. I have a simple contact database with 2 tables: Contacts and phone_numbers. These are joined by contact ID. The phone numbers appear in the contact layout within a portal that contains two fields: type & number (e.g. "Work Phone" & "555-1234"). I've set the field behavior to allow data entry in find mode, but when I try a find of "Work Phone" in the type field in the portal, it says "No records match this find criteria". I'm not trying to filter the portal rows in the current record, I'm trying to find all contact records with "Work Phone" in the portal. The data type is text and the storage is set to All indexed.

Is there a setting I'm missing? This is supposed to work, right? I've double checked and there are indeed contact records that have a portal row that contains "Work Phone". The portal works correctly otherwise, displaying the info as it should. This same problem extends to other portals in my database, I cannot perform a find in any of them. Any ideas?

[Søren Dyhr]

Do the search in the related table instead, and when a found set is established issue a GTRR(FS) to get back to the matching records.

GTRR(FS) means: /fmhelp.filemaker.com/fmphelp_10/en/html/scripts_ref1.36.20.html

(FS) means found set...

This is the safe way to do it, but as such could the explanation to not being able to do it, that the field access have been turned off in the "Behaviour.." for the layout.

--sd

Edited April 17, 2010 by Guest

[LaRetta]

But if records are displaying in the portal (and you search for "Work Phone" and "Work Phone" appears in the portal before your search) then that parent record WOULD be found. It would help to see the file (save an empty clone) or possibly you can create a test file showing the issue?

Also, field behavior was verified that entry in Find was checked. Try clicking into the number field and copying all of it (within a portal row for one specific Contact). Then manually perform a find. Do you then find this exact Contact? There is nothing wrong with performing finds through portals; they find all parents which meet the related table's find criteria entered.

Something is amiss and we really want to help you identify it. :wink2:

[bruceR]

What type of field is "Type"?

[LaRetta]

I wondered as well, Bruce, because if a number it wouldn't find the text. But it specifies that data type is text and it was checked. And the problem extends to other portals (with different fields?) as well.

I really hope we can get the file; mysteries need to be solved. :wink2:

[csharpmin]

Thanks for your responses. I'm glad you want to help solve this mystery with me.

Going to Related records works fine from the portal.

The type of "type" is indeed text not number. Also under behavior both "in browse mode" and "in find mode" are checked for this field. It allows me to perform the find, it just yields no results.

If I go to the layout based on the exact same table occurrence as the portal in question, performing a find in the type field gives me accurate results.

Honestly this database is massive and contains over a hundred portals with a myriad of data, none of them that I've tested yield find results whether from the "type" field or any other, but all of them work properly otherwise. I didn't originate this database, could there be some sort of global setting or other programming that is trumping the ability to allow finds from portals. A permissions setting perhaps?

Edited April 18, 2010 by Guest

[LaRetta]

If you can perform a find on the parent and, if going to the child layout, you can perform a find in the child table then it wouldn't be a permission issue. What happens if you perform a find in the Type field (through the portal) and you just try to find an asterisk. Will it work then? How about finding on the number?

Otherwise, as much as I choke on the words, I'd have to say (without a file or sample) that I give up.

[LaRetta]

Oh! Another idea ... is the field set to Unicode in Options > Storage > Default Language? If so then the case sensitivity must match exactly or the find won't work.

[bruceR]

"Honestly this database is massive"

OK. Upload a clone.

[csharpmin]

The file is on a server at my office so I'm not able to share it at this time. I have another idea though.

This portal, like many in the database is based on a relationship with multiple criteria.

Specifically, the portal shows phone numbers and emails related to the "main contact" as opposed to the "spouse" who both exist in the same record, and it only shows contact info that hasn't been marked "archive".

The relationship is basically

contactID = contactID

and

constant1<>Spouse

and

constant1<>Archive

I think the problem is the find is not smart enough to add these additional criteria without my explicitly adding them.

I haven't tested this yet, but my theory is portal finds only work on simple relationships of equality.

Many of the other portals are tricky as well with content filtered using global fields.

Thoughts?

[LaRetta]

If it shows in the portal, you can find in those child records. You didn't answer my questions.

[Søren Dyhr]

I haven't tested this yet, but my theory is portal finds only work on simple relationships of equality.

I just have ... and no this take is not correct - but turning just one of the constants into type number by accident, could be what you have expirienced?

--sd

[csharpmin]

Sorry Laretta.

The language is English. Case sensitivity, searching an asterisk and searching for a number in the number field yield no results.

[csharpmin]

Soren, I just double checked the constants. They are actually numbers. The constant in the parent table is a calculation that equals 1. In the child table, the archive field gets a 1 if the record should be archived, the spouse field gets a 1 if the record relates to the spouse. All these fields are number fields. No luck here.

[LaRetta]

"Honestly this database is massive"

OK. Upload a clone.

Even if we had other guesses, we all would be wasting our time at this point. Seeing the file will be the only answer left. Do you know how to create an empty clone? File > Save A Copy As > and then in lower pop-up, select clone (no records).

UPDATE: I should also mention that you need to zip the file before attaching.

Edited April 20, 2010 by Guest

[Søren Dyhr]

What do you mean by "gets" here:

the archive field gets a 1 if the record should be archived, the spouse field gets a 1 if the record relates to the spouse.

...it's what triggers it that concerns me here, I would suggest you turn away from the use of constants on primary side ... and instead use something like the attached...

--sd

cflat.zip

[csharpmin]

If you press the "archive button" on the row of the record you want to archive, a script runs placing a "1" in the archive field of that child record. This removes it from the phone number portal and adds it to the phone number archive portal.

I thought it was a clever way of keeping track of old phone numbers so we don't keep entering the same bad phone number again and again. It may be the source of this problem though. And constants like these are widely used throughout this database. I've looked at the attached file and I don't fully understand what you've done yet. I see it's a self join and doesn't use a constant. I'll try to digest it more fully when I have time.

Also, I can't really add the file here because of the proprietary info the programming contains (that I don't own, and have signed non-disclosure.) If I can't get it to work using the idea behind your prototype, I'll recreate the offending portal in it's own file and upload.

Also, I'm wondering if your attachment, may help me with another problem I'm having in a current post in the relationships forum. My problem involves using a constant there too.

Thanks.

[Søren Dyhr]

I thought it was a clever way of keeping track of old phone numbers so we don't keep entering the same bad phone number again and again.

Yeah, thumbs up for seeing it - although your use of two secondary keys is due to own ehm... catering ... the matter could be a popup having a limited number of values in one single field. But it's probably due to not having seen that a portal not necessarily should show the adjacent relation, but could show something carried over more steps, to provide the filtering required.

Also, I'm wondering if your attachment, may help me with another problem I'm having in a current post in the relationships forum. My problem involves using a constant there too.

Although there is a rendering speed price to pay, is it far more flexible where AND'ing could feel a little limited, the Ugo'ing method I displayed in the template, could exhibit either XOR'- or OR'ing behaviours, the scope of permutations is simply larger.

--sd

[csharpmin]

I took a closer look at your example. Much thanks. I get it now. I'll try applying it to my database when I get a chance, and hopefully I be posting a success story soon.