File Manager 22.2 Getting Started Manual

Contents > Chapter 8

Chapter 8: Search

We have already learned how to sort entries, and select a certain range within that sort. There are situations, however, when sort-and-select isn’t going to get you the information you need.

For example, suppose we want to find out how many composers in our COMPOSER file have “Johann” (or “Johan”) as a first name. We can’t find this information by sorting; the NAME field sorts alphabetically by last name. We need to find a way to search within the NAME fields for the particular string we’re after.

How Searching Works

Now might be a good time to remind you that most packages have some kind of search option available to end users. It’s possible you can find the information you’re looking for without having to query Fileman directly.

If you do need to ask Fileman, you can use the Search File Entries option. Search File Entries has three basic steps: entering conditions, combining conditions, and formatting output. We’ll go over each of these in detail.

Invoking this option looks like this:

  -A- Search for COMPOSER field:

Entering Conditions

Once you have selected the search option, and the file to be searched, your next step is to enter one or more search conditions to test each entry. These conditions are sometimes called truth tests, which is a fancy computer language term for “yes or no question.”

Notice that our prompt starts with the letter “A.” This is Fileman’s way of helping us keep track of which search condition we’re on. Our first condition is “A,” our second will be “B,” and so on.

The question we want to ask Fileman is: “does the NAME field contain the string ‘Johan’?” (The name “Johann” contains “Johan,” so no matter how they spell it, this query will find them.)

