table of contents - staminadownloads.stamina.com.au/manuals/r5trainingmanuals/ql... · web...

Query Language Training

TABLE OF CONTENTS

Q/L CONCEPTS - OVERVIEW............................................................................................................3

QUERY LANGUAGE USAGE....................................................................................................................3FRONT-END TO PICK ACCESS................................................................................................................3PICK STRUCTURE...................................................................................................................................3CREATING/RUNNING A Q/L PROCEDURE...............................................................................................5GENERATING MENU ITEMS FROM Q/L TEMPLATE.................................................................................5

OTHER Q/L RELATED PROCESSES.................................................................................................6

QLDUP, QLIST, LISTFILE, DICTLIST GDLISTDELIST, LISTLIST

PICK VERBS...........................................................................................................................................7

DESCRIPTION / MAINTAINING................................................................................................................7REPORTS................................................................................................................................................9SELECT LISTS.........................................................................................................................................9GRAPHS................................................................................................................................................10OTHER VERBS......................................................................................................................................10

COUNT, SORT-LABEL, COMPARE, WHERE, WHATLISTU, FREE, LIST-LOCKS

FILES AND DICTIONARIES..............................................................................................................11

STRUCTURE..........................................................................................................................................11TYPES OF FILES...................................................................................................................................11

Master files.....................................................................................................................................11Transaction files............................................................................................................................12Index files.......................................................................................................................................13Balance files...................................................................................................................................13

DICTIONARY LISTING..........................................................................................................................13ID / Key..........................................................................................................................................14Attributes........................................................................................................................................14Values.............................................................................................................................................14

SORT CRITERIA..................................................................................................................................15

DESCRIPTION.......................................................................................................................................15SINGLE-VALUED SORTS......................................................................................................................15MULTI-VALUED SORTS.......................................................................................................................16

EXERCISE A.........................................................................................................................................17

Q/L MAINTENANCE...........................................................................................................................18

QLMNT - MAINTAINING.....................................................................................................................18XQL - EXECUTING..............................................................................................................................19

SELECTION CRITERIA.....................................................................................................................20

Overview.........................................................................................................................................20With / Without................................................................................................................................20Relational Operators.....................................................................................................................22

WILDCARDS.........................................................................................................................................24LOGICAL CONNECTIVES......................................................................................................................26MULTI-VALUES...................................................................................................................................28

I


TABLE OF CONTENTS

SELECT LISTS.....................................................................................................................................29

DESCRIPTION.......................................................................................................................................29EXECUTING / SAVING..........................................................................................................................30SELECTED FIELDS................................................................................................................................31QSELECT...........................................................................................................................................32USE IN SPECIAL PROCESSES................................................................................................................33THE NEXT KEY...................................................................................................................................33

EXERCISE B.........................................................................................................................................34

OUTPUT SPECIFICATIONS..............................................................................................................35

OVERALL QUERY STRUCTURE.............................................................................................................35DEFAULT OUTPUT FIELDS....................................................................................................................35SIMPLE OUTPUT...................................................................................................................................36DICTIONARY ITEM SPECIFICATIONS....................................................................................................39TOTALS................................................................................................................................................42

Standard Total...............................................................................................................................42Detail Suppress..............................................................................................................................43Grand Totals..................................................................................................................................45

BREAK-ON MODIFIER..........................................................................................................................46

HEADINGS............................................................................................................................................49

DESCRIPTION.......................................................................................................................................49HEADING OPTIONS..............................................................................................................................49

DEFINE PROCEDURES......................................................................................................................50

PURPOSE OF DEFQLPRC....................................................................................................................50HOW IT WORKS...................................................................................................................................50SPECIAL PROCEDURES.........................................................................................................................55

QLDUP, QLIST, DELIST, LISTLIST, QLREINDX

II


Q/L Concepts - Overview

Query Language UsageThe more common uses for the Query Language module are for producing ad hoc, user-definable reports and lists. Reports may be generated using a wide range of selection criteria, sorting methods, and output specifications. Totals and sub-totals are easily generated, as are “control breaks” to new pages on the change of certain data. Headings, footings and other finishing touches may also be added to reports.Select lists are also commonly generated out of the Query Language system, using the same sorting and selection criteria as reports. Select lists may be used as pre-select lists for other reports, as lists for printing labels, letters or other processing, or in conjunction with the “NeXT” key.

Front-end to Pick AccessThe Query Language module and it’s associated processes seen in the menu system, are basically a “front-end” to Pick’s Access processor. All query language processes “executed” from the menu system may also be keyed in at TCL (Terminal Control Language) and executed that way. Advantages in using the menu system include being able to store frequently used procedures, ability to “FiND” file names and dictionary names, and also to set security profiles so only authorised users may access the information. It is also much easier to work on a procedure during the authoring process through the menu system, as editing can be carried out line by line without having to re-key the whole procedure.Information on the Access processor may be found in the Pick Reference or Epick manuals, and this book may be used as a reference and extension to this class.Many other Access commands are available at TCL and through the Q/L menu options, such as commands to print labels, produce graphs (if Accuplot installed), view system usage and activity etc.

Pick StructureThe Pick database (on which Extra! and it’s associated accounts are installed) is made up of a hierarchical structure of accounts, files and dictionaries.

Each account defines a major work area in the database structure, and is usually accessed via a separate “logon” name. There is usually one account that contains all data specific to your site and is often called “Extra” or “QARMS” or a short name for your company : eg. “PJB”. Sometimes a separate account may be setup for each major company that is maintained on the system. This may be the case where a completely different set of customers, suppliers, or G/L accounts are used for each company. Often, you will also have a “PLAY” account on your system, where this account is basically a copy of the live data account.

3


In addition to your data account(s), other accounts will also be on your system that hold the programs and help text etc. These are usually called : STAMINA, HELP.FILE, DM etc. These accounts may be ignored for the purposes of query language access.

To get a complete listing of accounts on your system, you can type : listfiles system when at TCL in any account. The ‘real’ accounts will have a Type of “D”, where other accounts may have a type of “Q”. The “Q” type accounts are called Q Pointers, and are just ways of accessing or pointing to ‘real’ accounts. There may be other accounts with a type of “DX” or “DY”. These are ‘real’ accounts, although they are flagged so as not to save on your backup tape. A ‘PLAY’ type account is often setup in this way.

To perform query language procedures on your data, you should be logged onto the correct account. In most cases, this just means you should be logged onto “EXTRA” or “QARMS”.

Within each account, there is a complete list of files which may be accessed. Each file contains information or data that is logically related. Usually the file name gives a quick explanation as to the contents of the file. For example, the “PRODUCTS” file contains the main master file details of products on your system, and is maintained by the PRODMNT process. A complete listing of all files accessible within an account can be produced by typing : listfiles at TCL. There are also methods through the menu system where particular files may be found and listed. These methods will be dealt with in a later section.

With each file, there is always an associated file dictionary. The dictionary describes what information is contained in the file, and allows a number of ways of accessing that information, field by field. A dictionary for a file may be displayed by typing : LISTDICT filename at TCL. Again, there are processes within the menu system that allow file dictionaries to be displayed and printed.

4


Creating/Running a Q/L procedureThe processes involved to make, edit, and run query language procedures are all found on the main Query language menu : QLMENU. Often, when first creating a query language procedure, it is useful to print out a file dictionary using the DICTLIST process, and this listing may be used as a reference while composing the Q/L procedure. To create and maintain (edit) a query procedure, use the QLMNT process. Each record maintained through this process will generate one report or one select list. To execute or run a query language procedure that you have written through the QLMNTprocess, use the XQL process. Usually there is an option where the procedure can be generated to the screen, so you can quickly validate your procedure without having to print a hard-copy. An error in the formatting or structure of the query procedure is often picked up at this stage and reported on the screen - such as the use of a non-existent dictionary item. Select lists may be activated and deactivated using the ACTLIST and DACTLIST processes respectively. These processes should only be used in conjunction with the “NeXT” function key.

Generating menu items from Q/L templateOnce a Query Language procedure has been created and “debugged” (tested and found to produce the desired results), a ‘real process’ may be added to the menu system for easier running of the report or select list. This process is called : “Defining a Query Language Process” and is accessed via the process : DEFQLPRC. In addition to easier running of the report, another advantage is being able to “secure” the data being produced by the process, so only users with the relevant security may access and run the query procedure. Also, because the user can’t actually change any of the query language commands from the generated process, he can not corrupt your Query Language procedure database. A detailed view of the DEFQLPRC process is covered later in the course.

5


Other Q/L related processes

A brief description of other Q/L related processes follows :

QLDUP A quick method of creating a new query language procedure if it is similar to an existing procedure. This process copies an existing procedure to a procedure that does not yet exist, and from that point the new procedure may be amended to suit. The process does not in any way affect the original Q/L procedure.

QLIST Used to produce a hard-copy listing of Q/L procedures that exist on your system, along with all relevant details.

LISTFILE Produces a hard-copy listing of all files accessible within the current account. A brief description and optionally a full description may be included on the report. This report is similar to doing a LISTFILES command at TCL.

DICTLIST Produces a hard-copy listing of a dictionary associated with a selected file. The report contains details of the dictionary item names, and other relevant information.

GDLIST Similar to the above process, except the “Global” dictionary is listed. This dictionary is not related to any particular file on the system, but instead contains dictionary items that may be valid and applied to a wide range of files.

DELIST Deletes a select list that has been selected and stored on the system. Although not a mandatory process, it helps in the ‘cleaning up’ and ‘housekeeping’ of the system.

LISTLIST Produces a hard-copy listing of all select lists that have been executed and stored on the system. Information about when the list was created and what process created it are also included on the report.

6


