Hi all,

I am trying to create a portal that:

1)Has a google search type - did this!

2)Has the possibility to decide where to search (for example: search for articles, search for descriptions, etc.) - getting mad to do do this...

Does anyone has a solution?

I solved the first point making a global field, then a calculating field related to the record I want to search.

For the second point, I have been trying to use the getfield, but no results.

Thanks.

Really no ideas?

This is what I am trying to do. I want to be able to search in the "CODICE ARTICOLO" or "DESCRIZIONE" by selecting this option in a global field.

multipleColumnSearch.zip

Hi viandante! Welcome to FM Forums!

Unfortunately, I do not believe there is a way of forcing your Giacenze table to filter the key depending upon whether you have selected CODICE ARTICOLO or DESCRIZIONE - even if you have that gOPZ global in Giacenze (your child table). You could change Giacenze::OPZIONE to:

Case (

gOPZ = "DESCRIZIONE" ;

DESCRIZIONE ; CODICE ARTICOLO

)

GetField() wouldn't be necessary ... but you could not use standard calculation because it could not be indexed because it references the global (or even an unstored calc from your other table). You would need to use standard text field but even so, auto-enter REPLACE would only update the ONE record with the change (when you change the gOPZ global), and not all records in the table.

Even with vs. 10 and triggers, the script would need to fire through all records to update them (EVERY TIME the global was changed) and I think it would be quite slow and ugly.

UPDATE: You can (as you have) filter the portal based upon BOTH fields but not selecting to filter by only one or the other in the same portal. I do notice that both those cInsert* calculations are still set to number and they should be text.

:wink2:

Edited June 7, 200917 yr by Guest
Added update

the script would need to fire through all records to update them (EVERY TIME the global was changed) and I think it would be quite slow and ugly.

Not to mention that it would only work for the last user that made the selection.

Now, there IS a way to tell a relationship which matchfield/s on the child side it should "pick", but I believe it would be much simpler to script a find in list view than tagging each value of an exploded key with its field of origin.

Thanks for helping!

I have been working on this all this morning (rainy day). This thing is really challenging.

Now, I can search different fields, but the portal report just 1 row. It's a weird behaviour because it does the search, but it shows only the first rercord and not the others similar.

............

I have put all the calculation to text and translated all names to english :)

SearchMultipleFields.zip

I suggest you look at the As–You–Type Search Filtering demo here:

http://www.excelisys.com/web/downloads/index.php

Well, cool solution, but the problem with this is that what you find is not "clickable". I mean, on the portal I am using buttons with scripts and that is important to me, more than doing a serach for two different fields.

Did you had a look at the file? I really don't understand why the portal shows just 1 row!

You can add buttons to a list view, same as you can to a portal, and thus make the found records "clickable".

I did see your file, but I am not interested in looking for the flaw, because I don't find the basic approach worthwhile.