We would enter that search condition like this:

  -A- Search for COMPOSER field: NAME <Enter>
  -A- Condition: [ <Enter> Contains
  -A- Contains NAME: JOHAN <Enter>

When we enter the left bracket, Fileman translates it to “contains,” which is the search condition we want. There are other symbols we can use for our search condition, as described in the table below.

For Field Types
All except word-processing
Numeric, free text, word-processing, MUMPS, set of codes, and computed fields.
Numeric, free text, MUMPS, computed, and date/time fields.
Less than
Numeric, computed, set of codes, free text, and date/time fields.
All data except word-processing.
Greater than
Numeric, computed, set of codes, free text, and date/time fields.

What is the difference between Equals and Matches? That’s a good question, and one that we’re not going to answer here, except to say you probably want to use Equals until you get better at this stuff.

After we specify our “contains” search, Fileman prompts us for the “B” conditions, like this:

  -A- Search for COMPOSER field: NAME <Enter>
  -A- Condition: [ <Enter> Contains
  -A- Contains NAME: JOHAN <Enter>

  -B- Search for COMPOSER field: <Enter>

We don’t have a “B” condition, so we press Return to tell Fileman that we’re done entering conditions.

Combining Conditions

After the search conditions have been established, Fileman next asks how to combine them. There are several options, but let’s start with our simple example.

  -A- Search for COMPOSER field: NAME <Enter>
  -A- Condition: [ <Enter> Contains
  -A- Contains NAME: JOHAN <Enter>

  -B- Search for COMPOSER field: <Enter>
  IF: A <Enter>

With the “if” prompt, Fileman is saying, “okay, I have the search conditions, now, how do I apply them?” Our response says, “if condition ‘A’ is true (that is, if the composer’s name contains ‘JOHAN’), then show me the record.”

We could also enter 'A or -A, both of which mean “not A.” That is, we could ask for a list of composers not named Johan or Johann.

After we enter A, Fileman does ask us for another possibility. Since our only other possibility, with just the one condition, is “not A,” we’ll go ahead and press Return to end this step.

  IF: A <Enter>
  OR: <Enter>

A Better Example

Don’t you hate it when manuals give you the easiest possible example, then leave it up to you to figure out what to do when it gets complicated? Yeah, so do we. So let’s come up with a more complicated set of criteria, and see how we would define them, and how we would combine them.

Let’s say we’re looking for a list of composers who are either named Johan or Johann, or are Romantic composers born after 1850, or were born in London.

(We have no idea why anyone would want this list, but in medicine you will do searches at least as complex as this, so it’s a good example.)

The first thing to do, before we even touch the keyboard, is figure out the logic of what we’re asking. We have three search conditions. The “Johan” one we already know how to do. We also have to look for composers born in London, which is a pretty straightforward search. We have to look for Romantic composers born after 1850....

You know what? We don’t have three search conditions; we have four. Because “Romantic era” and “born after 1850” are two conditions, not one, even though we intend to combine them. This is why it’s a good idea to work these things out ahead of time.

Now that we’re (pretty) sure we know what we’re asking, let’s define our conditions.

  -A- Search for COMPOSER field: NAME <Enter>
  -A- Condition: [ <Enter> Contains
  -A- Contains NAME: JOHAN <Enter>

  -B- Search for COMPOSER field: BIRTHPLACE <Enter>
  -B- Condition: = <Enter> Equals
  -B- Equals BIRTHPLACE: LONDON <Enter>

  -C- Search for COMPOSER field: ERA <Enter>
  -C- Condition: = <Enter> Equals
  -C- Equals ERA: ROMANTIC <Enter>

  -D- Search for COMPOSER field: BIRTHDATE <Enter>
  -D- Condition: > <Enter> Greater than
  -D- Greater than BIRTHDATE: 12/31/1850

  -E- Search for COMPOSER field: <Enter>


That was a lot of information, so let’s highlight a few things. First, we chose the “equals” condition (=) for the birthplace. This means that Fileman will only show us records where the birthplace matches “London” exactly. If somebody made an entry and misspelled London, that record will not be selected.

If it was really important to get every record, we could have used the “contains” condition instead, and ask Fileman for records that contain the string “Lond” (for example). That might get some misspellings that the “equals” condition missed. However, it might also give us other cities with similar names, such as New London and Londonderry.

Which condition you choose for your search depends on many factors. How important is it that you get every single record that might fit the criteria? How many “extra” records will you get with a looser condition? How likely is it that you will miss records with the stricter condition?

These questions are related to a broader issue, which is database integrity. If you’re having to go through a lot of extra steps to catch all the records you want, because information is misspelled, it may be time for a database cleanup. Some options for this are discussed in Chapter 10.

In this case, we decided that London is less likely to be misspelled than, say, Albuquerque, so we’re taking a chance with the “equals” condition.

In our imaginary COMPOSER file, we’re imagining that ERA is a set-of-codes field, rather than a free text field. When searching a set-of-codes field, you must search on the actual value, not the code that represents it. In our search, therefore, we used the whole word (ROMANTIC) rather than its code (R).

Now that we’ve established our conditions, let’s tell Fileman how to combine them:

  IF: A <Enter>
  OR: B <Enter>
  OR: C&D <Enter>
  OR: <Enter>

What we’re saying here is that we’d like to see the records where condition A is true, or condition B is true, or conditions C and D are both true.

When combining conditions, there are a few symbols you can use to tell Fileman what you want to see:

Description Example
The conditions on both sides of the AND operator must be true. The “&” symbol can be omitted (i.e., AB is the same as A&B). A&B
' or -
The condition following NOT must be false. If A is false, 'A evaluates as true. 'A
Enter on new line.
Only one of the conditions combined with OR needs to be true. If A is true and B is false, A OR B evaluates as true. IF: A <Enter>
OR: B <Enter>

The difficult thing about creating and combining search conditions is not using the correct symbols. The difficult thing is training yourself to think with the formal logic of a computer. We wish we could help with that, but experience is really the only way to learn how to do this. If you want to be a whiz at finding the data you need, practice doing searches.

Just as you were able to save sort templates and print templates, you can also save your search specifications in a Search template. Fileman prompts you for the name of a template after you finish combining your search conditions:

Store results of search in template:

If you do not want to save your search, you can just press Return to continue to the next step. Otherwise, you can save your search by giving your template a name. Fileman asks if you want to save your new template, then prompts you for a description, in the same way we’ve seen with other kinds of templates:

Store results of search in template: PRACTICE SEARCH <Enter>
Are you adding 'PRACTICE SEARCH' as a new SORT TEMPLATE? No// Y <Enter>

From here, you can enter a description and save your Sort template.

Whoa! Wait, hang on here. Sort template? We wanted to store a Search template!

Yes, we have uncovered a secret. To Fileman, a Search template is merely a specialized kind of Sort template. Every now and again, a VISTA expert will loftily inform you that “there’s no such thing as a Search template.” Technically, they’re correct. However, you probably want your Search templates to do different kinds of things from your Sort templates, so it’s perfectly okay to think of them as different kinds of templates. Even if not everybody agrees with you.

Inquire Templates

Just as Search templates are specialized Sort templates, Inquire templates are specialized Search templates. We mentioned Inquire templates briefly back in Chapter 5, but you hadn’t really learned about templates yet, so it’s worth going over them here.

You can create and use Inquire templates in the Inquire to File Entries option. As with other kinds of templates, you can tell Fileman you want to create an Inquire template by entering a right square bracket at the “select” prompt. If your inquiry includes four or more entries, Fileman automatically asks you if you would like to save it to an Inquire template.

Formatting Output

We’ve specified our search conditions, and told Fileman how to combine them, and saved (or not saved) our search. What comes next?

  IF: A <Enter>
  OR: B <Enter>
  OR: C&D <Enter>
  OR: <Enter>

Store results of search in template: <Enter>

Sort by: NAME//

Well, this is a familiar sight. Once you’ve finished combining your search conditions, the rest of it is the same sort and print prompts we’ve been working with for the past few chapters.

An interesting aspect of this is that you can augment your search with the same sort-and-select options we’ve already discussed in Chapters 6 and 7. If you choose this option, Fileman does the sort-and-select first, then runs your search on the resulting selected list.

Print Number of Matches Found

Returning to our original question, the one that started the chapter, we wanted to know how many composers were named Johan or Johann. We didn’t necessarily need to see a list of them; we just wanted to know how many there were.

We could, of course, just print them out and count them manually, but Fileman has another option for us. To print the number of matches found, without printing any of the matched entries, we can just press Return at the “first print field” prompt. That is, we don’t specify any fields to print. Fileman responds with the number of records found, without actually showing them to us.

Using Your Templates

Once you have created a Search template, you have two options for how to use it. You can use it in the “Search File Entries” option like this:

  -A- Search for COMPOSER field: [PRACTICE SEARCH] <Enter>

But remember what we said earlier. A Search template is really just a special kind of Sort template. Because of that, you can also use your Search template in the “Print File Entries” option, like this:


Sort by: NAME// [PRACTICE SEARCH]<Enter>

The important thing to keep in mind with search templates is that you may see different results with the different options.

When you use a Search template in the “Search File Entries” option, you are instructing Fileman to run your search query again. If the file has been updated since the last time you used the search, and some of the new records meet your search criteria, you will see these new records in the results.

When you use a search template in the “Print File Entries” option, you are instructing Fileman to use the results obtained the last time the search was saved. If the file has been updated since the last time you saved the search, you will not see any of the new records, even if they meet the search criteria.

A Search template can therefore be used to create and save a snapshot of data, which will remain the same no matter how many new records get added to a file.

Updating a Snapshot

There are times when creating a snapshot of key data is pretty darned handy. But what if we wanted to update our snapshot to include new data?

We can do this using the “Search File Entries” option. We call up the option, and use our PRACTICE SEARCH template, like this:

  -A- Search for COMPOSER field: [PRACTICE SEARCH] <Enter>
Store results of search in template:

After we specify our search template, Fileman asks us how to store the results. This prompt is the key to whether or not our snapshot gets updated. If we press Return here without entering any information, Fileman shows us the updated search results, but does not update the snapshot.

If we instead enter PRACTICE SEARCH, Fileman has a new prompt for us:

  -A- Search for COMPOSER field: [PRACTICE SEARCH] <Enter>
Store results of search in template: PRACTICE SEARCH <Enter>
Data already stored there...OK to purge? NO//

If we answer “YES” at this prompt, Fileman will update our snapshot. This means adding any new entries that meet our criteria, but it will also remove old entries that, for whatever reason, no longer meet the criteria.

Searching Multiples

In the End User section of this manual, we mentioned select prompts. Select prompts are often used with multiples, fields within a record that can store more than one value. For example, a patient record might have a DIAGNOSIS field, set up as a multiple so it could contain several different diagnoses. In our imaginary COMPOSER file, let’s imagine that each composer has a field called OPUS, set up as a multiple, which lists the composer’s works.

In a multiple, each entry or subfile can have its own subfields. For example, our OPUS field might have subfields for the opus name, composition date, and type of piece.

Searching on multiples is a special situation. If one of the fields in your search conditions is a multiple, Fileman prompts you for additional information, like this:

  -A- Search for COMPOSER field: OPUS <Enter>

    -A- Search for COMPOSER OPUS sub-field: NAME <Enter>
    -A- Condition: [ <Enter> Contains
    -A- Contains NAME: SYMPHONY #9 <Enter>

In this example, we are searching for composers who have written a Ninth Symphony. Once we complete our search conditions, and combine them, Fileman has some additional questions for us:

IF: A <Enter>
OR: <Enter>

Do you want this search specification to be considered true for
condition -A-
1 When at least one of the OPUS multiples satisfies it?
2 When all of the OPUS multiples satisfy it?
Choose 1-2: 1//

Our choices, then, are to choose composers who have at least one work called Symphony #9, or composers whose works are all called Symphony #9. For this example, the choice is pretty obvious. For some of the medical data you may end up searching for, the choice may be less obvious. Remember what we said earlier: practice this stuff to get good at it.