Pick Verbs

Description / MaintainingPick verbs are commands used within the Query Language module to tell the system how to process the query language procedure. Each Pick verb is a code used within the Extra! system, and MUST also be a valid verb that could be typed in directly at TCL. The Pick verbs are created and maintained by using the PICKVERB process under the SYSTEM menu. Most systems have the four most commonly used verbs pre-installed, and it is rare that these would ever be modified or deleted. These verbs are : LIST, SORT, SELECT, and SSELECT. If you intend to add more verbs, you should have some knowledge of their existence under the Pick database, and how they may be utilised. Information about Pick verbs may be found in the Pick reference manual, although the most used verbs are covered in this class.As each query language procedure is created through the QLMNT process, you MUST enter a valid Pick Verb, which is used during the running or execution of that procedure. Associated with each Pick verb is also a list of questions that tell the Extra! Query Language Module how to best handle that type of procedure. For instance, if a particular Pick verb is not associated with a file (such as the LISTU verb), then the field prompting for a Filename in the QLMNT process will not be asked.

When maintaining a verb in the PICKVERB process, the following fields are prompted :

Pick Verb This is the code which must correspond to an actual Verb that is valid in the Pick database.

Description A descriptive extension of the code. This field is displayed in “FiND” screens and has no bearing on the effect of the verb.

Allow Tape Not used at present, but will be utilised if creating your own verbs to dump and restore to tape/floppy.

Allow Batch Tells Extra! whether or not to ask the Via Batch question when executing a Q/L procedure. It does not make sense to allow the batch processor to handle some Pick verbs, such as COUNT, LISTU, or WHERE, where the output of the procedure cannot be saved or is not meaningful if not viewed immediately. Some verbs also require interaction from the user, such as COMPARE or COPY, and therefore procedures that use these verbs should not be processed via the batch system.

Printer OK Tells Extra! whether or not to ask the Screen or Printer question while executing a Q/L procedure. Many verbs do not produce any output that may be sent to a printer, such as SELECT, SSELECT and COPY, and for these verbs, you should set this field to “N”.

7


Act on File Some Pick verbs have no relationship to a file, and therefore the filename question on the Query Language maintenance process may be skipped. Examples of these types of verbs are : WHERE, LISTU, and FREE. For these verbs, this field should contain an “N”.

Forms List This is another Yes/No type question. If the Pick verb forms a select list such as SELECT or SSELECT, then enter a “Y” in this field. Virtually all other verbs should have this field set to “N”.

Heading OK This question is used by the DEFQLPRC process when generating a user-defined Q/L process. If the field is set to “Y” for a particular verb (such as SORT), then for each “selection” type field associated with generating a report, you may have the details of that selection automatically included in the heading of the generated report. This facility is described in more detail in the discussion of the DEFQLPC process.

Options Allows you to specify options that are to be included with the normal execution of a Q/L procedure. For instance, you may specify an “I” option on a SORT verb, so that the item id’s are suppressed when producing a sorted report.

8


ReportsA “report” is an Access type query facility, which may be generated to the screen or printer. The two Pick verbs used to create a report are LIST and SORT. Both verbs always act on a Pick file, may be processed through the batch system, but do NOT form a select list.

The LIST verb produces a report which is NOT sorted in any way. The output of the report is produced in the order of which each item is stored in the file. To us, this appears to be random, although the system has a set method or algorithm by which locations of each item are calculated and stored.

The SORT verb acts in the same way as the LIST verb, although “sort” criteria may be added to a query language command so that a report is generated in a set, sorted sequence. On older Pick systems, it was illegal to use any kind of sort criteria in a LIST procedure, although on Advanced Pick systems today, a LIST procedure will automatically be processed in the same way as a SORT procedure if any type of sort criteria is found in the Q/L command.

A LIST procedure is often useed to quickly view the contents of items (records) in a file, in a random sequence. You should not confuse the LIST verb with select lists which are discussed in the next section.

Select ListsA select list is a list of items stored under a single list name which may be activated and used in a number of ways. A select list may be activated and used as a pre-select list to generating a report, used to select which items will be involved in special processing (such as printing labels or doing a stock replenishment), or used in conjunction with the “NeXT” function key. A select list can be generated by the following verbs : SELECT, SSELECT, or QSELECT. These verbs may all be processed via the batch system, always act on a file, and do NOT produce any output which may be sent to a printer (or screen).

The SELECT verb produces a select list in a non-sorted order, SSELECT is exactly the same except that it produces the list in a specified sorting sequence. The QSELECT verb (“Q”uick select) is often used to produce a selected list of items from an “index” type record, and is therefore usually a very quick way of accessing or selecting items in a large file. The select list generated will be sorted in the same order as found in the “index” item that was selected.

9


GraphsGraphs or charts may also be produced through the Query Language system, but only if the Accuplot package is installed. Accuplot is a third-party software product specifically written to run on the Pick database for the purpose of producing graphs. There are two main types of graphs or charts that may be generated (either to the screen or printer) : Bar/line graphs, and Pie charts. To produce a bar or line graph, you should use the PLOT or SPLOT verbs (SPLOT for a sorted graph). To produce a pie chart, use the PIE or SPIE verbs (SPIE to produce a sorted pie chart). These verbs are handled in a very similar way to the LIST and SORT verbs although they should not be processed via the batch system, as some interaction between the system and user is required as the Q/L procedure is executed. Full details of the use of these verbs should be examined in the Accuplot manual.

Other VerbsSome other verbs that you may find useful to enter and execute through the Query Language system allow you to : view system usage, copy or compare items in a file, do a quick count of items in a file, produce name and address labels, display available hard disk space etc.

Some of these verbs are displayed below, and I will leave it up to you to investigate and try them out for yourselves as “hands-on” exercises. No damage can be done to your database by using these verbs, as they do not in any way alter information on your system.

COUNTSORT-LABELCOMPAREWHEREWHATLISTUFREELIST-LOCKS

10


Files and Dictionaries

StructureAs mentioned previously, within a data account a number of files and dictionaries are contained on the system, and may be accessed for use in Query Language processes. Often, there may be hundreds or even thousands of accessible files within an account, so to find or list a group of files that you are interested in may seem a daunting task, however the system does provide a grouping facility for you. For the purposes of finding the name of a file (using the “FiND” function), you may narrow the selection by using a grouping called the G/L Source. G/L sources are not user-definable codes, as they are pre-set with your system and correspond to the modules installed on your system. Often there are codes representing sub-modules to narrow the selection of relevant files even further. Although the “G/L” prefix implies a relationship to the General Ledger system, this does not always have to be the case. The list of G/L Sources serve a dual process, in that they may be used to associate files with modules (for use in the Query Language System), but may also be used to associate posting sources in conjunction with the General Ledger System. Some valid G/L Sources are :

IN Inventory system. If entered on the “FiND” screen for Filename, only files directly used within the Inventory system would be listed.

BR Bank Reconciliation. Used to list all files associated with the B/R module.BRC Bank Reconciliation Cheques. Would only display files directly related to the

processing of B/R manual cheques - ie. the CHEQUE.TRX file. In this case, the BRC list of files would be a subset of files contained under the BR group.

Types of FilesGeneral definitions may be applied to the categorisation of files on the system. Typically there are four main types or categories of files in use, and although these are not specified in the data or dictionary portions of a file, they are often reflected in the NAME of the file. It is a good idea to have a knowledge of how files are designed on the system and how they may interact with each other in order to know “where to look” when faced with a new query language procedure to write.

The four main types of files are :

Master files Each of these types of files are often associated directly with a maintenance process on the menu. For example, the PRODUCTS file would be classed as a master file, and it is virtually wholly maintained by the PRODMNT process. Another example of a master file would be the GLCHART file, maintained by the CHART process. This file contains the G/L account codes, descriptions, alpha keys, whether debit or credit etc., but NOT details of account transactions or balances. Other smaller files which may be categorised as master files are sometimes called control files, and again these files are usually maintained by processes under a xxSTATIC type menu.

11


Examples of some of these files are : SALESTAX, GENPROD.CATEGORY, REGIONS, and INSTITUTION.TYPES. There are usually hard-coded or “canned” reports available on the menu system for producing lists of the control type files, but it is often necessary to create your own user-definable Query reports for the larger master type files, like PRODUCTS.

Transaction files These files can usually be broken down into two sub-categories : unposted transaction files, and posted transaction files. Each record in this type of file contains (as the name suggests) information and data relating to a transaction. Unposted transaction files are usually maintained directly by a process on the menu, may be listed using an EDIT list type process, and are passed through an updating process (called a POST) which clears the unposted file when complete. An example of an unposted type transaction file would be VOUCHER.ENTRIES. This file is maintained directly by the VOUCHER process in the Accounts Payable module, and each record in the file contains information relating to one A/P voucher. These details would include the supplier code, type of voucher, transaction date, reference numbers, descriptions, G/L account distributions and amounts. Once this file is posted through the POSTVOUC process, most of the details are copied to the ACTIVE.VOUCHERS file. This file would be classed as a posted type transaction file. You will find that most transaction files falling under this category are not user-maintainable, but are generated directly from a system posting program. It is often useful to produce query reports using a transaction file for analysis purposes - such as sales or purchase analysis reports over a set date range. Other examples of transaction files are : GENERAL.JOURNAL, PRODUCTS.TRX.DETAIL, CUSTOMERS.TRANSACTIONS, and JOB.TRANSACTIONS.

12


