File Manager 22.2 Getting Started Manual

Contents > Chapter 10

Chapter 10: Editing Records

Records can be edited by ordinary users, using the options available to them in VISTA’s packages. For most of the editing that you will need to do, these editing options should work just fine. However, you may need to use Fileman’s more sophisticated editing tools to do database cleanup.

The .01 Field

You may have heard IT people, or other super-users, refer to “the .01 field.” What does that mean? The .01 field is the single most important field in a file, as identified by the developer who created the file. For example, the .01 field of our imaginary COMPOSER file is NAME. The .01 field of a CLINIC file might be CLINIC ID NUMBER.

The .01 field plays a role in both adding and deleting records in a file. If you attempt to add a new record without filling in the .01 field, Fileman will not accept your record. To delete an entry, you can enter an at-sign (@) in the entry’s .01 field.

Enter or Edit File Entries Option

You can edit data in a file directly using the “Enter or Edit File Entries” option. Keep in mind that you will only be allowed to edit a file if you have Write access to the file (if you need to review the different levels of access and what they mean, they are listed in Chapter 4). When you choose this option, Fileman asks for the name of the file you want to edit:

Select OPTION: Enter or Edit File Entries <Return>
Input to What File:

If you’re not sure which files you’re allowed to edit, you can enter two question marks at this prompt to get a list.

Let’s assume we want to edit our trusty (and imaginary) COMPOSER file. Fileman next asks us which field(s) we’d like to edit:

Select OPTION: Enter or Edit File Entries <Return>
Input to what file: COMPOSER <Return>
Edit which field: ALL//

How you answer this prompt depends on what kind of database cleanup you’re trying to do. If, for example, you’re dealing with a problem where specific records are more or less completely screwed up, you would want to edit ALL fields for these records.

On the other hand, you may have a problem where one field consistently has wrong or incomplete information. In that situation, you would probably want to limit your editing to that one field.

For this first example, let’s assume we want to edit all fields.

Select OPTION: Enter or Edit File Entries <Return>
Input to what file: COMPOSER <Return>
Edit which field: ALL// <Return>

Once the composer is selected, Fileman walks through all the fields, giving you the opportunity to edit them.

Wait, that’s it? You can select a record by its .01 field, and then edit it? Can’t you just do that as a regular user, in VISTA?

Yes, at its most basic level, “Enter or Edit File Entries” is a little underwhelming. So, let’s not spend any more time at the basic level; let’s learn about some of the options that make this a powerful tool.

Using ^LOOP

As long as you have to specify, one at a time, which records you want to edit, the “Enter or Edit File Entries” option isn’t appreciably better than the options available to regular VISTA users. Luckily, there’s a way to tell Fileman that you want to look at a whole bunch of records. At the “select” prompt for choosing a record, enter the command ^LOOP. This tells Fileman to go through (or loop through) a whole series of records, without you having to select each one.

Select OPTION: Enter or Edit File Entries <Return>
Input to what file: COMPOSER <Return>
Edit which field: ALL// <Return>
Select COMPOSER NAME: ^LOOP <Return>
  Edit entries by: NAME//

The “Edit entries by” prompt is very similar to the “Sort by” prompt we’ve seen before. We can use it to sort and select a group of records to be edited.

We’ve seen in at least one of our examples that not all the composers in our COMPOSER file have the ERA field filled in. Let’s find those and fix them!

Select OPTION: Enter or Edit File Entries <Return>
Input to what file: COMPOSER <Return>
Edit which field: ALL// NAME <Return>
Then edit field: ERA <Return>
Then edit field: <Return>
Select COMPOSER NAME: ^LOOP <Return>
  Edit entries by: NAME// ERA <Return>
  Start with ERA: FIRST// @ <Return>
  Go to ERA: LAST// FIRST <Return>

There are a couple of things to note in this example. First, instead of opting to edit ALL fields, we’re limiting our edit to the NAME and ERA fields. When we select a specific field (rather than ALL), Fileman asks us which field we’d like to edit next. If we wanted, we could choose several fields, which, depending on the situation, might be preferable to going through all the fields for each record we look at.

