Finding in portals

[DanBrill]

Hi,

I've never seen anyone flamed on this site. But I'll probably deserve it for this questions, because this seems too simple. Yet I can't get it to work.

I have a portal with a check box in each row. I just want to find records in the portal where the box is checked. I have a record that has related records in the portal, and some of them have the check box checked, but when I enter find mode and search for checked portal records, it tells me there are no matching records.

I've used this type of find in other portals with no problem. What am I doing wrong?

Thanks,

Dan

[Todd Dignan]

I'm not sure what your asking. In your parent file, if you have a lot of records. A portal that have similar line items but some diffrent and you do a find on one of the line items. You will find the records in parent file that have similar line items in the protal. Or. Are you trying to filter a portal.

[ernst]

Hi Dan,

I've encountered the same problem. It seems that finding in a portal does not work if the key is based on a global field.

The only workaround I could come up with is use a script that loops through the portal and checks every portal line.

Best regards,

Ernst

[Ugo DI LUCA]

Dan,

Searching a portal is not the best thing to do....

Now, if this value-list was defined in the Main File rather than in the related file, it could be that it is "slightly" different, therefore no matches could work....

Check your value-list, compare it from the one in the related or look at the values in the related file.

The best setting however, if this portal is not set to "creation of related records" would be to use a value-list originated from the field values in the related file.

[Ugo DI LUCA]

Hi Ernst,

Yes, searching for filtered portal doesn't work if the key is a global field.

Well, the first workaround would be to use a "classic field" instead of a global, which is often the best solution. This Temporary Key would only be used for the current record, thus moving from record to record would lead to an accurate filtering process.

And find can be performed on checkboxes.

The second, if this search is a kind of "daily find need" and you need to keep the global field, would be to use a concanation in the related file :

KEY &"-"& & KEY&"-"& Valuewithcheckox

and use another calculation at left side (Main File)

g_KEY & "-" & g_valueToSearch, where the g_valueToSearch is another filter.

Create a relationship using these new keys and draw a new portal with new fields from this relationship.

This way, when no filter is selected (g_valueToSearch), the portal shows all records, as if the relationship was a classic g_key::key

As soon as a g_valueToSearch is selected, the records would be filtered according to the value you're looking for within the relationship on the Key.

Hope that helps..

[Vaughan]

"Yes, searching for filtered portal doesn't work if the key is a global field."

If the local key is based on a global field, then all records in the local file will be found. Which is a more-or-less trivial result.

Remember, a find in a portal finds all *local* records that have a related record that matches the criteria. It does not find records in the related file.

[Ugo DI LUCA]

Hi Vaughan,

Sure.

The best method is to search directly in the related file....

Now, Dan is probably aware of that, and surely want to check if "at least" one related record has a checkbox turned on.

Of course this "find" will not end to a "one record in portal" .

- all related records would show if there is a checkbox turned on

- a message will appear if not.

unless he uses a filtered portal...

Now he has a message while he says there are checkboxes turned on in related. Thus, there is probably a "bad VL setting" or a "global field"

Again, agreed that direct finds in portals are not reliable nor useful.

[ernst]

Hi all,

The method that Ugo describes will indeed only show the portal lines that match the find criteria. Which is of course really neat.

But I think there's also sometimes a need to search a main file for criteria that are in portals without the need to filter the portals.

For example: assume a 'company' file displaying employees from an 'employees' file through portals.

When searching for all companies with an employee called 'Rob' by entering 'Rob' in the portal in find mode, everything will work as expected when the relation between the 'company' file and the 'employee' file is between 'stored' fields.

As soon as 'Do not store calculation results' is checked -which it is automatically if the key field is a calculation field with a global somewhere in the calculation- finding in the portal will not work any longer and always produce 'no results', even if the relation itself works.

To come back to Dan's original question, if his find function does not find the checked portal lines even though there are no globals in one of the key fields, it may be caused by the 'Do not store calculation results' option being checked one one

[Vaughan]

"The best method is to search directly in the related file...."

No.

My point is that the results are not the same. They are not equivilent operations. Performing a find in a portal finds the local records that have a related record that matches the criteria. Not the same as peforming the find in the related file.

[Ugo DI LUCA]

Yes Vaughan,

Searching in a portal for Item_ID005 will find all invoices where ItemID005 is part of an invoice.

...which really isn't as efficiant (nor useful in my opinion) as performing a find on Item_ID005 in the related file.

[DanBrill]

Hi Everyone,

Thanks for all of your help on my question. It seems that the problem is that the related field in the parent file is an unstored calculation. This seems similar to Ernst's observation that the portal find won't work if it is based on a global. Unfortunately I can't opt to store the calculation because it is based on a related field. So, the scripting method seems to be my best direction at this point.

Thanks again,

Dan

[DanBrill]

Post Script -- I was able to re-arrange the relationship so that it wouldn't be based on a calculation. Now the find works.

There are days when I long for Access SQL queries....

Cheers,

Dan