Index files There is nearly always at least one index type file associated with each posted transaction file. An index is a quick way of referencing a group of related records in a transaction file, and hence can be used to speed up a query language selection or report dramatically. There is usually one index type record for each master record, and within that index record is a list of pointers to transactions relating to that master record. For example, the CUSTOMERS.INDEX file has a separate record (item) for each active customer on the system. Each of these records contains a list of pointers to the relevant records in the CUSTOMERS.TRANSACTIONS file. So in this example, we could quickly select all current transactions for a particular customer by first accessing the index record for that customer in the CUSTOMERS.INDEX file. Other index records may be specific to an entity as well as the masterfile item. For example in the Inventory system, the PRODUCTS.TRX.INDEX file contains records which are specific to each entity/product combination.

Balance files These files are also built by posting programs, but also by “end of period” type programs. There is often a corresponding balance record for each record in the related index file. Balance type files contain summarised information and often monthly information, and are accumulated over a period of time. An example of a balances type file is the CUSTOMERS.BALANCES file. There is a record in this file for each customer on the system, and each record contains information on that customer’s purchases, payments, outstanding amounts etc. These figures are kept on an “overall” as well as “monthly” basis. Another often used balance type file in query language procedures is the PRODUCTS.BALANCES file, which contains information about the quantity levels, average costs, purchases, sales, tax etc. for products in the inventory system.

Dictionary ListingA dictionary, as mentioned previously, is a description of the fields which may be accessed in a data file. For each data file (a file is basically separated into two parts, a data portion, and a dictionary portion), there is always a set of dictionary items that may be listed. This list can either be sent to the printer by using the DICTLIST process, or by using the “FiND” function key on the relevant field in the QLMNT process. Each dictionary item tells the system where to access the information in the file, how to format or output the information, how big the information will be, and what heading should be placed at the top of a column of information.

13


An explanation of terms relating to files and dictionaries follows :

ID / Key The ID or Key to a file is a direct way of accessing ONE RECORD within that file. Given a filename and an item ID, the system can directly read that record from the file without having to search the file using other criteria. For example, the ID to the PRODUCTS file is the product code. Given a particular product code, the system can immediately read the correct record from the PRODUCTS file relating to that product. Master files, index files, and balance type files are usually keyed on codes maintained by the master maintenance processes. For example the key to the CUSTOMERS, CUSTOMERS.BALANCES, and CUSTOMERS.INDEX files is the customer code. Transaction type files are usually keyed on a sequence number that is automatically generated by the system and hidden from the user. This is the case with the PRODUCTS.TRX.DETAIL, and CUSTOMERS.TRANSACTIONS files, but is not the case with the ACTIVE.VOUCHERS file. This file is keyed on the voucher number, and while this IS system generated, it is not hidden from the user. The key or ID must ALWAYS be unique, in that it can only ever select one record from the file. Some keys are multi-part, ie. they are made up with two or more parts in order to form a unique key for each record. For example, the JOB.TRANSACTIONS file is keyed by a combination of Job number and transaction type. These parts to a key are separated by an asterisk (“*”), and this happens to be why you are NOT allowed to enter an asterisk character as part of a product code, customer code, supplier code etc.

Attributes Attributes are often referred to as “fields” and relate to individual lines of data within a record. For example, a record in the PRODUCTS file may be made up of 40 different attributes or fields. There would be an attribute for the generic product code, another for the unit cost, another for the salestax code etc. Each attribute in a file may have several dictionary items pointing to it, each dictionary item may format or output the data in a different way.

Values You will often hear the term multi-valued associated with file structures in the Pick System. This happens to be a fairly unique way of handling associated fields within a record in a database structure. Multi-values are a number of values contained under the one attribute. For example, consider an “A”ssembly type product record in the PRODUCTS file. One of the attributes in this file contains the component codes. This attribute is a multi-valued attribute as it may contain more than one component (the number of components is actually unlimited). Multi-valued attributes usually correspond with fields contained within a window in a process. There are special commands available for sorting and selecting multi-values in a Query Language procedure, and these will be covered in the next section.

14


Sort Criteria

DescriptionMany Query Language processes that are executed form either an output that may be shown on the screen or printer, or produce a select list that is stored on the system. It is preferable to have this output in a sorted format for easier reading and locating specific items. It should be noted that a sorted output from a query language process often takes longer to generate than an unsorted output, but this is a worthwhile price to pay for a readable report.

Pick verbs that create a sorted output include : SORT, SSELECT, SPLOT, SPIE, and SORT-LABEL. As noted previously, the use of a sort command in a query language procedure may automatically change a non-sort type verb to act like the related sort type verb.

It is possible within the same Query language command, to sort the data by one attribute, or by multiple attributes. For example, to produce a report of product codes, it may be sufficient to sort by the product code alone. However, for a sales analysis report, you may wish to sort by a salesman code, then by the generic product codes related to each salesman, then by the product codes related to each generic product.

Each sort command operates by using a dictionary item, and the justification of that dictionary item is important in how the SORT processes that attribute. The justification for a dictionary item may be either “L”eft or “R”ight, and this justification can usually be related to alphabetic/alpha-numeric or just numeric fields respectively.Left justified fields are sorted from the left-most character in the field first, then the second from left and so on until all characters in the field have been processed. Each character also has a certain sorting sequence. A blank character will be processed before special characters (eg. #@%*), special characters will be processed before numeric characters (0, 1, 2, 3 etc.), and numeric characters will be processed before alphabetic characters (A, B, C, D, E etc).Right justified fields process characters in the field in the opposite way. Ie. the right-most character in the field is processed first, then the second from right and so on until all characters in the field have been processed. The sort process of each character is the same as for characters in a left-justified field.

Single-Valued SortsSorting on a single-valued attribute is performed by using either the BY or BY-DSND modifiers. The BY modifier is used to produce an output sorted in ASCENDING sequence, ie. the method explained above where each character is sorted in it’s logical sequence. This is the way that most reports are generated, as it is the most logical way we think about the data that is being viewed.

15


There are instances, however, where we would want the report to be sorted in a descending sequence. For example, running an outstanding debtors list, we may want the highest debts (largest outstanding amounts) to appear first. In this case the BY-DSND modifier should be used.

Multi-Valued SortsMulti-valued fields have been discussed earlier, and it is possible to sort each value within these fields either in an ascending or descending sequence for formatting the output. When sorting individual values within a field in an ascending sequence, use the BY-EXP modifier. This modifier means “by exploding”, and in effect “explodes” the values within the nominated field and sorts them as if they were individual single values. A corresponding “descending” modifier may be used, called : BY-EXP-DSND. This modifier explodes the values with in an attribute and sorts them in a descending sequence as if they were single valued fields. A combination of BY, BY-DSND, BY-EXP, and BY-EXP-DSND may all be used within the same query language procedure, as long as each modifier relates to a different attribute in the file being output.

16


EXERCISE A

For some “hands-on” experience to practise and utilise some of the information learnt in this first section, I would encourage you to try some of your own simple SORT query commands at the TCL level.

To get to TCL, you may be able to just type “TCL” at any menu option. Alternatively, you probably have the security to be able to “break-out” of the menu system, and “end” to get to TCL.

The exercises are designed to give you experience in processing query language commands directly at TCL, to sort and list the contents of various files, and to help you become familiar with the contents of some of the files on your system.

It is suggested that you DON’T include any selection criteria or any output specifications in your query language commands, as these will be covered later in these notes. If no output specifications are entered, the numbered dictionary items in the file will be output (these are called default dictionary items).

In trying out your SORT commands, you may also wish to use the SAMPLING modifier. Please look this up in your reference manual for an explanation of it’s usage. While not mandatory, it may speed up a lot of the ‘test’ reports that you generate.

To abort a LIST or SORT printing on the screen, you may do a <Ctrl> <X> at the bottom of any page.

Try the following commands, and feel free to search for additional files and view their output :(If I have suggested an incorrect dictionary item name, print your own list of dictionary items for that file, and select the correct dictionary item.)

LIST CUSTOMERSSORT ACTIVE.VOUCHERS BY VOUCHER.TYPE BY SUPPLIERSORT GLCHART BY GLGROUP BY GLCATEGORY BY ACCOUNT.CODESORT CUSTOMERS.BALANCES BY-DSND O/S.BALANCE BY CUSTOMERSORT INVOICES BY-EXP PRODUCT.CODESORT DOCUMENTS BY-EXP BILL.CODE

NOTE : All these commands may be typed in “lower case” if on an Advanced Pick system.

17


Q/L Maintenance

QLMNT - MaintainingA query procedure, which you wish to run from the menu system, must first be entered into the maintenance process QLMNT (second process on QLMENU).

Entering the details is fairly straightforward and is explained in the screen layout below:

QLMNT Ver x.xx Company Name 99:99:99 xx xxx xxxxScreen 1 Maintain Stored Procedures

Please Select : CRE/AME/REV/DEL/END [ ]

*1) Procedure Name a code that you give to this procedure 2) Password a password you might give to this procedure to restrict access to this procedure

3) Description a name that helps describe the procedure

4) Verb Name a valid pick verb as maintained by PICKVERB 5) List Name only asked if verb is SELECT or SSELECT usually make the same as the procedure name 6) File Name only asked if the pick verb “acts” on a file.

==============Query Language Commands====================P1 a list of query commands that are appended to the Verb and the File name to formP2 a complete query sentence. All commands may be put on a single pane in thisP3 window, or split between panes at word breaks. It is common to split the commandP4 over multiple panes for easier editing, should the process require amending. P5P6Field # to change or Pnnn or Cnnn [ ](xx panes in window)

18


XQL - ExecutingTo run a query language process that has been entered through the QLMNT process, use the XQL process (first process on QLMENU).

XQL Ver 5.00 Company Name 99:99:99 13 Oct 1998Screen 1 Execute a User Defined Procedure

1) Procedure Name the procedure code as entered in QLMNT

