PVRQ Version 1.32 - Release Notes March 30, 2001 ------------------------------------------------------------------------------ A) Reporting Enhancements A.1 - Added options to the configuration screen to control how PVRQ accesses tables. These options can result in dramatic speed improvements. A.2 - The external key data of files with an embedded data dictionary and external keys can now be used in reports. A.3 - Added an option to the print screen to allow blank lines to be printed. Most blank lines are normally suppressed. This new option may be useful on a multi-line report where one of the lines has been set to print blanks, to provide a double-spaced report. A.4 - Added an option to the print screen to suppress the printing of all page headings, including headers and footers. A.5 - Added options to the header/footer screen to suppress the printing of individual report heading components: company name, report title, page number, date and time. There is also an option to suppress all page headings. A.6 - Added the ability to use custom date formats. This option is controlled by a checkbox option on the configuration screen, which defaults to exclude custom dates. To use custom dates: 1) the check box option on the configuration screen to exclude custom date types must NOT be checked 2) define a global function to be used to unpack this data type. The function must be named: FN%UP4$(year_digits,packed_date$) PVRQ will automatically call upon this function to unpack any report columns you define as "custom date". Your function should format the date as you want it reported, such as MM/DD/YYYY. PVRQ always uses the number 4 for the year_digits. 3) define a global function to unpack the date into YYYYMMDD format. You may need to reference this function in filters, sorts and formulas that use custom dates. The function should be named: FN%UP8$(year_digits,packed_date) 4) These functions must be defined prior to running PVRQ. You can also define the function as part of a start-up user-defined procedure (see the user guide for more information regarding user- defined procedures). A.7 - Increased the maximum number of lines for a multi-line report from 9 to 25. Also increased the maximum number of data fields that may be printed on a report from 40 to 99. B) Configuration screen changes B.1 - The PVRQ serial number can now be changed when entering the activation key on the configuration screen. This allows users of a demo version (which has a generic demo serial number) to easily install a licensed serial number when they decide to purchase the full product. B.2 - The list box that shows the list of available fonts is now initially hidden. A new button has been added to the screen to allow the user to change the report font. Obtaining the list of available fonts is slow on some systems, so this change will make accessing the configuration screen noticably faster because the font list isn't obtained until it is required. If the user presses the change font button, only then will the program obtain the list of available fonts and display them in the list box. B.3 - Added a checkbox option to use embedded dictionaries when present in a data file. In most cases this box should be checkmarked to ensure best performance. In FACTS installations, and other installations where embedded dictionaries have been defined that contain numeric fields as part of strings (ie. the type has been set to "number" and the format mask is set to "Substring" or "Last substring"), this option should NOT be checkmarked because these fields are returned as strings instead of numbers by the ProvideX interpreter. B.4 - Added options to control how tables are accessed when an embedded dictionary is not present, or when the option (B.3) described above is not checkmarked. These options are: 1) Build IOLIST from data dictionary. PVRQ will read the data dictionary files and build an IOLIST for the table. String fields will be the length specified by the dictionary, ie. trailing spaces are not trimmed. If the record string is shorter than expected, some string fields will be shorter than specified by the dictionary. This option provides very good speed performance. 2) Build IOLIST from data dictionary, and pad strings. This option does what #1 above does, then pads all string fields to their full size, even when the record string is shorter than expected. This option is much slower than #1, and should rarely need to be used. It was added only to allow for records that are shorter than what is specified by the data dictionary. 3) Manually parse each record. PVRQ will read the table using READ RECORD, then manually extract each field based on the data dict- ionary files. This option is much slower than #1. C) Other changes C.1 - Added an option to display users currently using PVRQ. This button option is on the administrator's control panel. The button also appears on the report selection screen when the current user has administrator privileges. C.2 - Corrected a problem in printing of graphics where the body of the report was not being moved down the specified number of lines. C.3 - Corrected a problem where some long user id's were not being recognized as valid users. C.4 - Corrected an error 42 that was occuring when printing a report that referenced a file having an multi-dimensional data element (occurs clause). C.5 - Corrected a problem that was preventing permanent activation on non- Windows systems.