Why are we choosing to edit the NAME field? If we don’t, we won’t see the name of the composer we’re editing! We’d just see a field labeled ERA, and we’d have to guess which composer it was.

It’s been a while since the sorting chapter, so we’ll remind you that the @ at the “Start with” prompt tells Fileman to start with the null values, which are the ones we want to edit. The null values sort to the top of the list, so if we start with them, we want to end with FIRST; that is, with the first record that has a non-null ERA field.

How to Stuff a Field

This section is about “stuffing” field values, which honestly sounds a little rude. All it means, though, is that Fileman allows you to specify a default value for the fields you want to edit.

To illustrate, let’s revisit our ERA editing example. The Romantic era was pretty big for composers; it is the most likely response to the ERA prompt. To save a little time, we could specify ROMANTIC as our default answer during our edit, like this:

Edit which field: ALL// NAME <Return>
Then edit field: ERA//ROMANTIC <Return>
Then edit field: <Return>

After typing the name of the field, ERA, we enter two slashes, followed by the value we want to stuff into the field. Because we used two slashes, Fileman will consider ROMANTIC to be the default for any record where ERA is blank. Fileman would next show us the records we asked for, and we would have the opportunity with each record to either accept the default or enter something else.

Setting a default before editing can save time. But we would still have to go through each of the records we specified.

Let’s consider a different scenario. Earlier we hinted that “Albuquerque” is often misspelled. Let’s suppose that, at our facility, there were several patient records where the city was spelled “Albaquerque.” We want to find those, and stuff the correct spelling into each patient record. Can we do that, without having to manually go through each one?

We can! Using ^LOOP, we can specify the records we want to see. And by using three slashes instead of two, we can stuff the correct value into each record. This is what that would look like:

Select OPTION: Enter or Edit File Entries <Return>
Input to what file: DEMO PATIENT <Return>
Edit which field: ALL// CITY///ALBUQUERQUE <Return>
Then edit field: <Return>
  Edit entries by: NAME// CITY <Return>
  Start with CITY: FIRST// ALBAQ <Return>
  Go to CITY: LAST// ALBAQZ <Return>

As you can imagine, the ability to stuff values into fields is incredibly powerful. And it has the potential to create some truly spectacular errors, if it is not used carefully. For example, when we stuffed “Albuquerque” into the city field, we needed to be careful about which records we selected. If we had begun our edit with ALBA rather than ALBAQ, we could have moved hundreds of innocent patients from Albany to Albuquerque in an instant!

We can also use three slashes to delete all field values for the records we select. To do this, we follow the three slashes with an @, like this:

Then edit field: ERA///@ <Return>

If we use the @ to stuff a null value, Fileman warns us that this will delete information that may already be entered in the field.

Using Templates

We mentioned earlier that the “Edit entries by” prompt you receive when you use ^LOOP is very similar to the “Sort by” prompts we’ve seen before. They are so similar, in fact, that you can actually use a Sort template with ^LOOP to choose the fields you want to edit, and the records within those fields. This is a handy option if you happen to have a Sort template that specifies the fields and records you want to edit. However, there is also a template specifically designed for use while editing.

INPUT Templates

By now we’ve learned how to create Sort templates, Print templates, and Search templates (which do exist for our purposes). Creating an Input template is very similar to what we’ve seen already.

If you select at least five different fields to edit, Fileman automatically prompts you for a template name. You can also specify the creation of a template by answering the “Edit which field” prompt with a right bracket.

Once you have your template saved, you can use it by entering its name, enclosed in brackets, at the “Edit which field” prompt. As with other templates we’ve seen so far, Fileman asks if you would like to edit the template before you use it. Editing an Input template is similar to editing a Sort or Print template. Chapter 7 has specifics of how this process works.

If you edit your Input template, you can insert a new field using the caret or up-arrow character (“^”), just as you can with a Print template.

In Chapter 7, we discussed how your IT department can use your Sort and Print templates to create new report options for your users. Similarly, your IT department can create new options based on your Input templates, so that your users have new options for how they enter and edit records.

Edit Qualifiers