Purpose these fields are displayed after the procedure Verb Name has been entered. They reflect the information that was entered on QLMNT. File Name

2) Save List Name Only asked for select lists in ‘change’ mode. Defines location of where list will be stored.3) Pre-Start List Enter a list name if you want to use an existing select list, as a pre-list to this procedure.4) Via Batch “N” or a number between 1 and 9.

5) Screen/Printer Reports may be sent to screen or printer.

Field # to change [ ]

19

Stamina Software, 03/01/-1,


Selection Criteria

OverviewSelection criteria is usually necessary within a query procedure, in order to limit the items that are being processed for the query report or select list. If a query procedure does not have any criteria limiting the selection, then all items in the file are eligible for processing. Criteria may be single level, or involve multiple conditions that must be met for an item to be included in the processing.

The WITH modify is most often used in conjunction with a dictionary item, a relational operator and a value. Multiple selection clauses may be joined together with logical connectives such as AND and OR. These terms are explained in the following paragraphs.

With / WithoutTo form a selection clause, you use the word WITH in conjunction with a dictionary item, an operator and a value. The word IF works in exactly the same way as WITH and so therefore the two operators are interchangeable to suit the user.

WITH may be used in a query sentence in conjunction with a dictionary item only, in which case an item is selected for processing if the field pointed to by the dictionary item has data in it.

For example : LIST PRODUCTS.BALANCES WITH QTY.O/H

Would list all product balance records where the quantity on hand level is not null (or empty) Note: A qty on hand of 0 will still be listed, as the field is not empty..Take note of the terms we are using so far :

LIST is our Pick VerbPRODUCTS.BALANCES is the name of the file we are processingWITH is the selection modifierQTY.O/H is a valid dictionary item either in the

PRODUCTS.BALANCES file or the global dictionary.

If this query was entered using the QLMNT process, the pick verb and the filename would be specified in the fields above the window, and the text WITH QTY.O/H would be entered into the first pane of the window labelled “User Commands”.

20


The word NO may be used before the WITH to negate the normal affect of the modifier.

For example : LIST CUSTOMERS WITH NO CONTACT This query sentence would list all records from the CUSTOMERS file where a contact person has not be entered. The modifier WITHOUT could be used in exactly the same way, and effectively replaces the words “WITH NO”. Ie. LIST CUSTOMERS WITHOUT CONTACT

21


Relational Operators

The WITH modifier is most often used with a relational modifier and a specific value, as well as a dictionary item. This gives the WITH clause the power to not just check whether data is present in a field or not, but to compare the data with a value.

Valid relational operators are :Symbol Meaning = or EQ Equal to# or NE, NO,NOT Not equal to> or GT, AFTER Greater than< or LT, BEFORE Less than>= or GE Greater than or equal to<= or LE Less than or equal to

An example using the “equal to” operator follows :

SORT CUSTOMERS WITH SALESMAN = “MT”

So, with this query sentence, we have added the relational operator “=” and a literal value. Note that a value should be enclosed in inverted commas.This example will produce a sorted report to the screen of all customers that have a salesman code of MT.NOTE : Because no SORT criteria was specified, the file is sorted by the ID or key to the CUSTOMERS file. In other words, it would be sorted by the customer code.

Another example :

SORT PRODUCTS.BALANCES BY GENERIC.PROD BY PRODUCT WITH QTY.O/H >= “1”

This example would produce a report of product balance records where the current quantity on hand of the product is greater than or equal to 1. The report would be sorted firstly by the generic product code, then by the product code.

22


The position of selection criteria and sort criteria within a query sentence is reasonably flexible, although it is recommended that you stick to a particular format, such as that presented here : sort criteria first, then selection criteria.

Our previous example of :

LIST CUSTOMERS WITH NO CONTACT

could be re-written with a relational operator and a value as :

LIST CUSTOMERS WITH CONTACT =“”

Most query sentences can be written and formatted in a variety of ways, some ways seem more logical and easier to understand than others. With experience and practice, you will become used to your own formatting methods and will tend to adhere to similar structures.

23


WildcardsWildcard characters may be used within the value string to allow some flexibility in the selection of the value. Rather than having a dictionary value directly match a value string, wildcard characters within the string widen the selection possibilities, and allow for a less-exact match between dictionary item and value.

Special wildcard characters may be used on each end of the value string to represent any number of characters that would allow the value to be matched with a dictionary item. These special characters are open square brackets : “[“ and “]”. The left square bracket must be used as the very first character in the value string. Using this type of wildcard character allows the value to be matched on the remaining characters in the value string without regard to how the dictionary value may begin.

For example, to produce a list of all customers with a name ending in “Smith”, the following query sentence could be used, incorporating the “[” wildcard :

SORT CUSTOMERS BY CUSTOMER.NAME WITH CUSTOMER.NAME = “[SMITH”

Customers with names such as “John Smith”, “Joe Smith”, “A. B. Smith” and just “Smith” would all be included in such a report. The casing of the value string does not need to exactly match that which is present in the actual record, therefore the word “Smith” may be typed in upper or lower case characters.

The right square bracket may only be used as the very last character in a value string. This type of wildcard character allows a match against the value string as long as the start of the string correctly matches the dictionary value.

For example, a list of suppliers with a phone number beginning in “049” could be produced as follows :

SORT SUPPLIER BY POST.CODE BY SUPPLIER.NAME WITH TELEPHONE = “(049)]”

Any supplier record with a telephone number beginning exactly with the five characters, ‘(‘, ‘0’, ‘4’, ‘9’, and ‘)’ would be valid candidates for the above report.

24


Another wildcard character may be used anywhere in the value string to represent a SINGLE character. This character is a carat : “^”. Any number of carat characters may be used within a string to represent exactly that number of characters.

For example, a list of New South Wales customers could be extracted by using the post code within the address in the following way :

SORT CUSTOMERS BY POST.CODE BY CUSTOMER.NAME WITH POST.CODE = “2^^^”

Customers with a post code beginning with a 2, then having exactly three other characters would be selected for the above report.

Of course, a mixture of the wildcard characters may be used, as in the following example:

SORT POSTED.INVOICES WITH POSTING.SOURCE =“[*OEI1^^”

This sentence would select all invoices that had been posted from an invoices journal from any company (the first ‘part’ of the field), and with a journal number from 100 to 199 (ie. a match on the ‘1’).

25


Logical ConnectivesWhen using multiple selection clauses within one query sentence, you must use logical connectives between the selection clauses. The two logical connectives are AND and OR.

If a logical connective is not used between selection clauses, then the query sentence will usually be resolved in all records being selected.

Using the OR connective will allow a valid selection of an item if one OR another selection clause meets the criteria. For example :

LIST CUSTOMERS WITH POST.CODE = “2300” OR WITH POST.CODE = “2302”

would produce a listing of customers with two types of post codes. Either “2300” or “2302”.

A query sentence using the OR connective and the same dictionary value may be simplified in the following way :

LIST CUSTOMERS WITH POST.CODE = “2300” “2302”

This sentence is processed in exactly the same way as the above sentence, and is thus much easier to write when a number of valid values must be specified.

26


Another example using the OR connective :

LIST PRODUCTS WITH GENERIC.PROD = “NUT” “BOLT” OR WITH UNIT.COST < “1.00” OR WITH PRICING.CATEGORY = “SMALL”

Spaces are required between each word as specified in the above example, but are not required between values within inverted commas. Ie. “NUT” “BOLT” could appear as “NUT””BOLT”.

The AND logical connective should be used where more than one selection clause must be met within a query sentence for the item to be included. For example :

SORT JOURNAL.SUMMARY BY ENTITY BY ACCOUNT WITH ENTITY = “SS” AND WITH YEAR.CODE = “95”

Only journal summary items that have an entity code of “SS” and with a year code of “95” would be included in the above listing. To modify the above sentence to also include items in the year “96”, we could add this value to the end of the sentence, representing an implicit OR connective :

SORT JOURNAL.SUMMARY BY ENTITY BY ACCOUNT WITH ENTITY = “SS” AND WITH YEAR.CODE = “95” “96”

Multiple selection clauses may be added to a query sentence, however there is a limit of nine AND connectives within one sentence.

27


Multi-ValuesYou can specify selection criteria on a multi-valued field, and as long as one of the values within the field match the value string, the item will be included in the query selection.

Consider an index record has a range of dates within one of its fields. We could select the whole item by placing a selection clause in a query sentence, which matched one or more of the dates.

For example, if an index record has the following multi-valued field in it :

5/6/95]7/6/95]20/6/95]30/6/95]2/8/95]15/8/95

the record would be included in the following query listing :

LIST PRODUCTS.TRX.INDEX WITH TRX.DATE = “20/6/95”

Also note, that when sorting a multi-valued field, only the FIRST value in the field will be included in the sort processing.

The BY-EXP modifier may be used as seen previously as a sorting mechanism, and also as part of a selection clause. For example :

SORT PRODUCTS.TRX.INDEX BY-EXP TRX.DATE = “20/6/95”

would include the same records in the report as the above listing, however the output of the listing may vary slightly. This will be examined in more detail in a later section.

28


Select Lists

DescriptionAs mentioned in the initial overview, select lists are a common usage for the Query Language interface. Select list usage may be categorised in three broad ways :

As pre-lists for other reports or lists. Using a select list as a pre-list may considerably speed the processing of a report, particularly if index files are available to use. For example, to list transactions for a particular product in a particular company, we could list the whole PRODUCTS.TRX.DETAIL file - placing selection criteria on the product code and company code, or we could create a select list using the PRODUCTS.TRX.INDEX file first, then running a report over the PRODUCTS.TRX.DETAIL file. The second method allows processing in virtually an instant, while the first method processing time may vary greatly, depending on the size of the file etc.

