Hey everyone...

I am looking for some general advice / best practise on scripted search using globals.

Now and then I read that one way of performing a search is to enter search terms in browse mode using global fields and then perform the find. I wonder what this means exactly. Does it mean that for each field that I want to make searchable I create a global field on a search layout where the user enters the search terms when in Browse mode? Then, after clicking the Submit button he gets put in Find mode and the script fills the actual search fields with what was entered in the global fields?

So, I would be grateful to receive some general advice on this; as this technique seems to be quite useful. Couldn’t find a „manual“ in my books and on the web.

Btw, the background for this is among others, that I have a problem where this technique seems to be a good solution. When my users start the database I want them to be able to choose the different tables they want to search at the same time. They’d check TableAfrica, TableEurope and TableAustralia and then they can enter search terms.

Let me know if I am on the wrong track...

: Mike

This will not answer your question, but may be relevant to your issue: you cannot search more than one table at a time (the result of a search is a found set of records in a table), and having multiple tables by continent doesn't look like a good approach.

Hey,

Thank you very much for your advice.

O.k., I must now admit that my example to make things clearer was not a good one.

The way the database is set up is as follows: The information common to all records is stored in a single big table, with relationships to other tables based on "type" of data, that hold the other pieces of information. So, via relationships from "ground info table" to "specific info table" I am able to search information in the related tables. Also, the tables have nothing to do with continents... As mentioned, the related tables hold info that does not appear in other tables. For example, one table called People holds first names and last names and birthdates, a table called Organizations holds organization names and abbreviations, and the Locations table holds specific geographic info.

The database itself is a kind of a reference tool. When somebody searches for Neil Armstrong it is pretty obvious that he wants to look up information about the person, but we found out that with foreign terms like Haid a lot of people don’t know what it actually is (it is both a common surname and a village’s name in Austria); so, we have to give them the opportunity to tick all the “tables” to avoid that something is missing.

Any hints on this?

I am very sorry that my approach to make things clearer was in the end more confusing!!!

Thanks again for your input!

: Mike

It's still not very clear. If you search for "Haid", you can find people whose name is Haid along with people who live in Haid. Or you can find locations named Haid. You cannot show these two results together, because they are not in the same table (though you could show them side-by-side in two portals). So what exactly is the result you expect to see following this search?

Hey,

Thanks for your answer.

Well, showing these results together actually works. When the user searches for “Haid” in all records he gets as a result the found records in list view: (see attached file)

The actual names (Arthur Haid, Haid Austria,…) are from the related tables. Clicking on the names opens a new window where the user can read all the details about the record.

The idea now is to allow the user at the beginning to search for locations only or persons only or both together and so on. So, somehow I'll have to let him make a choice and keep this choice for his searches. That is where I think globals could help, or stored variables.

Oh, I see (I think) - your People and Locations are not related, but types in a giant "Anything" table.

Well, the process should be simple enough: make the user enter "Haid" into a global field. Then have your script enter Find mode, and set the first field to search (say the related LastName in People) to the contents of the global field. Create a new request and set another search field the same way, and so on.

Well, the giant "Anything" table actually connects Persons, Locations and so on. It holds fields like InfoGeographic, InfoGeneral, Status and so on, while the related tables hold the specific info (LastName,...)

Thank you very much for your input regarding the search with global fields. I am playing with it now... looks very interesting and like a solution for what I have in mind...

Mike