In Chapter 7, we discussed sort and print qualifiers, which you can use to refine and format your reports. You can also use qualifiers when editing. Most of these qualifiers are intended to be used in Input templates that you share with users; they help define what your users see and how they enter information.

Qualifier Action
field;"xxx" Replace the field’s label with a literal string during an editing session.
field;T Replace a field’s label with its title during an editing session.
field;REQ Require a response to a field that is usually not required.
field;DUP Save responses for later use with spacebar recall.

You can combine specifiers by separating them them with semicolons, like this:

Then edit field: DATE OF BIRTH;T;REQ <Return>

Creating Special Prompts

Normally, Fileman refers to fields by their label. A label is a specific attribute belonging to a field, which is set by the programmer when the field is first created. The field label is what you usually see when sorting, editing, or printing files. For example, our imaginary COMPOSER file has fields labeled NAME, ERA, BIRTHDATE, and so on.

Two of the edit qualifiers allow you to show the user a field to edit, but use something other than the field label to tell the user which field it is. For example, we might have the user edit the BIRTHDATE field, but specify different text for them to see, like this:

Edit which field: BIRTHDATE;"DOB" <Return>

Then the user would see this:


Why would you do this? Maybe you have reason to think that your users (or some of your users) will be editing on a small and/or crowded screen, and you want to minimize the amount of space your prompt uses.

In addition to the label, fields can have titles. Often, the title is another name for the same information. You can choose to show the user the field’s title instead of its label by using “T” after the field, like this:

Edit which field: BIRTHDATE;T <Enter>

If you used that command for a template, the user would see the title of the field, instead of the label, when they were editing or entering records.

How do you know what a field’s title is? There’s a way you can view this, and other attributes belonging to a field, but it’s a little more advanced, and often requires a higher level of file permission. File attributes are covered in more detail in the Fileman 22.2 Advanced User Manual.

For now, you can see a field’s title by calling up the “Enter or Edit File Entries” option, and using the “T” qualifier when editing the field. You may just see the label, which means that this particular field does not have a title.

Requiring Input

As we discussed in Chapter 3, some fields are required by Fileman. This kind of requirement is set by programmers.

However, you, as a super-user, can make certain fields required within your template. This does not change their status in Fileman; Fileman will still regard them as non-required fields. You can, however, ensure that your users won’t be able to leave these fields blank. The specification looks like this:

Edit which field: NAME;REQ <Enter>

The REQ qualifier is a good one to use if a specific piece of information is badly needed in your department, but perhaps not in the facility as a whole. You can ensure that your users have to include it, without interfering with the practices of other departments.

Duplicating Input Values (Spacebar Recall)

Sometimes many entries will need the same data value input for a particular field. If you follow a field label with ;DUP, then your users can use spacebar recall to repeat their previous answer (spacebar recall is described in Chapter 3). For example, we could say:

Edit which field: ERA;DUP <Enter>

The users would then be able to use spacebar recall to repeat their earlier response. Since there are a limited number of answers to this field, spacebar recall could save the users a bit of time.

By now, we’ve seen a few ways you can manage user input in your templates. The following chart summarizes some things you might want to do for your users, and what commands you would use to make it happen.

I want to...... Command
Set up a default that users see when the field is blank. Two-slash stuff:
Allow spacebar recall. Duplicate qualifier:
Place a value in the field without user action. Three-slash stuff:
Require that a value be entered. Required qualifier:
Delete all values from the field without user action. Three-slash stuff of @:
Require that a value be entered and allow spacebar recall. Edit qualifiers can be combined!

Your Next Steps

As its title suggests, this manual is meant to get you started with the kinds of Fileman tasks you are most likely to perform as a super-user. Once you have finished with this manual, you have a few different options of where to go next.

If you are interested in more information about the packages your department users, those packages should have their own documentation, including information for super-users.

If you are interested in learning more about what super-users can do in Fileman, you will find it in the Fileman Advanced Users’ Manual.

If the kinds of things you want to do seem to involve programming, you could investigate the Fileman Programmers’ Getting Started Manual. You will probably need additional permissions if you are going to take on programming tasks.