As a method of processing a unique, user-defined selection of items in a normal ‘menu’ type process. For example, Accounts Receivable statements may be printed by first specifying a select list. Therefore, virtually any ad-hoc selection of customers may be used to print statements. Select lists may also be used for label printing, letter printing, stock replenishment processing etc.

For use in conjunction with the <NeXT> function key. By activating a previously saved select list, each item in that list may be accessed by hitting the <NeXT> key.

Select lists may be created using one of the three following Pick Verbs :SELECT, SSELECT, or QSELECT

Another verb: NSELECT may also be used to create a select list, but only if preceded by another active list.

Once a select has been executed, that select list is said to be active, and remains so for the next statement that is executed. While the select list is active, it is used to limit the items processed in the next query statement. This can be repeated again and again, progressively limiting the number of items selected in the query processing.

To put this into an example, let’s take an example seen before :SORT JOURNAL.SUMMARY BY ENTITY BY ACCOUNT WITH ENTITY = “SS” AND WITH YEAR.CODE = “95” “96”

This query sentence could be broken down into 2 SELECT statements, then by a simple SORT statement :

SELECT JOURNAL.SUMMARY WITH ENTITY = “SS”SELECT JOURNAL.SUMMARY WITH YEAR.CODE = “95” “96”

29


SORT JOURNAL.SUMMARY BY ENTITY BY ACCOUNT

If these statements were entered at TCL, they would need to be executed one after the other, without other commands executed in between. The first SELECT gets all JOURNAL.SUMMARY records for the entity “SS”, and this list of records stays active for the second select. The second select, therefore is restricted to only those items selected from the first statement, and it places an additional restriction on the year code. This select list is then fed into the SORT query sentence, and therefore only those items meeting the search criteria in the first AND the second SELECT sentences are considered for the processing in the SORT statement.

Executing / SavingThe above example may be implemented within the menu system by creating a separate query procedure for each of these statements. Therefore, each statement would be entered as a separate record in the QLMNT process, the first two with a SELECT pick verb, the third with a SORT pick verb.

When executing these lists, we would not HAVE to execute them one after the other, as at TCL, because as we execute a select procedure, we also SAVE that list for later activating. The list is saved under a name that is given in the QLMNT process, and which may also be modified during the executing process : XQL.

To make a list active, so as to restrict the items being processed in another query procedure, we would use the select list name as a “Pre-Select List”. This field is seen in the XQL process, and when used in this way, causes the same sort of processing as seen at TCL when one query command is executed after another.

So, the above example could be processed as follows : - Create the three procedures in QLMNT as previously discussed. - Run XQL on the first query procedure. This selects the JOURNAL.SUMMARY records that have an entity code of “SS”.- Run XQL on the second query procedure, using the first list as a “Pre-Select List”.- Run XQL on the final query procedure, using the second list as a “Pre-Select List”.

Remember, these procedures could be separated by other menu processing, as each list is saved and then activated again when it is nominated as a “Pre-Select List”.

30


Selected FieldsUp till now, when we have created a select list from records in a file, the list produced is a list of the keys or Ids to that file. Ie. If we execute the query command :

SELECT PRODUCTS WITH GENERIC.PROD = “BOLT”

we create an active list of product codes.

We can use this list of product codes on the same file (ie. PRODUCTS) or on any other file that has a product code as it’s key.

To take another example:

SELECT CUSTOMERS.BALANCES WITH TOTAL.O/S.BALANCE > “10000”

This query statement would create a list of customer codes, where each customer’s outstanding balance exceeds $10,000.

This list of customer codes could be applied to the CUSTOMERS file for example, as both the CUSTOMERS and the CUSTOMERS.BALANCES file use the customer code as the key. Therefore, the query sentence :

SORT CUSTOMERS BY CUSTOMER.NAME

could be used with the above select list as a “pre” list.

It is also possible to create select lists from a file, using fields other than the key to the file, by specifying the dictionary item name as a parameter in the select sentence.

For example, we could follow the above select of the CUSTOMERS.BALANCES file with the statement :

SELECT CUSTOMERS SALESMAN

Therefore, once we have our list of customer’s that have an outstanding balance over $10,000, we could create a list of the salesman that service those customers by specifying the dictionary item SALESMAN at the end of the select sentence. Remember, if we didn’t put the word SALESMAN in this sentence, we would just end up with another list of customer codes. Note : It is possible that each salesman code is repeated many times in this list, as one salesman may service a number of customers whose balance has exceeded $10,000.

31


Select lists made up of fields other than the key to the file are handy when using index and transaction files. A select list may first be made using a field within an index, where this field is the key to a transaction file.For example, we could list all product transactions for a particular product and a particular company with the following two query commands :

SELECT PRODUCTS.TRX.INDEX WITH COMPANY = “SS” AND WITH PRODUCT.CODE =“ABC” DETAIL.ID

SORT PRODUCTS.TRX.DETAIL BY TRX.DATE

You can add more than one type of field to a select list by specifying multiple dictionary items as output fields for the select list. These types of select lists have limited uses, but are required at times.

QSELECTA QSELECT statement works in a similar way to a SELECT on an index, where the list created is made up of a series of fields contained in a multi-valued format in the index record. The QSELECT is named because it is a “Q”uick selection method under these special circumstances.

The above example could be transposed into a QSELECT statement as follows :

