Reports may be displayed in a window, directed to a specified text file or sent straight to the printer. Choosing Options from the Report submenu (keystroke equivalent Ctrl Print but see footnote to Appendix B) displays the Report options window, the topmost portion of which is illustrated. The three different output destinations may be selected via radio buttons and descriptions of these options now follow. A complete explanation of the rest of the Report options window will be found in section 3.10
For such reconstitution of the report window to be possible it is necessary to save three files for each report. One of these is a plain text file which may be viewed in an editor, printed out, incorporated into a wordprocessor document etc. The other two are data files with the same name as the text file stored in subdirectories called RecNums and Tabs. If either of these ancillary files is missing it will not be possible to display the report as it was and it will probably be simply loaded into your text editor instead. This will also happen to text files, other than normal database reports, saved in PrintJobs.
To avoid leaving unwanted data files in RecNums and Tabs when deleting a report it is best if deletion is carried out from the Show reports submenu rather than directly from a filer window. To do so, choose the reports to be deleted from the submenu using ADJUST. The menu will remain open and the chosen reports will be ticked. To untick a report click again with adjust. Delete ticked will only be unshaded when at least one report is ticked. Choosing Delete ticked will then delete all the ticked reports, removing all three files pertaining to each report. Delete all will delete the entire contents of the PrintJobs directory after requesting confirmation.
An option button in the Preferences window, Re-load last report allows the last saved report to be auto-loaded on opening a database (see 14.1). This is deselected by default. To activate the facility you will need to select the button and then save the Preference file either in the database (in which case it is operative for that database only) or in Powerbase, which will make it the default for all databases.
This report destination allows you to append output to an existing text file. Make sure the file-name entered is the same as that of the pre-existing file and select the Append button on the Save box. If you do this for a file which doesn't exist the effect is as though Append were not selected.
Powerbase is capable of producing reports in four different formats. Only two of these, Columns and Field-per-line, are available when
you display the report in a window or create it as a text-file and these are
selected via two radio buttons on the Report options window. When the output
destination is Printer two additional formats, Table and Label, are also available and are selected from the Printer setup window. These four formats will now be described.
![]() |
![]() |
Where the field selection includes an External text file, i.e a Text or Text block field, the Field-per-line format is the only one which may be used and will be selected automatically.
Although each field normally occupies a line to itself you can override this by holding down Shift as you click with ADJUST to select the field. You will then not get a new line after the field; the next field to be selected will appear (with its identifier) on the same line (so it's not strictly "Field-per-line"!). We will call this function field concatenation. It may be applied to any number of fields; keep Shift down while selecting all except the last one to appear on the line.
This feature is very useful if your report contains a mixture of long fields which need a line each and short ones which don't and would otherwise result in wasted space and paper. Suppose you'd selected the six fields for the above report in the following way:
The report would then appear as on the right, with the first two fields concatentated on one line and the last three on another. Concatenated fields are separated by the Spacer and the width of the report is governed by Text width (see 3.10.2).
This format is only available when outputting to the printer. It resembles Columns format but the lines and columns are separated by horizontal and vertical rules, forming a grid. When this format is selected a number of extra features are enabled allowing you to include extra (blank) columns and rows, making this format especially useful when you want a list to which information is to be added by hand (e.g. entering marks against a printed list of students).
The number and width of blank columns and the number of extra rows may be specified. You may provide headings for the blank columns by entering them in the writable field to the right of the Table button. Separate the headings with commas. Headings which are too wide for the column will be truncated to fit.
For a tidy result it is recommended that you increase the line-spacing from the default 120% to about 150% when using Table format. If you are using a colour printer the grid lines will be printed in the Rules colour (see 3.2.1). The default ruling of the table grid uses solid lines, irrespective of the settings described above in connection with Columns format. However, if you do want to use dotted lines, or even no lines, for either the horizontals or verticals you can override this default setting by means of a setting in the !Powerbase.Resources.Config file or in a separate Config file inside the database directory.
This format is meant for printing on special label stationery. Since such stationery is expensive you are advised to try out your settings on plain paper first. Selecting this format enables the label setup choices which include the label size and the number of labels in a row. It also allows optional fixed starting and finishing lines to appear on each label. The number of lines on the label is not needed; Powerbase works this out from the label height and print size and warns you if the data won't all fit.
Note that the horizontal and vertical dimensions are left-edge-to-left-edge and top-edge-to-top-edge distances and may therefore be greater than the actual label dimensions. A menu button enables you to choose one of the standard Avery label sheets and will set up the options automatically. If you use other types of label you can redefine this menu by editing the file !Powerbase.Resources.LabelForm and then re-starting Powerbase. The position of printing on the label is determined by the Left and Top margin settings (see 3.1.5).
Printing will normally begin on the first label in the first row on the sheet but, to enable you to use up a part sheet of labels, you may specify which label to begin with, e.g. for three-in-a-row labels, entering 5 would make printing start at the second label of the second row. (Remember that sheets are upside-down in the feeder-hoppers used by some ink-jet printers!) After the first sheet the starting-point reverts to the first label in the first row.
Each field normally appears on a separate line but fields may be concatenated (see 3.2.2) with the Spacer being used to separate the fields (see 3.10.2). This may be necessary if you are using separate fields for surname and initials or surname and forename. Fixed lines (i.e. the same for every label) may be printed before and/or after the selected fields and these lines will be printed in the Header font (see 3.1.5). Field data is mainly printed in the Body font (but see below). If a colour printer is in use then the Header and Body font colours will be used (see 3.2.1).
The Label format is most commonly used to print mailing labels and Powerbase can enhance these in two ways:
Powerbase can use many different types of field. All are described in 4.2.5 to 4.2.13 in connection with setting up a new database and you should refer to those sections to clarify what follows here. You can include data from the following types of field:
The field or group of fields chosen for inclusion in a report is called a field selection. Point at each of the required fields and click with ADJUST. The fields will be highlighted by reversing the foreground and background colours. Only those fields which can appear in reports (see 3.3) will respond to ADJUST in this way. A second ADJUST click will de-select the field. Note that the order in which you select the fields is important since that is the order in which they will appear in the report. The menu button on the Match window, beneath the Query panel, (see 3.5) will list the fields in the order in which they have been selected. Ctrl F has the same effect. (If no fields are selected Ctrl F gives a listing of all the fields.)
A contiguous range of fields may be selected by placing the caret in the first field then double-clicking with ADJUST in the last. To select all reportable fields choose Select all (Ctrl A, but see footnote to Appendix B) from the Report submenu. There is also a Clear selection entry on this submenu (Ctrl Z).
Although a Scrollable list is, strictly speaking, a single field, its columns are selected individually. You will find, however, that the order in which the columns are highlighted is immaterial; they are always printed in the order in which they appear in the record window. For other options applicable to Scrollable lists in reports see 3.10.1
If the selection includes a Referenced field the report will show the pathname of the object linked to the field. If the linked object is a plain text file it would be very useful to display the actual text instead: just as you can for the External Text and Text block fields. You can if fact do this by holding down ALT as you ADJUST-Click the field. As with Text and Text block fields the field-per-line format is automatically selected.
If a Selection file has been loaded by double-clicking in order to modify it and re-save under the same name, you can avoid having to re-type the filename by simply choosing Save selection from the menu without opening the Save box.
To save a default selection you need only select the option button Default selection in the Save box (thus causing the "!" to be added) and accept the supplied pathname by clicking Save or typing Return.
Unless we want a report to contain all the records in the database we need some means of telling Powerbase what are the common features of the records to include. There are two ways of doing this. The more versatile way (and the one which Powerbase uses by default) makes use of a search formula or query describing the characteristics of the required records. The remainder of this section deals with the construction and use of search formulae. For the alternative method, query by example, see 3.6.
Clicking the Report button on the tool-pane opens the Match window. The same thing happens if you choose Report from the main menu, or Create report from the Report submenu, or type the Print key on the keyboard (but see footnote to Appendix B). The most prominent feature of the Match window is a group of icons enclosed by a thin red border. This object is called the Query panel and you may have already seen it since it forms part of several windows. (For a list of these see Ch 2, Note 7.)
The writable icon in the Query panel, in whatever context the latter appears, is meant to take a search formula. The simplest thing you can do, of course, is to type nothing at all! If you then click the Report button on the Match window you will create a list of all the records in the current subfile of the database. You could achieve the same result by typing ALL indeed if, after producing the above list with a null formula, you click on the Old button (Ctrl O), which retrieves the last-used search formula, you will find ALL displayed.
Clicking MENU over the Query panel's writable icon calls up a menu of the search formulae you have used in the current session and you my use them again by choosing from the menu with SELECT. Unwanted menu items can be deleted by choosing with ADJUST. This behavious is exactly the same as for searching for a record by key. (See Ch 2.3.1) On closing the database the menu contents are saved in PrintRes as a Data file called Q. You may reload and display this by dragging it onto the Query panel's writable icon or by placing the caret in the writable icon and typing Ctrl Q. (It isn't loaded automatically because you might not want any of the old queries.)
The angle brackets are there for clarity and are not used in entering the actual formula. There must be no spaces between the three parts. A tag list (if it contains more than a single tag) has the form tag1,tag2,tag3,.... where tag1 etc. are field tags (see 4.2.4) which uniquely identify the fields to be matched. It is also possible to query data in validation tables linked to fields (see 5.9). A target list (if it contains more than a single target) has the form target1,target2,target3,.... where target1 etc. are the data items which are to be compared with the contents of the fields specified in the tag list. The comparator which links the tag list and target list determines the type of comparison to be made. The commonest is "=", meaning that one of the items in the target list must exactly match the content of one of the fields in the tag list.
If the Case button on the Query panel is selected then all comparisons will be case-specific, e.g. "Cat" will be regarded as different from "CAT" or "cat". If the Case button is not selected all those three will be considered identical.
The heading of a report shows which fields were used in the search formula, what targets were specified and what type of comparison was made. If a target was placed in quotes (which is the only way of searching for any string containing a comma, for example) then it appears in quotes in the heading also.
It is impossible to describe the use of search formulae adequately without quoting actual examples. As in the Tutorial file we will make considerable use of the Elements sample database. A simple example of a search formula consisting of a single search element is GP=T where GP is the field tag, = is the comparator and T is the target. This means "The field whose tag is GP must contain the value T", i.e. all transition elements (but no others) are to be included in the report.
A slightly more complex one is GP=1,2,3 which would be interpreted as "The GP field must match one of 1,2 or 3". This may also be entered as GP=1 OR GP=2 OR GP=3 which is possibly easier to understand but also somewhat longer.
A further example is OX1,OX2,OX3=3 meaning "One of the first three oxidation state fields must have the value 3". This could also be entered as OX1=3 OR OX2=3 OR OX3=3. Yet another way is OX1-OX3=3, i.e. you may specify a range of fields by giving the first and last separated by a hyphen. This is a useful abbreviation but must be used with care. It is only useful where all the fields in the range are contiguous, e.g. if the field-numbers are 7,8,9,10. If the fields in which you are interested are numbered 7,9,10,15 any result obtained from a search of fields 7-15 is likely to be nonsense since all the intervening fields (8,11,12,13,14) will also be examined.
What if you expect the target string to be somewhere in a record don't know which fields to test? You can replace the tag, tag list or tag range with @ as in @=T which causes all the fields in the record to be examined. It's slower but it works!
Note that in these examples only one of the fields in the tag list is required to match one of the targets in the target list (although it doesn't matter if more than one field matches more than one target). Sometimes we want an inclusive search so that all of the fields in the tag list match a given target or, less frequently, a field contains all of the values in the target list. It's a matter of connecting the search elements with AND instead of OR. You can do exactly that (although the following example is chemically nonsensical!): OX1=3 AND OX2=3 AND OX3=3
You may also save typing by using the ampersand (&) instead of the word AND, but the same result can be achieved even more briefly by simply doubling the comparator, in other words using == instead of = so that the formula becomes OX1,OX2,OX3==3.
Yet another way of forcing all the targets in a list to be matched is by using the reserved word AllOf. Applied to the example above gives the formula AllOf OX1,OX2,OX3=3, which you might find more understandable than the one with the double comparator.
= | is equal or identical to |
<> | is not equal or identical to |
~ | an alternative to <> |
< | is less than |
> | is greater than |
<= | is less than or equal to |
>= | is greater than or equal to |
{ | contains |
}{ | does not contain |
The full list of available comparators is shown in the table at right. { and }{ are used where the target value must (or must not) be part of the field but isn't expected to make up the whole field. It is sometimes useful to require all the items in a target list to be matched in a given field. e.g. Suppose we knew that someone's house number was 17 and that they lived on "<something> Avenue" but the actual name couldn't be remembered. In a database of addresses a search formula such as ADDR{{17,Avenue (note the doubled comparator) would find it by listing all records where ADDR contained both 17 and Avenue, whereas ADDR{17,Avenue would find all those addresses where the house number was 17, regardless of street name, and all those addresses with "Avenue" in them, whatever the house number. The aforementioned AllOf can be used on the target side of the formula as well as the field-tag side so you could achieve the same result with ADDR{AllOf 17,Avenue.
You may invert the logic of a search criterion by putting NOT in front of it. To include all non-transition elements you could use NOT (GP=T). Note the space after NOT, the need for brackets, and that the syntax isn't "GP NOT=T". You could equally well use either GP<>T or GP~T and may find either of these more understandable.
Be careful when using the negative comparators <> ("not equal to") and }{ ("does not contain") in conjunction with tag or target lists as opposed to a single tag or target. You might, for instance, interpret: GP<>1,2,3 to mean "field GP doesn't contain 1 or 2 or 3", i.e. the content isn't any of those targets. This would be sensible but inconsistent with the way in which GP=1,2,3 is interpreted; if the comparator isn't doubled the use of a tag or target list is always a short equivalent of multiple search elements linked by OR. In other words the example quoted would be interpreted as GP<>1 OR GP<>2 OR GP<>3 when what you probably mean is GP<>1 AND GP<>2 AND GP<>3. To secure this result with a target list you can double the comparator as previously described: GP<><>1,2,3, but it might be safer and less confusing to use another reserved word: NoneOf. The formula then becomes GP=NoneOf 1,2,3.
Note that AllOf and NoneOf contain no space (but must be followed by a space) and the use of upper and lowercase must be exactly as shown. Confusion with field-tags or target strings is then most unlikely. To complete the group there's a third reserved word AnyOf as in AnyOf OX1,OX2,OX3=3 or GP=AnyOf 1,2,3. It adds clarity to the formulae but does nothing else since the results would be exactly the same if the word was omitted.
To make multi-criterion searches either place tags and targets in comma-separated lists as described above or string search elements together with the connectives AND and OR. Use AND (or the ampersand, &) when a field must meet all of a set of criteria. e.g. GP=T & Z>50 & NAME{IUM for all transition metals with atomic numbers greater than 50 and names containing IUM. Use OR when a field need meet only one of a set of criteria. e.g. GP=L OR GP=A would find all lanthanide and actinide elements as the formula means "either L or A; I don't care which".
AND and OR can produce ambiguous search formulae e.g. GP=1 OR GP=2 AND Z<50 could mean either "elements in group 1 or 2 (don't care which) with atomic numbers less than 50" or "group 1 elements (of any atomic number) or group 2 elements whose atomic numbers are less than 50". You probably want the former, but Powerbase will give you the latter. To get what you require use brackets to make the logic clear. In other words write it as (GP=1 OR GP=2) AND Z<50. You could also write this as GP=1,2 & Z<50 without any need for brackets at all.
Numeric |
Calculated |
Record number |
Sequence number |
Day in week |
Day of month |
Month number |
Year |
This can easily catch you out. Suppose, for example, you want to include records for which NUM<8. You may be surprised to find records in which NUM contains values such as 55, 20, or 13 appearing, as well as those containing 4, 6, 2 etc! If this happens check what type of field NUM is. Unrestricted and Alphanumeric fields will give the above result, as will any others not listed above. Fields of types listed in the table will give the result you probably want.
You can force a comparison by numeric value for a field which consists of (or, at least, begins with) numerals, even though the field is not defined as of Numeric type, by enclosing the field tag in square brackets, e.g. [NUM]<8 would produce the desired result in the above example even if the field is Alphanumeric or Unrestricted. This is useful where you want to make a comparison but still allow the field to accept non-numeric characters. The comparison-by-value can only work in such cases if the number part of the field comes first. e.g. it will deal correctly with 55A, 20B, 13X but not with A55, B20, X13.
Note also that NAME=*TIN* finds PROTOACTINIUM, PLATINUM etc, but not TIN itself. NAME=S*IUM finds all names which begin with S and end with IUM, e.g. SAMARIUM, SCANDIUM, and SODIUM.
The effect of using single wild-card characters as in NAME=S####IUM is somewhat different. You are, again, asking for names which begin with S and end with IUM but this time SAMARIUM and SCANDIUM would be found, but not SODIUM since you have specified exactly 4 wild-carded letters between the S and the I. Finally, to find any 5-letter name, regardless of the actual letters you could enter NAME=#####.
It should be noted that individual columns of a Scrollable list may be defined as Numeric type and the precautions mentioned in 3.5.2 apply.
chars(NAME,L,3)=CAL |
chars(NAME,R,3)=RON |
chars(NAME,2,3)=ERB |
The chars() and word() functions may be combined to test characters in a specified word. If you think of it in that way it is easy to remember that chars() is opened first and the word() statement is nested inside it. The following example, using Friends is of no use at all but illustrates the point chars(word(ADD3,2),L,3)=Far will list only the record for Mary Jones. (Watch those brackets!) The 3rd address field (ADD3) reads "Little Farham" so we have targeted the leftmost 3 characters of word 2. Note that the position in chars() which is normally occupied by a field tag contains a complete word() statement.
Both word() and chars() may also be used on the right-hand, i.e. the target side of a search formula. A trivial example using Elements is chars(NAME,L,1)=chars(NAME,R,1) which compares the first character of the name with the last and lists MAGNESIUM, MENDELEVIUM, MOLYBDENUM, NEON and NITROGEN. An important feature here is that a field, rather then a literal string, is being referenced as the target. In this example it's the same field as the one on the left but it doesn't have to be. You may have occasion to compare the contents of two fields in a record without the use of word() or chars() and this can be done with the field() function.
Only use field() when you are comparing whole fields; if word() or chars() is used as in the final example in 3.5.5.2 you shouldn't use field().
You can also use calc() on the left-hand side, just as you can with word() and chars(). The formula calc(2*Z)=field(M) will, again, list OXYGEN only. Note the use of field() here where the tag M stands alone instead of being inside a function.
If a Query file has been loaded by double-clicking in order to modify it and re-save under the same name, you can avoid having to re-type the filename by simply choosing Save query from the menu without opening the Save box.
After that lengthy description of querying the database using a search formula we turn to the alternative; query by example. For brevity when comparing the two we will refer to them as QSF and QBE respectively. To select query by example choose Preferences from the iconbar menu, select the option button Query by example and click on Accept. The option then becomes active for all operations which would otherwise involve typing a search formula into the Query panel.
If you simply enter the required target strings Powerbase assumes that you want the all relevant fields to match exactly, i.e the effect is the same as using "=" in every search element of a search formula (see 3.5.1). There are, however, other comparators besides "=" which may be used in search formulae. You may use any of these in a QBE query by placing them at the start of the string, e.g. {Avenue in an Address field would match all records where the field contained the word "Avenue". An address such as "15 Acacia Avenue" could be found by this method whereas just entering the word Avenue wouldn't work because it would require the field to read "Avenue" and nothing more.
Wildcards may be used; e.g. you could list from the Elements database all elements ending in IUM by entering *IUM in the NAME field or all those whose symbol began with H by entering H# in the SYM field.
You may specify a target list to make the search include all records matching any item in the list. e.g. Leeds,Liverpool,Manchester in a Town field (if it will fit) would cause records with any of these places to be included. You can also specify a field list (equivalent to a tag list) provided that the fields form a contiguous group. The target string (which may be a target list, be wild-carded or be preceded by a comparator) is entered in the first field of the group. Press Return and enter " (double quote or "ditto" mark) in the next field and for the remaining fields of the group. (Pressing Return rather than moving the caret by means of the mouse ensures that you really are dealing with a contiguous group of fields.)
As supplied Powerbase uses QSF as the default query method and the Query by example button will be deselected when the Preferences window is displayed. If you want to make QBE the default you can edit the relevant line of the Config file in !Powerbase.Resources to read Query QBE instead of Query QSF. Don't forget the space after Query. Clicking Report on the tool-pane will then produce the blank record without displaying the Match window at all. How then, without the Match window and its own Report button to click after you have entered the target strings, do you tell Powerbase to proceed? Simply type the Print key on the keyboard.
The Case button was discussed in 3.5.1 and the Old button in 3.5. Selecting Reverse causes whatever index is in use to be scanned in reverse order, e.g. alphabetical lists will be produced in Z-A order. The Indexes button is discussed briefly in 3.13 and in detail in 7.3.
The default action button at bottom right reflects whichever of the four radio buttons on the left is selected. When the Match window is opened it is always Report which is selected, this being the most often used feature. If you merely want to know how many records match a specified set of criteria, without creating a report, select Count. The number of matching records appears just below the red border. Mark and Clear are explained in 3.8.2.
The Fields selected menu button (duplicated by Ctrl-F) will be shaded if there is no field selection, otherwise it lists the selected fields in the order of selection. This last is well worth remembering since there is no other indication of the order in which fields were selected. The icon directly below it indicates the selected output destination (see 3.1) by displaying a representation of a window, a text-file icon, or a printer. In the latter case the icon will be shaded if no printer driver is loaded. Clicking with SELECT on the icon opens the Report options window, in fact you may find this the most convenient way of doing so.
In many databases some keys may be repeated several times. This is especially true of subsidiary keys, but sometimes also occurs with primary keys. A report created with Ignore repetitions of key selected will contain only the first record having a given key; subsequent ones will be skipped.
Choose the comparator in the same way. Type the target string into the writable icon and click Add to formula. The search element will appear at the caret. The following modifications may be made to the procedure before clicking Add to formula:
Make sure the caret is in the Query panel's writable icon, hold down Ctrl and click with SELECT over the required field. The tag of the field will be entered in the search formula at the caret.
All the examples described so far report only on the current subfile. It is, however, possible to search multiple subfiles. Click Select subfiles and the query panel on the Match window changes as shown here. Any or all of the enabled subfiles may be selected or deselected (disabled subfiles are greyed out) and clicking Query returns the panel to its normal display. Note that is not possible to leave all subfiles unselected; attempting to do so will leave the the currently-in-use subfile selected. When more than one subfile is selected the label on the Select subfiles button is coloured red — a useful reminder when the subfile selector is closed.
When you create a report from more than one subfile the records are not merged into one alphabetically (or numerically) ordered list; the ordering starts afresh for each selected subfile. This isn't really a problem because you can always sort the completed report on any field to produce a single, ordered list (see 3.1.1).
Multi-subfile reports are often more useful if records from each subfile are separately totalled and preceded by a header. To achieve this enter "S" in the Page length icon. Each page will be headed with the number and name of the relevant subfile. Subsequent sorting on a field, although permissible, would not be useful since it would order the entire report according to the sort field without regard to subfile divisions. If the report is destined for the printer each subfile will begin on a new page, even if the previous page was only partly filled.
Attached to the bottom of the record window is the Mark pane (Note 2). If you tick the check-box, Mark record, the displayed record will be included in the report. Using the Search button or the browse controls you can call up each record you want and tick the box. You can also mark records from a windowed report: see 2.7.1.
Check box | Search formula | Which records are reported? |
Tick | No | Marked records only |
Tick | Yes ("Search within marked set" deselected) | Records matching formula plus marked records, whether they match or not |
Tick | Yes ("Search within marked set" selected) | Records matching formula only if they are also marked |
Cross | No | All records except those marked |
Cross | Yes | Records matching formula except those marked, even if they match the formula |
But what happens if you enter a search formula as well as marking records? If the records are marked for exclusion (i.e. with a cross) records which match the search formula will be reported unless they are so marked. When records are marked for inclusion the result depends on the status of the Search within marked set button on the Match window. If this button is not selected (the default situation) the report will contain all the marked records plus all records which match the search formula. However, if the button is selected the search takes place, as indicated, within the set of marked records and only those records which match the search formula and are also marked will be included. The table on the right summarises the results obtained in all possible cases. When using Search within marked set is inapplicable the button is deselected and shaded.(See also Note 3)
You might want to check that you have marked the right records before creating a report. This can be done by selecting the Find marks check-box. A report made while this icon is selected lists only the marked records, regardless of whether the marking is for inclusion or exclusion, and any search formula is ignored.
The Clear all button does exactly what it says. It is shaded when no record is marked. A further indication of whether records are marked is provided by the icon at the far right of the Query panel which displays either the green tick or the red cross when any record is marked. This applies to the whole database, by the way, not just to the current subfile.
Powerbase takes heed of marked records in any operation which involves the Query panel, i.e. batch move/delete, convert Referenced pathnames, filter, global change, export CSV file, export subset, as well as report creation.
Holding down Shift whilst clicking with SELECT on the Report button of the Match window creates a report containing just the displayed record; so does typing Shift-Print on the keyboard (but see footnote to Appendix B). Yet another method is to mark the displayed record as described in 3.8.1. A report generated without entering a search formula will then include only the marked record. The highlighted fields of the displayed record appear in the currently-selected report format as determined by the setting in the Report options window. If no fields are selected the action is as described in 3.4.2; Powerbase will use the default selection if it exists or, failing that, use the primary key field(s) as a selection.
To display this window you can choose Options from the Report submenu, type Ctrl Print (but see footnote to Appendix B), or click SELECT on the icon beneath the Fields selected menu on the Match window. Features such as Destination (see 3.1), Format (see 3.2), Colours and the Sort on facility (see 3.2.1) have already been dealt with extensively. The rest are covered here.
This format can result in very long lines indeed, especially if all the columns of multi-column lists are included in the selection. An option button Shrink line (selected by default) causes as much white space as possible to be removed, but lines could still be too long for the printer. The alternative format puts the data from each row of the list on a separate line so that the data aligns As columns. This occupies less room horizontally but much much more vertically. Sep is used between the data from cells in the same row but Row end is shaded because nothing is needed to delineate rows.
It can be very inconvenient to have an entire list (or even all the data from a single selected column) included in a report when only a single cell is of interest. The option button Only if targetted in query (deselected by default) overcomes the problem by restricting what is included to those rows in which the contents of a cell match a target in the search formula.
Field headings (tags) appear on each page of a report in Columns and Table formats, and at the beginnings of lines in Field-per-line format, unless None is selected.
Expand codes (OFF) causes extra data from a validation table to be substituted for (or added to) the coded data in fields linked to such tables (see 5.2).
Expand headers (ON) will show the expanded versions (see 5.2) of the target values for fields linked to validation tables in the list header. Turning the option OFF causes the target values to be shown exactly as typed in the search formula.
Upper case (OFF) causes all textual output to appear in capital letters.
Page numbers (OFF) allows the page number to appear as the first line of each page of a report
Date stamp (ON) makes the date and time when the report was created appear immediately below the line number, if present. It appears on the first page only.
Header (ON) causes the following lines to be printed below the date-stamp:
Footer (ON). Reports in Columns and Table format normally end with a footer which gives the total number of records in the report. If the output includes Numeric or Check-box fields and column calculations have been selected (see 6.5) the results of these too will be part of the footer.
Cut white space (ON). In Columns and Table format the width of columns is determined by the maximum defined length of the fields included in the selection. These lengths are often greater than the length of data actually present in the fields, resulting in a lot of "white space" between columns. With this option ON the surplus space will be automatically removed. Even if it is OFF you can still remove white space via the Report menu (see 3.1.1). Output to Printer always removes white space whether this button is ON or OFF
Title (blank) allows you to specify a descriptive title for a report. It appears below the header and will be printed on every page, but you may limit it to page 1 only by selecting the button to the right. The colour of the title may be selected independently of the rest of the list header.
Page length (0) determines the total length of page, including header, footer and top margin, for destinations other than Printer (for which the page length is determined by the top and bottom margin settings). The default value of 0 means no division into pages at all, but you may want to alter this if you drag text-files to the printer. In Field-per-line format Powerbase will try to avoid splitting a record between pages, but this can happen if the report includes Text or Text Block fields of greatly varying length. (It will also happen if the number of fields per record exceeds the length of the page!)
Text width (A) specifies the line length used in Field-per-line format. A means "Auto" and lets the program calculate the value. You may enter your own value (e.g. 70) to override this. Values are in characters.
Spacer (1) specifies how fields on the same line will be separated. Fields are first padded with spaces to the maximum width of the relevant data field (but see Shrink list above) and the spacer string then appears before starting the next field. Four interpretations of the contents of this icon are possible:
When the report destination is set to Printer clicking Lots more on the Report options window gives access to the Printer setup window. Some of the features of this window have already been described in connection with the Table (3.2.3) and Label (3.2.4) formats. Despite the complexity of the window most of the rest is fairly self-explanatory and only a few comments are necessary.
If the calculated new size is 5pt or greater and you are using RISC OS 3.50 or later you will be offered four choices:
The behaviour just described is modified somewhat if you have selected the pre-sorting option (see 3.2.1) or if you are printing from a report in a window (see 3.1.1). In both these cases the entire report is buffered in memory instead of processed page-by-page. A choice of smaller text to cope with over-long lines therefore applies to the entire report, not just to the current page. The same is true if you decide to proceed with the configured size.
There are places in the window for setting all four margins. If, however, you set a margin which is less than the minimum specified by the printer driver (which will probably mean as near the edge of the paper as the printer is capable of printing) then the printer driver's minimum is used instead. This particularly affects the minimum bottom margin which is quite large on many ink-jet printers; possibly 15mm or more. If you specify a bottom margin of 10mm and find you get one of 15mm it probably isn't Powerbase's fault! If a printer driver is loaded the As printer button will be available and, if selected, all four of the printer driver's minimum margins will be used.
Like all such windowed reports field analyses can be saved as text files or printed out (see 3.1.1).
It is, of course, possible for a field containing a date to be indexed. Action (a), above, takes precedence in such a case. You can, however, force action (b) instead by first selecting the field with ADJUST, then choosing from the menu. For cases not described above the menu entry simply says Analyse and is shaded. These reports are always in a window (from which they may, of course, be saved); the Destination buttons in the Report options window have no effect.
Create an index on the Group (GP) field, select the element name only, and create a report using the search formula GP=T
If you do this first with the Indexes button on the Query panel selected (default), then with it deselected, you will notice a difference between the times taken. Use ADJUST, not SELECT to click the Report button on the Match window so that the window remains open and you can see the actual times. On a StrongArm RiscPC the above test takes about 0.25 sec with Indexes selected and about twice as long with it deselected.
This may not sound like a difference worth bothering about, but remember that Elements is a very small database; you are extracting 31 elements from only 103. If you were targeting a simliar number in a database containing thousands of records the difference would be very marked indeed; a factor of 10 is common and a factor of 50 or more may be achieved in some instances.
Note 2
If the Mark pane isn't visible Ctrl M will display it. It is possible to configure Powerbase not to display the Mark pane (see 14.8) but even then it can be toggled ON and OFF with Ctrl M (back).
Note 3
If you use script commands you can make use of the "Search within marked set" feature by appending M to the commands !QUERY, !CSV and !FILTER.
(back).