QSELECT PRODUCTS.TRX.INDEX “SS*ABC” (2

The “(2” in this statement represents field or attribute <2> in the PRODUCTS.TRX.INDEX record. This statement executes MUCH faster than the above SELECT statement because of two factors :

- We are directly referencing the index record by its item Id (or key).

- We are quick selecting an attribute in the record rather than selecting a field through a dictionary item.

32


Use in Special ProcessesIf we were to implement and execute any of the above examples through the QLMNT and XQL processes on the menu, each select list would be saved under a nominated heading or name. This list will remain intact on the system until it is :Overwritten by executing another procedure that saves a list with the same name.Manually deleted by using the DELIST process on the menu.

To use one of these lists in conjunction with one of the special processes, such as A/R statement printing, supplier label or letter printer, inventory stock replenishment processing etc., it is NOT necessary to “activate” the list using the ACTLIST process on the QLMENU as often thought. When running one of these special processes, there is a field present for entering a List Name. Once a valid name of a select list is entered (as created from the XQL process), the special procedure automatically “gets” that list and makes it active for the rest of the processing required. The help text in the special procedure usually explains how the select list should be formatted, or what type of fields it should contain. For example, when printing Accounts Receivable statements, the select list used should be a list of valid customer codes.

The NeXT keyThe <NeXT> function key (usually key “F6”) is a handy facility for performing multiple accesses to a file when used in conjunction with a select list. As we have learnt, a select list is a stored list of fields that may be used in a variety of ways. One way is to access each field in the list, one at a time, starting at the top of the list and working through it until reaching the very end of the list. This can be done by activating a previously stored list, and working through it with the NeXT key.

The NeXT key has a range of uses, one being to perform multiple accesses to a file through a menu process. One example of this is performing the following :

Create a list of customers whose outstanding balance exceeds say, 30 days. Use the “Chase Debtors” process (CHASDEBT) to ‘pull up’ each of these

customers in the list so as to follow up and check on their payments, one at a time.

To implement this procedure, you need to do the following :

Create a query select list using the QLMNT process, with a query sentence similar to : SSELECT CUSTOMERS.BALANCES WITH O/S.BAL1 > “0” OR WITH

O/S.BAL2+ > “0”

Execute this list using the XQL process, which in turn ‘saves’ the list under a name that you nominate.

Activate the select list using the ACTLIST process on the QLMENU.

33


Go to the CHASDEBT process, and hit the <NeXT> key when on the “Customer” field.

As you <ESC>ape from each record and continue to step through the select list using the <NeXT> key, you will eventually come to the end of the list, and the process will report : “Select list exhausted”. You can abort the currently active select list at any time by running the process : DEACTLIST.

Note : Only one select list can be active at any time on any particular port or line.

Tip : The above procedure for debtor chasing can be enhanced by creating a keystroke sequence which performs all the steps outlined above. This can be taken further by placing the keystroke into the “logon” sequence, so that the whole process is automatically performed when you log on in the morning. Obviously, this is not ideal for everybody, but may be handy for some account clerks.

EXERCISE B

For exercises to try on your own computer throughout the coming week, read through these notes and practise as many of the examples as you can. Vary the examples where appropriate to fit with the data on your system. Test the speed of various selects and sorts, in particular where replacing a SELECT with a QSELECT.

Look up other methods that may be used at TCL to manually save, activate, and delete select lists. How do you know when a select list is active at TCL ? Where are select lists saved ? Can this be altered ?

34


Output Specifications

Overall Query StructureSo far, in this course we have covered portions of a complete query statement - specifically : Pick verbs, filenames, sort criteria, and selection criteria. A complete query sentence is made up of these components as well as output specifications, and optionally a heading, footing, and other options.

Typically, the order in which these components appear in a query statement are :1. Pick verb2. Filename3. Sort criteria (if a sorting type verb)4. Selection criteria5. Output Specifications6. Heading7. Footing8. Output options

Default Output fieldsIf no dictionary items are specified for output (as seen throughout examples to date), the id or key to the file will be listed (output), followed by any default dictionary items that may be present in the file. Default dictionary items are referenced by numbers rather than names, where the numbers usually correspond with the attribute numbers in the file (although not always).

Fields that have numeric dictionary items are automatically output if no other output specifications are present, and as long as the numeric dictionary items are in sequence.

For example, if the PRODUCTS file contained the following dictionary items :

Dictionary item name Description 1 Generic product code2 Product description3 Product type4 Assembly level6 Stock units7 # of decimals

etc.If we entered the query command : LIST PRODUCTS, (note : there is no further output specifications), the listed output would show the product code (being the key to the file), the generic product code, the product description, the product type, and the assembly level. No further output would be present because there is a break in the numeric default dictionary items (ie. there is no ‘5’).

35


The output of this particular listing can be simplified even further to suppress the default dictionary output by using the ONLY modifier. The ONLY modifier is used between the Pick verb and the filename.For example :

LIST ONLY PRODUCTSwould list the product codes only (being the key to the PRODUCTS file).This type of listing is very handy for having a quick look at what items are present in a file, when the contents of each item does not have to be known.

Another simple way of modifying the default output of a listing, is by suppressing the item id (or key to the file). This can be done using the ID-SUPP (Id suppress) option. Either the word ID-SUPP entered within the query sentence, or the output option “I” perform an Id suppress on the output.

For example : LIST PRODUCTS ID-SUPP

orLIST PRODUCTS (I

would produce a listing from the PRODUCTS file of the generic product code, the product description, product type, and assembly level, but no product code.

Interestingly, if we combine these two limitations to a query sentence, ie. :LIST ONLY PRODUCTS ID-SUPP

we get a listing of blank pages only.

Simple OutputTo specify simple output for a query sentence, you only need enter the dictionary item names that reference the fields you want displayed - separated by spaces.

For example, to sort the PRODUCTS file, displaying the product code, unit cost and base selling price only, the following query sentence will work :

SORT PRODUCTS BY PRODUCT.CODE UNIT.COST BASE.SELL.PRICE

There is no need to specify the product code as an output dictionary item, because it is the key to the file. Some implementations of the QLMNT and XQL processes automatically suppress the item id (key) however, so be aware of this as you execute query processes through the menu system. The latest release of the software allows permanent output options to be attached to the Pick verb, via the PICKVERB process, so if you are used to always entering the key as one of the output dictionary items, put an “I” option against the SORT and LIST pick verbs.

36


With each output dictionary item specified, a new column will be produced on the report containing the data pointed to by that dictionary item. A heading will also appear at the top of each column, and this heading is retrieved from within the dictionary item specification. The width of the column is also specified within the dictionary item specification, but be aware that if the column heading is wider than the width specification - the actual column width will be extended to accommodate the heading. When the system generates a query report, it inserts one space only, between each column. If you require further spaces, you would need to specify special dictionary items that are made up of blank space only, or widen the width specification of each dictionary item.

A maximum width will be automatically placed on the report output - which will be linked to the output device itself. Ie. If the output is directed to the screen, the width of the report will be limited to 80 characters. If the output is directed to the printer, the width will be limited to 132 characters. If the total width of the report is less than this maximum, then each field of data that is output (ie. each output dictionary item) will form a vertical column on the report. Therefore, you would see data columns going ACROSS the page, and the items in the file going DOWN the page. If you specify too many output dictionary items, so that the total width of the report exceeds the relevant maximum, the system will automatically compensate by rearranging the format of the output. Each field of data output would be a line DOWN the page instead of across. Each item in the file is also represented DOWN the page, although each item would be separated by a blank line. Also note, that if there is no data present in a particular field, the line will be suppressed altogether when the output is going DOWN the page.

For example, the query :LIST PRODUCTS (P

directed to the printer, may produce the following output :

Products Generic Prod Prod No Description Product Type Assembly Level ABC GROUPA Test product ABC P DEF GROUPA Test product DEF A 5123 GROUPB Product 123 P

We would see the product codes listed under the “Products” heading, as this is the key to the file. Each default dictionary item would then produce a separate column on the report, where each column is separated by a space. NOTE : The width of each column is not accurately depicted in this example.The report would be correctly output in this columnar format because the total width of the report does not exceed 132 characters (being the maximum width to the printer).

37


If we directed this same query to the screen, ie. without the “(P” option, the following output may result :

Products ABC Generic Prod GROUPA Prod No Description Test product ABC Product Type P

Products DEF Generic Prod GROUPA Prod No Description Test product DEF Product Type A Assembly Level 5

Products 123 Generic Prod GROUPB Prod No Description Product 123 Product Type P

See how this output is much harder to read than the columnar format, and it becomes harder as more fields are added with totals etc. Note also, the suppression of the “Assembly Level” fields on the first and third items, as these products did not have an assembly level present.

38


Dictionary Item SpecificationsAs we have seen, when a dictionary item is referenced to produce output on a query report, details within the dictionary item can determine the column heading and also the column width. Other attributes within the dictionary specification can also determine the type and format of the output, such as the format of a date, or the number of decimals to be shown when outputting a number.

These types of specifications are contained in two attributes (fields) of the dictionary item called : “Conversion” and “Correlative” fields.

When data is stored in Pick type files, it is often stored in a different format to how we see it when it is output on a report. When dates are stored in the Pick database, they are stored as an integer sequential number, where each number represents one day after 31st December 1967. Therefore, 1st January 1968 was day “1” on the Pick calendar. 24th October, 1995 is day “10159” on the Pick calendar. For example, if we were to enter an invoice onto the system with the date : “24/10/95”, this date would actually be stored as “10159” within the INVOICES file.

Most numbers when stored in the Pick database, are stored without any decimal point.

The dictionary item associated with that field then identifies to the query processor how many decimal places should be inserted when the data is output.

The two most common “conversion” formats are thus, date conversion codes, and numeric masks.

A date conversion code tells the query processor what type of date output is required from the internal date number. The most common date conversion code that you will see is : D2/

The “D” means that the conversion code is a date type, the “2” means we only wish to show the last two numbers in the year, and the “/” specifies the character which separates the day, month, and year.

Therefore, if the internal number : “10159” is processed through a D2/ conversion, we would see the output as : 24/10/95. Other examples of date conversion codes, and their effects follow :

Conversion Code Output on day “10159” D/ 24/10/1995D 24 Oct 1995DD 24DM 10DY 1995D2- 24-10-95

39


A numeric mask conversion code processes a number stored without a decimal place, and modifies and formats it for output. During the formatting, a decimal place may be inserted, the number of decimal places may be specified, leading characters may be nominated, and the appropriate format - such as prefixing with a dollar sign may be specified.

When a number is entered via a process on the menu, you will usually see how many decimal places are required for any particular field. For example, when typing in a “Unit Cost” on the first screen of the product maintenance process : PRODMNT, the system will automatically convert the cost to show 4 decimal places. This number when stored in the Pick database, will actually be stored without the decimal point, and with an implicit 4 decimal places. Examples of the unit cost as entered via PRODMNT and as stored in the Pick database follow :

Unit Cost (as entered) Unit Cost (as stored) 25.1289 251289150.02 15002000.65 6500500 50000000.0010 10

If we wanted to list the unit cost in a report generated via a query on the PRODUCTS file, we would probably use the dictionary item : UNIT.COST. This dictionary item has a conversion code of : MR4

The “M” in this conversion code identifies it as a Mask, the “R” specifies the justification to be applied (ie. Right justified), and the “4” tells the output processor that there are four implicit decimal places in the field AND to show four decimal places when the field is output.

A slight variation on the conversion code, would be to use the code : MR24We still have the “Mask Right” specification, but a “2” has been inserted into the code. The “2” identifies how many decimal places to show in the final output. As the “2” wasn’t specified in the previous conversion code, the default “4” was taken. The “4” in the MR24 code still identifies the number of implicit decimal places contained in the internal data.

40


Examples of the above internal unit costs, processed through a variety of processing codes follows :

Unit Cost (internal format) MR4 conversion MR24 conversion 251289 25.1289 25.131500200 150.0200 150.026500 0.6500 0.655000000 500.0000 500.0010 0.0010 0.00

Note : The MR24 automatically rounds to the closest 2 decimal places.

Other conversions and correlatives that you may see within a dictionary listing are :

Tx,y Text extraction. Data is extracted and truncated from the field before being output. “x” is the start character in the data to extract, and “y” is the number of characters to extract. Often used to shorten the column width of descriptions. If the width of the column was decreased alone, the description would still “rap-around” in the column - thereby taking up two lines instead of one. By adding a text extraction conversion as well as shortening the column width, the description is literally cutoff at the column width.

Gx*y Group extraction. “x” is the number of groups to skip before extracting, and “y” is the number of groups to extract. (‘*’ is the delimiter between groups, and may be changed to suit.) Mostly used on multi-part keys in a file, to separate out one group or part. For example, the INVOICES file has a key of Invoice Number*Entity code. To extract just the invoice number from the key, we could use a conversion code of G0*1.

Tfilename;Xvalue;;attribute File Translate. Takes the data in the field, and uses it as the key to read another file, and return a specific attribute and value from the translated file. Usually used to read a description from a file when the code is known. For example, the dictionary item GENPROD.DESCRIPTION in the PRODUCTS file works on attribute <1> (being the generic product code for a product), and processes it through the file translation code : TGENERIC.PRODUCT;X;;1. This conversion reads the GENERIC.PRODUCT file (using the generic product code), and returns attribute <1>, which is the generic product description.

S;x;y Substitution. When operating on data in a field, the attribute or text string x is used if the data is not zero (or null). If the data is null or zero, the attribute or text string y is output. For example, if we had a field in the INVOICES file which contained a “1” if the invoice had been printed, and a “0” if it hadn’t been printed, we could use the substitution code S;”Printed”;”Not Printed” to produce meaningful output on a report.

41


A Arithmetic function. Attributes may be added, subtracted, divided, multiplied together etc. Other conversion codes may be embedded within the arithmetic function, such as file translations, and substitutions. For example, the dictionary item MAX.POSSIBLE.FREE.STOCK in the PRODUCTS.BALANCES file contains the conversion code : A2-23-24. This conversion would output the quantity on hand (field <2>) less any invoice allocations (field <23>), less any customer order allocations (field <24>).

F F-Correlative. Performs same functions as an “A” function, but uses a different format (reverse polish notation). In fact, when an “A” conversion is processed in a query report, the system changes the function into an “F” function before interpreting it. “A” functions are usually easier to read than their corresponding “F” functions, but some people prefer to program directly using an F-correlative.

Totals

Standard TotalAny numeric field in a query report may be automatically totalled by the system, with the total displayed at the bottom of the relevant column on the report. A total is implemented by using the word TOTAL in front of the dictionary item that you wish to accumulate, and you can total as many columns as you like on a query report.

For example :

LIST CUSTOMERS.BALANCES TOTAL NET.O/S.BALANCE

We have specified that we want to list the file of customer balances, and we want to display the net outstanding balance for each customer. By using the word TOTAL, we will also get an overall total of outstanding amounts for all customers at the very end of the report.

Another example :

SORT PRODUCTS.BALANCES BY PRODUCT WITH ENTITY = “SS” AND WITH QTY.O/H > “0” PRODUCT.DESCRIPTION QTY.O/H AVG.COST LAST.COST TOTAL AVG.VALUE TOTAL REPLACE.VALUE

Provides a report on products within the “SS” company, and shows the total value at average cost and total value at replacement (last) cost among other fields.

42


Detail SuppressAny report that is generating totals, may also have the detail lines suppressed (not printed), so that only the totals display or print. To suppress the detail of a report, use the modifier DET-SUPP within the query sentence, or use the output option (D at the end of the query sentence.

Suppressing the detail of a report is desirable when you only need the total information or “bottom line” of a report, and are not interested in the individual line details. Using a DET-SUPP option is a quick way of turning a “detail” report into a “summary” report.

Any columns in a report that are not totalled, will obviously produce no output if a DET-SUPP modifier is used. Ie. If we are suppressing the detail, there is nothing else to display if there is no total.

Taking the above examples in conjunction with a detail suppress option :

LIST CUSTOMERS.BALANCES TOTAL NET.O/S.BALANCE DET-SUPPor

LIST CUSTOMERS.BALANCES TOTAL NET.O/S.BALANCE (D

Either of these query sentences will produce a “one line” output similar to :Net o/s...Balance35253.85

This figure being the total outstanding balance for all customers.

43


The second example :

SORT PRODUCTS.BALANCES BY PRODUCT WITH ENTITY = “SS” AND WITH QTY.O/H > “0” PRODUCT.DESCRIPTION QTY.O/H AVG.COST LAST.COST TOTAL AVG.VALUE TOTAL REPLACE.VALUE DET-SUPP

This query sentence would produce an output similar to :

Product........ Qty O/H. Average Cost Last Cost Value @..... Value @....Description Average Cost Last Cost 125321.24 128634.65

The only two valid fields in this example are the two last columns - ie. the columns being totalled.

Another way of performing quick overall totals, is to use the SUM Pick verb. The SUM verb may be used to get quick totals of one field within a file at a time. To use SUM on the above example, we would type :

SUM PRODUCTS.BALANCES WITH ENTITY = “SS” AND WITH QTY.O/H > “0” AVG.VALUEand

SUM PRODUCTS.BALANCES WITH ENTITY = “SS” AND WITH QTY.O/H > “0” REPLACE.VALUE

These two sentences would produce the output :Total of Value @]Average Cost = 125321.24

andTotal of Value @]Last Cost = 128634.65

respectively.

44


Grand TotalsUsing the TOTAL modifier as we have so far produces just one total at the bottom of the report, and is thus a grand total in it’s own right. This total can be “prettied up” though, by using the GRAND-TOTAL modifier. This is a modifier that may be used towards the end of a query sentence, and it allows a tag to be assigned to the grand total, and also allows options such as underlining the grand total line. The tag or grand total description should be shown within inverted commas (“) after the GRAND-TOTAL words, and any options are enclosed within single quote marks (‘), also within the inverted commas.

For example,

LIST CUSTOMERS.BALANCES TOTAL NET.O/S.BALANCE GRAND-TOTAL “Total O/S Balance ‘U’”

If we had not used the GRAND-TOTAL modifier, the grand total would appear as just a figure at the end of the report, with three asterisks in the left column. By using the GRAND-TOTAL modifier, we get the words “Total O/S Balance” appearing on the grand total line (instead of the asterisks), and we have also used a ‘U’ option which gives us an underline. (A grand total “underline” is actually a double overline.)

Other options that may be used (singularly or together) with the GRAND-TOTAL modifier are :U Produces an underline (overline) for the grand total figure.L Suppresses the line feed just before the grand total line is output.P Produces a form feed (Page eject) just before the grand total line is output.

45


Break-on ModifierA BREAK-ON modifier may be used within a query sentence to break up the visual display of data if a change is detected in one of the output fields. A break may just produce an extra blank line in the printed output, or it may force a break to a new page on the change of data in a particular column. You can also use breaks to produce sub-totals throughout the report.

When a BREAK-ON modifier is used, it precedes an output dictionary item, and may be followed by an accompanying “break-on label” and also options.Ie. BREAK-ON output_dictionary_item “break-on label ‘options’”The break-on label and options are both optional parameters.

The BREAK-ON modifier should always be used in conjunction with the SORT verb. This is because the break works by detecting a change in data, and this is only meaningful if the data is sorted in the first place.

For example, a simple customer name and address listing :

SORT CUSTOMERS BY POST.CODE BY CUSTOMER.NAME WITH POST.CODE = “2]” CUSTOMER.NAME ADDRESS.LINE.1 ADDRESS.LINE.2 ADDRESS.LINE.3 POST.CODE

could be enhanced by producing a break for each change in postcode :

SORT CUSTOMERS BY POST.CODE BY CUSTOMER.NAME WITH POST.CODE = “2]” CUSTOMER.NAME ADDRESS.LINE.1 ADDRESS.LINE.2 ADDRESS.LINE.3 BREAK-ON POST.CODE

When a change in postcodes occurs, the report will contain a line with just three asterisks in the postcode column, making it easier to detect the change when scanning the report.

Multiple breaks may be generated within the one report as well. These are called nested breaks, and should be specified in the order of the break level. The highest level breaks should be specified first, followed by the lower levels. A good tip is to specify your BREAK-ON dictionary items in the same order as they are sorted within the query statement.

Consider that our CUSTOMERS file has the suburb in the ADDRESS.LINE.3 field. If we wanted to sort our name and address listing firstly by postcode, then by suburb - break to a new page on each change of postcode, and produce a blank line between each change of suburb, we could use the following query sentence :

SORT CUSTOMERS BY POST.CODE BY ADDRESS.LINE.3 BY CUSTOMER.NAME WITH POST.CODE = “2]” CUSTOMER.NAME ADDRESS.LINE.1 ADDRESS.LINE.2 BREAK-ON POST.CODE “‘P’” BREAK-ON ADDRESS.LINE.3

46


“P” is a special option, which causes the report to jump to a new page on a break.

As mentioned, whenever a break in specified data occurs, an automatic sub-total will be produced for any output fields that are being totalled. These totals are produced in addition to the usual grand total that appears when accumulating numeric fields.

For example, a query sentence could be written to produce a stock value report for all products in a particular company, and we could request sub-totals of the stock value for each generic product grouping.

SORT PRODUCTS.BALANCES BY GENERIC.PROD BY PRODUCT WITH COMPANY = “SS” AND WITH QTY.O/H > “0” BREAK-ON GENERIC.PROD PRODUCT PRODUCT.DESCRIPTION QTY.O/H AVG.COST TOTAL AVG.VALUE GRAND-TOTAL “Total Stock Value ‘U’” ID-SUPP

Because we want the generic product code to be the first column on the report (instead of the default ‘key’), we have used an ID-SUPP option to suppress the output of the Id, and later in the query sentence we have specifically requested the product code.

This query could be shortened and modified to produce a summary report, so that we just see stock values for each generic product and no other details, by using the detail suppress modifier : DET-SUPP :

SORT PRODUCTS.BALANCES BY GENERIC.PROD WITH COMPANY = “SS” AND WITH QTY.O/H > “0” BREAK-ON GENERIC.PROD TOTAL AVG.VALUE GRAND-TOTAL “Total Stock Value ‘U’” ID-SUPP DET-SUPP

Note : the ID-SUPP DET-SUPP modifiers could be replaced with the options : (ID

Remember, if we use the detail suppression option, all detail lines are suppressed EXCEPT for the total lines - therefore the only lines output will be the sub-totals that are generated as a result of the BREAK-ON modifiers, and the grand total line.

A label may be specified as part of the BREAK-ON clause within inverted commas after the output dictionary item. A label is some text that you want to appear on the break line of the report, which will replace the three asterisks that normally appear.For example, instead of just BREAK-ON GENERIC.PROD in the above sentence, we could say : BREAK-ON GENERIC.PROD “Total for this Generic Product :” and those words would appear on each break line.

A number of options may also be inserted within the inverted commas, enclosed in single quotation marks. One useful option is “V”, which tells the query processor to insert the Value of the break at this point in the break label. Again modifying the above example : BREAK-ON GENERIC.PROD “Total for Generic Product ‘V’”, would display the generic product code on each break line, alongside the total stock value for that generic

47


product. When breaking to a new page on the change of output, it is often desirable to have the break value appear in the heading at the top of the page. To do this you need to use the HEADING modifier (which we will discuss later) and the options ‘B’ and ‘P’ with the BREAK-ON modifier : Ie. : BREAK-ON GENERIC.PROD “Total for Generic Product ‘VBP’” . Using this clause would ensure a relevant label is displayed alongside each total line, and also the generic product code relevant to each page would be displayed in the heading.

The most commonly used BREAK-ON options appear below :

B Insert the break value in the heading or footing of the report.D Suppress the break line if there is only one detail line since the last break.L Suppress the blank line that normally appears above the break line (not valid with

“U”)N Reset the page counter to 1 on break.P Produce form feed (page eject) on break.R Inhibit the rollover of the break line if at the end of the page.U Underline (actually a single overline) all the total fields on the report.V Output the break value in the break-on label.

48


Headings

DescriptionA heading is easily specified to be placed at the top of each report page by using the HEADING modifier. The HEADING modifier is usually one of the last components that make up a query sentence, and is specified just before any output options. A footing (text to appear at the bottom of each page) may also be specified, and takes exactly the same format as the HEADING modifier, except that the word FOOTING is used.

Following the word HEADING should be the text that you want to have appear in the heading, enclosed in inverted commas. Certain heading options may also be specified throughout the heading text, by enclosing the options within single quotation marks. Therefore the format is :

HEADING “ text to appear in heading ‘options’ more text ‘more options’”

Heading OptionsOptions placed through the heading text can alter the formatting of the text in desirable ways, such as automatic centering on the page, and including an automatic page number within the heading.

Specifically, the most common options are :

C Centre the text (appearing to the left of the option) on the page - according to the known width of the output device.

L Produce a line feed at this point in the heading. Ie. Go to a new line.P Insert the current page number of the report at this point in the heading.D Insert the current system date at this point in the heading.T Insert the current system time.B Insert the value of the break at this point in the heading. Should be used in

conjunction with the BREAK-ON modifier, with the options : ‘BP’.

For example, the following heading statement :

HEADING “Customer Name & Address Listing ‘CL’ for customers within the ‘B’ postcode area ‘C’ as at ‘D’ Page No. ‘P’”

Used in conjunction with our customer name and address query listing that breaks on the change of postcode, may produce the following heading output :

Customer Name & Address Listing for customers within the 2300 postcode area as at 24 Oct 1995 Page No. 1

49


Define Procedures

Purpose of DEFQLPRCThe DEFQLPRC process is used to generate a real report process accessible through the menu system given a query report template. By generating a real report process, the following advantages are attained :

The user can easily change values or variables when running or executing the report process.

Values/variables that are entered may be validated ensuring more accurate reporting.Frequently run query reports may be generated into easily found menu options.Normal security profiles may be used on the generated report process.Selection criteria automatically built into heading if required.

How it WorksThe DEFQLPRC process uses an existing query language procedure maintained through the QLMNT process, as a template for building and generating a real report process that may be operated from the normal menu system. It is first necessary to get a working version of the query process, producing an example of the data that you require before processing it through DEFQLPRC.

When a DEFQLPRC record is created, the system searches through the nominated query process (maintained through QLMNT), locates any values or variables that are present within the query statement (depicted by inverted commas (“ ”) ), and allows the user to create user-defined tags for each of these values, and also to specify validation criteria for each of these fields. Therefore, it is possible for each variable within the query statement to become a “question” on the generated report screen.

For example, take the query statement we have used previously to produce a stock value report for a particular company :

SORT PRODUCTS.BALANCES BY GENERIC.PROD BY PRODUCT WITH COMPANY = “SS” AND WITH QTY.O/H > “0” BREAK-ON GENERIC.PROD PRODUCT PRODUCT.DESCRIPTION QTY.O/H AVG.COST TOTAL AVG.VALUE GRAND-TOTAL “Total Stock Value ‘U’” ID-SUPP

50


It would be nice to be able to easily vary the company that we run this for, to ensure the company code entered by the user is a valid company code, and make the whole report process easily accessible for any user in our organisation. This is exactly what the DEFQLPRC process can do.

Firstly, as described, the process searches through the query sentence looking for values enclosed in inverted commas. Therefore the process would pick up the company selection criteria, the quantity on hand selection criteria, and the grand total label, and present these to the user as possible tags on our report process. In this case, we would only want the company selection criteria to be a question on our report screen, so the other fields could be skipped and left constant (more on this later).

The process would allow us to specify validation criteria on the company input field, and we could also enter special help text and a selected “FiND” screen to accompany the input field.

The generated query procedure becomes a real process on the menu, where the process code is preceded by a “Z”. This just identifies the process as a user-defined process so as not to be confused with normal system processes. The generated process is automatically put onto a “USER” type menu, according to which module the report belongs under. This is determined by the filename used in the query sentence, and the System Code that this file is linked to.

It is worth noting that there are some limitations to the format of the ‘template’ query procedure, in order for DEFQLPRC to work correctly.

There must not be more than one value per pane. Ie. there should only be one set of inverted commas (“ ”) on any one line within the query process. The heading line should not span more than two panes.

Once the real process has been generated successfully using the template query procedure, the template is no longer required, and in fact may be deleted using the QLMNT process if you so desire.

51


A select list may also be included in the defined query procedure. When the procedure is run from the menu, the select list would first be executed, saved, and activated, and then the rest of the report would be produced using the pre-select list.

The first screen of DEFQLPRC is explained below :

DEFQLPRC Ver 5.00 Company Name 99:99:99 24 Oct 1999Screen : 1 Define QL user interface process 0 Username

Please Select : CRE/AME/REV/DEL/END [ ]

*1) Process Code This code becomes the process code on the menu, preceded with a ‘Z’.

2) QL Procedure Must be a valid procedure code as maintained through QLMNT.

3) Process Name Description of process.

4) Pre-Select Procedure Optional, but should be select list procedure, as maintained through QLMNT

Constant Tag------------------------------------------------------------P1 Displayed for reference only A user-defined tag may be entered if a P2 question is required on the input screenP3P4P5Field#to change or Sn or Pnnn or Cnnn[ ] (2 process screens)

As mentioned, a pane appears in the above window for each “Value” that is detected in the template query language process. The “Constant” that is displayed, is the example selection value that is present in the query sentence, and is shown for reference only. For example, when using the above query sentence for a stock value report, the constant appearing on pane 1 would be “SS”.

The default “Tag” that appears is the first part of the detected selection clause. Using the same example, the “Tag” displaying on pane 1 would be : WITH COMPANY =. This tag should be changed by the user to something that will be more meaningful to a lay person who may be running the report. A suitable tag may be : Company Code.

52


Other values that are detected in the query sentence will also display on separate panes in the above window. In this case, we do NOT want to generate tags or questions for these clauses, so the tag should be left blank.

If a tag is entered (thus telling the system that a question should be generated on the report input screen), a second screen will automatically be displayed asking for validation criteria etc. :

DEFQLPRC Ver 5.00 Company Name 99:99:99 24 Oct 1999Screen : 2 Define QL user interface process 0 Username

Field Definition for tag from previous screen inserted here as description

1) Minimum Length Minimum no. of characters to be entered in input field.

2) Maximum Length Maximum no. of characters allowed.

3) Field Type Describes format of input field.

4) Validation Min Max Specifies range of numbers Filename File to validate against Optional Is input optional ? 5) Help Code Used to specify your own help text for this field. 6) Find Code Gives user capability of using Find screen. 7) Default Specify a default to appear in input field. 8) Include in Heading Allows automatic insertion of selection criteria in

heading.

Field # to change or Sn [ ] (2 process screens)

53


Valid “Field Types” are :

0 to 9 This specifies a numeric data field, with this many decimal places.A An alphabetic field. Alphabetic characters allowed only.N An alphanumeric field. Alphabetic and numeric characters allowed.F Full ASCII field. Most printable characters allowed.D A date field. Usual date validations automatically carried out.T A field for entering a time.

“Validation” codes may be one of the following :

F Perform a file validation. The code entered must exist on the nominated file.R Range specification. Usually used with a numeric field. The minimum and

maximum range parameters are specified in subsequent fields.

Upon completely defining the query procedure by creating a record in the DEFQLPRC process, you will hit <Return> to file the record away. At this point you will see the real query procedure being generated, and at this point it will be inserted onto the appropriate menu. Make sure you update any security profiles you have in place before attempting to use the generated process.

If any changes are required to the completed process, you will probably need to make the changes to the template procedure using the QLMNT process. Once this is done, go back into DEFQLPRC, amend the existing user process, and regenerate it.

54


Special Procedures

A number of special type procedures are present on the main query language interface menu : QLMENU :

QLDUP Duplicate a Procedure. This process is very useful when creating a brand new query language process, if the process happens to be similar to an existing query process on the system. The QLDUP process creates the new record for you based on the existing query process, and you can then make any changes required via the QLMNT process. NOTE : The original query process is completely unaffected by the duplication.

QLIST List Stored Procedures. Produces a hard copy listing of the full details of query procedures entered through the QLMNT process. A range of procedures may be specified, so that a selected number are output.

DELIST Delete a Stored List. Select lists that are maintained and executed on the system, are also stored on the system indefinitely. If you do not require old select lists to be kept on the system, use this process to delete them one by one. Note : This process does NOT affect the original query procedure that generated the select list in the first place.

LISTLIST List Stored Lists. Produces a hard copy listing of all select lists that remain on the system. Details of which query procedure generated each list, and the date and time that the list was last executed are included on the report.

QLREINDX Re-index the Query Language System. Should only be run in the event of a system failure, and only when in contact with your software dealer. It re-indexes, or rebuilds the indexes association with the "FiND" facility in the query language menu.

55

table of contents - staminadownloads.stamina.com.au/manuals/r5trainingmanuals/ql... · web...

Documents