R&R Report Writer Version 9.0, xBase & SQL Editions New Release Enhancements and New Capabilities

Liveware Publishing is pleased to announce an exciting set of enhancements to R&R Report Writer!!

This is the first MAJOR update to R&R in almost five years, but Liveware has made up for lost time with substantial improvements for every R&R user. Developers building reports for their applications, end-users creating their own ad-hoc and production reports, and even casual R&R runtime users will all find something in this release to streamline their reporting activities.

For those who have purchased and implemented every update, and particularly Liveware’s Version 8.1 release licensees, you will be rewarded for your loyalty with a reduced upgrade price and a wide range of capabilities that will make R&R even more indispensable. For others who waited, this is the upgrade to buy since it contains so many unique and compelling ideas about reporting -- and ones you can use right away!!

Version 9.0 includes 5 new “modules” -- what we consider significant extensions of R&R capabilities -- and many convenience and usability improvements to open reporting to users at all levels.

The 5 new modules are (with page number in parenthesis):

Email Report Bursting & Distribution (2) Report Librariantm (4)

ParameteRRtm Field Prompting (9) FlexLinktm Indexing-on-the-fly (11)

Rapid Runnertm Runtime Control (16)

Among the other improvements, the most significant are:

Pervasive Band Color-coding (18) Page X of Y Functions (20)

Redesigned Join Dialog (21) Print Preview Band Identification (23)

Drill-down in Result Set Browser (24) Visual dBase 7 Support (25)

This document will summarize each of these modules and improvements and describe how they expand R&R’s capabilities to an ever-wider range of reporting needs. R&R xBase Edition Version 9.0 Enhancements Page 2 Email Report Bursting & Distribution

Since R&R Version 8, users have had the capability through MAPI (Mail Application Programming Interface) to send the results of a report export as an attachment to an email. R&R would produce the report and launch a MAPI-compliant Windows program (such as Outlook or Outlook Express, Lotus CC:MAIL, etc.). A new email screen would appear with the R&R export file name already as an attachment. The user would then add one or more email addresses in the “TO” box, and a subject and message, if desired.

This was a helpful, but two-step process that we felt could be enhanced. Therefore, we have designed a better and -- as far as we can tell -- unique approach to the problem of distributing reports via nearly ubiquitous email.

As R&R provided before, when one elects to “Export” the report (to one of the eight different formats--including HTML, RTF and worksheet), and one has a MAPI-compliant program installed on the computer running R&R, R&R will offer the option to “Send via MAPI”. Behind a new “Mail Options” button are several new options.

In the traditional MAPI export of the entire report, we have added an option to ‘Auto Send’ the attachment. R&R will build and place in your “Outbox” the email message and attachment to the party (or parties) listed in the “Send to” box. You can also add a subject line. With ‘Auto Send’ unchecked, you can still fill out the address and ‘Subject’, but R&R will launch your email program and allow you to add text to the message area prior to sending. R&R xBase Edition Version 9.0 Enhancements Page 3 This is a nice enhancement, but the real fun begins when you click the ‘Send Burst Report’ button:

This option activates the ‘Send To’ pull-down list for fields in your database. You can then select the field that holds the email address (or addresses) for the party to receive each PORTION of the report. The report is ‘burst’ into sections based on the ‘Burst Level’ field, which would be one of your designated grouping level fields. You can also add a text subject line, such as what is shown above.

R&R will take these instructions and go to work. Every time there’s a new value for the ‘Burst’ grouping level, R&R will create a new attachment for that group value and address it to the value for the field in the ‘Send To’ for that group. If you have 50 groups, R&R will send 50 separate emails with 50 unique attachments to the 50 designated addresses. If you have 100, or 1000, or 10,000, R&R will put them all in your Outbox, ready to go.

The capabilities this unleashes are enormous: automatic electronic statement delivery (to your customers, for example), customized email marketing messages and offers, address change email notices to all your vendors, budget reports sent to each department head, the possibilities are limitless.

Similar capabilities elsewhere using other tools require extensive programming, custom applications (often costing thousands for software alone). We can’t believe no other report writer ever offered this before!!

Due to the nature of MAPI interface, this option is available through the licensed Report Designer only, not runtime. This feature alone is worth the cost of a new license or upgrade since it replaces countless hours for so many people who have to prepare paper output, stuff envelopes and pay for postage to distribute customized correspondence, notices, statements, analyses, and on and on. R&R xBase Edition Version 9.0 Enhancements Page 4 R&R Report Librarian

As anyone who builds many reports -- or designs reporting systems for others -- knows, keeping track of those reports is difficult. Reports multiply out quickly as end-user take a report, make changes, then resave them under a new name.

Reports are files that can be stored anywhere on the user’s computer or network drives. Maintaining organization and references on all of these files becomes increasing cumbersome. After a while, remembering where to find a report, and what it was used for, becomes a burden.

But not any longer. R&R V9.0 includes the “Report Librarian” that automatically serializes and catalogs reports, then provides a front-end entry point to find and launch those reports. Librarian also does more: it builds a set of that allow multiple R&R users to just their own (and shared) sets of reports!! Librarian is a catalog from which all R&R users can run and modify their reports.

Librarian is the natural entry point for R&R. Each user logs in with a password (with rights controls), then can launch the R&R Report Designer from the main menu. Then R&R knows who is using it and assigns the correct ownership for any reports the user creates or modifies. If a shared report is modified by one user, the other user’s references to that report are updated automatically. R&R xBase Edition Version 9.0 Enhancements Page 5 Behind the ‘Catalog’ button is the Librarian database. Think of it as a card catalog you might find at a Library. It tells you where the volumes are stored, who owns them, when they were created etc.

Librarian users can also add descriptions and notes to their ‘Catalog Entries’, including a ‘Brief Description’ that displays in the window above to help the user locate that report they need but haven’t used in a while. The ‘Catalog’ report grid can also be resorted on the fly by report name, owner, date last modified, master table and ‘Report ID’ -- the serial number R&R V9.0 automatically assigns.

User IDs can be for people or for departments or functions. If you have a set of reports for the Finance Department, create a User ID ‘FIN’ with a special password for those people. That can be in addition to those individual’s User IDs. If R&R is installed on a network, everyone shares the Catalog and R&R updates it automatically each time a report is saved.

For a private Catalog, load an R&R license to the local computer and you’ll have a separate Librarian Catalog. This is a very good reason to put R&R on everyone’s desktop.

If that was all Librarian did, that would probably be enough for most software publishers, but not for us. Librarian automatically records in a database the key contents of the report. Clicking the ‘Detail’, ‘Relations’ and ‘Fields’ buttons above displays this information. R&R xBase Edition Version 9.0 Enhancements Page 6

Tabbed screens let users quickly reference important elements of the report. From summary grids -- similar to the Catalog grid -- for related tables and fields, user can find the details about how tables were joined to build the report, or what the formula was for calculating the commission amount for salesmen. R&R xBase Edition Version 9.0 Enhancements Page 7

Of course, the Catalog database and the related Librarian tables can be reported on using R&R Report Writer. Librarian includes several predefined reports (shown below) for commonly desired searches, but creative developers can use the data to determine, for example, which reports must be modified due to a change in the database of their core application.

Librarian also allows for version control and historical documentation of prior versions of reports (just do a “Save As” in R&R to assign a new serial number, even without changing the report name!!). There is also a free-text memo field to fully describe anything worth recording regarding the report. R&R xBase Edition Version 9.0 Enhancements Page 8 We think Librarian is so good, we wonder why Microsoft doesn’t have the same sort of thing for Excel, Word, Powerpoint and so on. Besides, if every file-based application program built a database of those files and their contents, there would be a lot more need for R&R!! (I wish I had it for Outlook to catalog my 30+ messages per day.) R&R xBase Edition Version 9.0 Enhancements Page 9 ParameteRR Fields and Prompting

It took some time for this feature to find it’s way into R&R, but we took our time and did it right!! For the greater percentage of reports out there, the person producing it must specify some controls or elements which will vary from run to run. These variables are often just a range of dates, or a selected customer code, or a percentage increase value for a custom calculation.

In prior R&R versions, one could edit a calculated field in Report Designer or ask a user to input a non-masked -- and therefore uncontrolled -- value in runtime. (This later option used the R&R RIPARAM() calculated field function and was strictly for experts.) Instead, most system developers who wanted to use R&R for reports had to write extensive code to receive and pass through to R&R key elements under the user’s control.

All of these features are still there -- and still work -- but ParameteRR fields are designed to augment and, in many cases, supercede RIPARAM methods and even source- application front-end programming. R&R V9.0 includes a new class of field item -- the ParameteRR field -- which is essentially a calculated field with some special properties.

Instead of specifying a formula, one indicates a constant value using standard R&R date, numeric, character or logical notation. (For example, curly brackets -- {} -- around a valid date.) Every record in the report is assigned this value so it can be used freely throughout R&R for formulas, total conditions and, especially, as query ‘Compared to’ fields. R&R xBase Edition Version 9.0 Enhancements Page 10 If user entry is desired when the report is produced, simply check the ‘Prompt at Runtime’ box. This will instruct R&R to present the screen below to accept user input for this ParameteRR field.

The report developer can also specify instructions to the end-user on what and how to set the ParameteRR field’s value, and R&R will validate the entry against an R&R validation formula to let the developer control, for example, the earliest and latest dates the end-user can specify.

Since the end-user will be able to view all of the prompted values at once, there is no need for an annoying series of prompts and a ParameteRR field’s limitations can be based on another’s value. The developer can even control the order in which the prompted ParameteRR fields are listed. Within Report Designer (though not in R&R runtime, naturally), there is even an option to store the most recently assigned ParameteRR value as the next default value.

All in all, we think this is an excellent implementation of the concept, and we even use it extensively in Report Librarian’s runtime reports to let the user control the print order and query. There’s no limit to what can be done with this feature, however. A clever developer can use ParameteRR fields to control nearly the entire report output, from conditional lines (to change the format or content of the report), to almost interactive drill-downs, the grouping variables, and so on.

Like so many of the features already in R&R, the presentation is calm, but the implications and possibilities run VERY deep. R&R xBase Edition Version 9.0 Enhancements Page 11 FlexLink Indexing-on-the-fly

On the surface, this new option -- which one can access through the new ‘Edit ’ dialog box (see description below) -- doesn’t seem like very much of a change. Nothing could be further from the truth, however, and this could possibility be the most important enhancement of R&R Version 9.0.

Why is FlexLink so important? To answer that question requires a greater understanding of how data tables are related in a theoretical sense, and then how one tells a report writer -- like R&R -- how those tables should be joined to create a result set. (Unfortunately, this change is primarily conceptual and within R&R’s processing algorithm, so visual manifestations from R&R V9.0 are not available. For a complete explanation and diagrams of all of these concepts, acquire a copy of both volumes of Relate & Report.) The short answer is that -- in R&R xBase -- to link two files together one must have a field in the starting table (a.k.a. the ‘controlling table’) with data that matches the index values in the related table.

In xBase tables (including Foxpro, Clipper, dBase, Rbase, Alpha 5 etc.), the developers define indexes on the data tables to speed the program’s internal processing. This includes routine processes such as being able to display information on the screen quickly, rather than having to search the entire, large table for the records to display. This same concepts applies to data processing portions of the program, such as posting procedures, calculations, automatic updates, etc. Some report writers -- especially R&R -- take advantage of the indexes defined for other purposes to search through the databases quickly and find records with key data in common between the tables. Some developers even add indexes primarily for later reporting, and we commend them for that.

As a primer, think of an index on a database table exactly like an index in the back of a reference volume, such as a listing of government agencies. If you had the need to find -- in that very thick volume -- key information about a particular agency, you would not want to look through the entire book to find it. You would check the index in the back, reference the page number, and turn to that page. That’s much quicker than scanning the entire volume.

Now suppose you wanted to find the names and years in office for all of the Executive Directors for each agency within the Departments of Interior, Health and Human Services, and Defense. If you attempted to use the index for that, it is unlikely that the printed index has entries for just the Executive Directors, and even less likely that it would be combined with the Department. Without that index, you’re stuck going through the entire volume to find what you wanted.

In the above case, the publisher of the volume cannot anticipate every use of the volume’s data and have a special index for that purpose. Indexes are ‘contextual’, meaning that they were designed to help in specific situations. A new situation means a new context and, maybe, the need for a new index.

For modern databases, we are not talking about a single volume. Most database applications have dozens of volumes (tables), each with -- perhaps -- the equivalent of R&R xBase Edition Version 9.0 Enhancements Page 12 thousands of pages of data. The number of potential contexts is astronomical. How many exactly is not that important; the fact remains that developers can predict some, but not all, and they are constantly changing. Being able to address new contexts, without re-engineering the entire application or returning to the developers for help, is the core purpose of any reporting tool.

The description of the problem laid out above is the summation of many of Liveware’s Principals , whose primary business has been consulting in this area for years. Clients come to us for help in putting their data to work -- often in new contexts that vary from administering a new, major contract to staying in closer contact with their customers.

Reporting tools have taken several approaches to this set of problems. The most common method employed is SQL -- short for ‘Structural ’ -- and R&R SQL Edition employs a version of that. R&R xBase takes a more direct approach by reading the data and indexes directly and allowing the report’s developer to control how tables are linked based on the data and index. R&R also allowed calculated fields to act as the controlling table’s field -- which was a very powerful option to addressing many contexts.

SQL does not let the developer select the index; it joins tables based on a predefined set of rules. Therefore, any new contexts must be addressed via the source application and this often results in expensive, time consuming, and resolution delaying developer for any new or unpredicted need. Therefore, for xBase tables we can unequivocally state that R&R xBase’s direct approach is superior since you can define reports for virtually any context that the data tables can address.

Prior to xBase V9.0, the one limitation was that the related table must have an index that serves the context for the report. Without an index, the report had to be built in multiple steps (with the required programming), new data processing programs were required in the source application to temporarily store or refresh some data prior to the report, or people would have to manually manipulate the data (usually with a spreadsheet) to produce the final result. R&R xBase -- prior to V9.0 -- greatly reduced the kinds of situations where an extra step applied, but the need for a predefined index remained.

The addition of FlexLink Indexing-on-the-fly lets us confidently remove the “virtually” from the last sentence two paragraphs above. Now the sentence would read “... you can define reports for any context that the data tables can address.” That’s a big change and that “any” is a major claim. In effect, you can go from raw data to final results no matter what using just R&R xBase.

We challenge anybody to give us your most difficult reporting problem. (It has to be a real problem, not ‘How many Angels can fit on the head of a pin?’) If you’ll buy R&R xBase V9.0, we’ll show you how it can be done.

This ability alone would be enough to make news, but the implications of FlexLink are even greater than that. FlexLink is a significant enhancement in several notable ways:

Streamlined report development Reduced processing time Relating non-related tables Compiling data across data sources R&R xBase Edition Version 9.0 Enhancements Page 13 We will examine each area below.

Streamlined Report Development

Even if an predefined index would do the job, a FlexLink index can do it better. How? By indexing a table to find just the records you need for the context, reports run faster and are simpler to define. For all SQL report writers and former R&R xBase versions, one had to link tables, then reduce the result set with the query (filter) to exclude records from the related table that were not of interest. This creates many extra steps and adds elements of complexity to the query, particularly, that are often unwelcome. FlexLink lets the report’s developer select only the records desired.

Calculations and totals are also simpler since one of the most commonly applied techniques to focus on segments of the result set was conditional totals. For these cases -- which often apply to dated records -- one would have to select all of the records from the related table then exclude all but certain ones from the total. This was necessary since applying the query to exclude unwanted records might also exclude the controlling table record from the one-to-many (scan) join.

Take, for example, a situation where we wished to total the overtime worked in each department for a particular month. If we wished to show a zero value for a department with no overtime, we could use the hours worked detail file and filter by month for overtime. A department without any would never appear in the report because all of its hours worked records would be filtered out if we looked just at overtime during the month. We would have to use a conditional total to sum just the overtime during that month for the grouping by department. Since the condition would never be true, the conditional total would produce a zero value for that department. To do so, however, would force R&R to read and select every hours worked record -- a lengthy, time consuming process. (See the description of reduced processing time below.)

Instead, we could use the department table as the controlling table in a scan join to the hours worked detail table, with a FlexLink index based on department, work category, and month. Since R&R already offers the option to create a blank related record when a match cannot be found -- as in this case for that department -- every department will be represented with at least one record in the result set. The total field is now just a regular total of the hours worked, with no condition. With R&R’s exclusive multi-scan join, this same could apply to an analysis for two separate months, or five, or twelve, or ...

Reduced Processing Time

Performance can also be improved dramatically, as the following recent example will demonstrate. A client requested a report to derive the insurance premium generated by each insurance agent. This would usually not be a particularly difficult task, but in this case each paid premium record could have two different agents receiving credit for it. That is, there was an Agent 1 and Agent 2 assigned in the record. Each agent earned a percentage credit for total premium based on the particular split and a fairly complex formula. Therefore, each premium record had to be counted under both Agent 1’s and Agent 2’s section of the report. R&R xBase Edition Version 9.0 Enhancements Page 14 Without getting into the boring details, we had to scan link from the agent table to the paid premium detail table twice (hence a multi-scan join), which by itself is a pretty fabulous R&R capability. We could do so in this case without creating a FlexLink index since the premium table had an index on which we could join the agent record to each premium record. The problem was that the premium table contains over 1,000,000 records!! Having each agent record find each of those one million plus twice made the report take over three hours to run -- on a fast computer. That was okay in the bad old days, but not good enough for today.

With a premium table FlexLink index based on agent 1 and another based on agent 2, that processing time, including building the indexes, was reduced to four minutes. (R&R could build each index in 45 seconds -- though results vary depending on the computer and formula for the index.) With this technology, very fast manipulation of even large databases is very possible right on the desktop, without any programming to temporary storage of that data just for reporting.

Relating non-related tables

Oftentimes, the tables on which we wish to report do not have any data in common. This happens in many circumstances, but often where separate databases have been built over a period of time and then must be thrust together due to an important event.

Suppose two banks merge. (I know, it will never happen in my lifetime, but humor me.) Each has its own customer and account databases and the two will continue to run independently for some time before the two can be combined. How can the bank produce consolidated statements for customers who had accounts at both?

Strictly speaking, the two databases do not have common data values on which to join them. One bank may use a customer code, while the other uses the customer’s social security number. With a FlexLink, these differences can be overcome easily since an index can define the context on which the tables can be joined. From a separate controlling table -- perhaps with just one record, we can define a FlexLink index using a key such as “ALL” on each table. We can then create a ParameteRR field (see above) also with a value “ALL”, and use the two to stack the two, separate databases into a single de facto table. They have been joined based on their actual context: they are really just one file in two separate places!!

(Note: Even if both had a social security number as the basis, we could join the two based on that because every account record for a customer in one table would link with every account record for that customer in the other. That’s not what we want!!)

This concept of creating a stack of tables on the fly -- with identical or different data structures; it doesn’t matter to R&R -- eliminates one of the most time consuming and expensive tasks any MIS department faces: consolidating data for reporting. Again, with FlexLink indexes, any context can be managed to turn raw data into results.

Of course, not too many banks use xBase databases for their customer accounts. They use big computers with mainframe or SQL-type databases. But at their core, all of this data R&R xBase Edition Version 9.0 Enhancements Page 15 is still in table form. Therefore, FlexLink can apply to them even though it is only available in R&R xBase Edition. You will understand how in the next segment.

Compiling Data Across Data Sources

FlexLink only works on xBase tables, and most tables are not xBase. These indexes need to be able to read the data where it is stored and make that index directly available to R&R. This is one reason xBase with it’s indexed tables are so much better for reporting than SQL data sources.

R&R SQL Edition (and Arpeggio before it) has always had the ability to extract data to create an xBase table. By combining that ability (and the purchase of R&R SQL V8.1) with FlexLink R&R xBase V9.0, one can extract any necessary data from any number of data sources (Oracle, SQL-Server, Sybase, Access, etc.) to xBase tables on a network or local computer. Fortunately, most newer computers have huge hard drives to store these tables, but the entire large table doesn’t need to be extracted for each report. R&R will only extract the fields and records instructed and can do so very quickly.

Of course, this takes significant power and storage on the local PC or network to pull it off. You might even have to spend $1500 on a computer. (Oops, you probably already have.) Granted, this is a multiple step process, but with Rapid Runner SQL (See Rapid Runner description page 16) these process can be put in a batch and commanded or scheduled to run as a single process.

(By the way, for those who will gripe that ‘this will create network traffic’, isn’t moving large sets of data for people to use the reason for the business network -- not downloading video clips. And the last time I checked, networks -- even the Internet -- was getting exponentially faster!!)

InIn ConclusionConclusion ......

In conclusion, sometimes knocking down one wall -- as FlexLink does -- can make a big difference. In this case, it was the last wall. Since it was a high wall, you may not have known it was the last one and that the promised land was just on the other side.

We believe this is the most significant development in databases in 30 years, and we will be seeking a patent on it. Others may not agree or even notice or care. They will continue to cling to the ways they know, as people refused to fly in favor of trains. But now we all fly and eventually FlexLink will be the way everyone will go. Imagine: raw data to final results without a single line of code. Always.

Non-stop. In a fraction of the time. At a fraction of the price. No rickety berths.

All Aboard!! R&R xBase Edition Version 9.0 Enhancements Page 16 Rapid Runner Runtime Utility

We liked Rapid Runner from the first minute we reviewed it. Written by a long-time R&R user to allow report end-users to better use the features of R&R’s royalty-free runtime, this program lets end-user batch reports into ‘sets’ for easier organization, then produce any or all of them by simply selecting and launching the report.

Rapid Runner also lets end-users schedule individual reports or sets for production, and assign printer designations, filter controls and many other variable elements of runtime reports. Rapid Runner is, therefore, the perfect companion program for developers to give their end-users who will not have access to a full Report Designer license, or simply prefer the runtime to streamline the reporting process for their end-users. R&R xBase Edition Version 9.0 Enhancements Page 17 We have been offering Rapid Runner as a bonus, or for sale, for both R&R xBase and SQL editions for a few months now. With R&R xBase V9.0, Rapid Runner xBase is now a standard module and part of the regular installation process. It is installed in the “RapRun” directory underneath the R&R directory and is available for use freely within the R&R licensee’s organization.

For those developers who wish to provide Rapid Runner to non-R&R licensees, license set of 25 end-user can be purchased for $250. This will allow developers to legally distribute Rapid Runner on up to 25 end-users’ workstations (outside the R&R licensee’s organization). If the end-user has or acquires a full R&R license, the Rapid Runner workstation installations are re-credited toward the 25. This means that Rapid Runner can be distributed to end-users for as little as $10 per workstation -- a small price to pay for this terrific utility.

The ‘Parameters’ portion of Rapid Runner refers to the RIPARAM() calculated fields and not the new ParameteRR fields described on page 9. R&R runtime will still present the ParameteRR dialog box when called from within Rapid Runner, but scheduling any set of reports for unattended processing that call for ParameteRR fields will suspend processing until the ParameteRR are accepted by the operator. Therefore, if a report is likely to be scheduled, use RIPARAM() calculated fields for which Rapid Runner will accept pre-entered values. Future enhancements to Rapid Runner will provide for pre-entry and acceptance of values for ParameteRR fields, but not in Rapid Runner for R&R xBase V9.0. R&R xBase Edition Version 9.0 Enhancements Page 18 Pervasive Band Color-coding

In R&R V8.1, we introduced the concept of color-coding bands to make the layout screen easier to understand. Bands are central to database reporting and any report writer, since they represent specific locations within the result set. The result set is central to every report, so recognizing the behavior of each band, and where it falls within the result set, is crucial to effective reporting.

In R&R V9.0, we have extended the color-coded band analogy throughout the program. While no capabilities have been added, we feel that this consistency will help novice and intermediate end-users more readily understand the banded concepts. For example, when adding another record band, the background for the band is the same color as presented in the elongated band area of the layout screen, as shown. R&R xBase Edition Version 9.0 Enhancements Page 19 Bands designations are used in many places in R&R, including specifics of the band to export, the grouping level on which totals are based, and even resetting of the page number on a group break. The total field edit screen has some very special behavior. ‘Running totals’ do not reach their full value until the end of the grouping level (or end of the report for grand totals), and therefore the colors for the band designations are for the group footer and summary band when the ‘Running’ type is checked.

Check the box for ‘Pre-processed’ and the colors change to the one matching the group header and title band. This is because a pre-processed total has its full value at the first record of the group (or first record of the report for grand totals). This simple change will make it easier to explain to novices the difference between these two totalling methods, and be a visual key concerning where the total might usually be placed in the layout.

This improvement is part of our continuing commitment to bring reporting to everyone, not just highly trained developers and power users. We have found that, with a minimal amount of training, anyone who uses the data casually can do some of their own reporting. R&R xBase Edition Version 9.0 Enhancements Page 20 Page X of Y Functions

This one has been a long time in coming and we appreciate the patience people have shown. R&R V9.0 has added the ability to define a calculated field that will instruct R&R to produce the entire report to memory, determine the number of pages, then assign the page count to that calculated field. This allows the report’s developer to include a legend that looks like ‘Page X of Y’, where ‘X’ is the actual page number of the report and ‘Y’ is the total number of pages in the report.

We could always do so, but the process had to be performed manually. We would run the entire report then fast-forward to the last page in the preview window and determine that page number. Then we would edit the layout to place that number at it’s appropriate location. Of course, this was impossible in runtime since this process required Report Designer to edit the layout. (An alternative method for runtime was nearly as cumbersome.)

Now, R&R will do all of this automatically. Create a calculated field as shown below, then place where you want it to appear. R&R xBase Edition Version 9.0 Enhancements Page 21 This function is not as simple and straight-forward as it seems for us to implement. Since it requires R&R to go through a, potentially, very lengthy step prior to generating the report again, R&R has to be aware that LASTPAGE() is included as active calculated field. Don’t define it and place it in the layout unless you really want R&R to go through that step. It will slow the presentation of the first page of the report significantly.

Also, other calculations cannot be based on this function, it takes no arguments (stuff inside its parenthesis), and it can’t be used for sorting, queries, grouping etc. It’s only use is in the layout, since any other use could create an invalid result due to circular reasoning. How many pages would actually be in the report if portions of it were based on the number of pages? To avoid possible problems with accuracy, don’t make the LASTPAGE() calc field in the layout a larger font than other items on the band line, and don’t have it stand by itself on a line either. The report will work, but the actual page count could be altered!!

Also added in V9.0 is the REPORTPAGE() function, which will return the actual page number in the report. This is particularly useful when page numbers have been reset on a grouping level and you need to determine exactly how many pages have been printed.

Redesigned Table Join Dialog Box

One of the most confusing aspects for beginners is linking (or joining) tables. There are several required and some optional elements to do so, and the selections and terminology are outside most people’s experience prior to learning report writing. Therefore, V9.0 includes a redesigned dialog box for linking xBase tables in an effort to make this step a little clearer. R&R xBase Edition Version 9.0 Enhancements Page 22 The steps have been numbered based on the most logical order in which most people would think about joining records from one table to another. The buttons to select the related table and related index have been moved to more appropriate locations, and the ‘Options’ button has been removed. (This latter button would reveal items that were not, in many cases, optional.) All of the defaults are the same as before and one can select them in any order, irrespective of the step numbering; so if you had your own way ...

The most obvious change is the addition of several graphic elements to represent various portions of the join and the dynamic method employed. The diagrams represented in ‘Relation Type’, ‘Character Match’ and ‘Failure Action’ are symbolic of how R&R will behave for the methods selected. It’s still complicated, but not as complicated as before.

Some might suggest that a ‘visual linking’ approach would be easier. We disagree. Most visual representations of any join tend to confuse beginners and intermediates, and may actually mislead them. A step-by-step approach makes more sense to us. By the way, Report Librarian (see description on page 4) includes a pre-defined report that summarizes how two tables have been joined in previous reports. This was included on purpose to help end-users learn from example on how to link tables. (Of course, the report’s context could make an important difference versus previous linking methods!!)

Also note the check box and button to define a FlexLink index (see description on page 11), here shown as ‘User Key’ -- and soon to be changed. Clicking the ‘Edit Key’ button brings up a formula definition box with fields from the related table. R&R xBase Edition Version 9.0 Enhancements Page 23 Print Preview Band Information

An extension of the band color-coding described on page 18 has been applied to perhaps the most important point where bands make a difference. When print preview is selected from the Report Designer or runtime, the band color is shown just outside the left and right margins of the page.

The clear cause and effect of placing items in the layout bands is now displayed during preview, making report design for both beginners and experienced users a little more intuitive. The impact can be quite exciting, however, as beginners learn to translate the page header as the red areas, the page footer as blue, record band as white, and so on. Turning report sketches into final reports is significantly more obvious, and these standard colors allow our support people to relay and receive visual clues to help end-users get the results they want.

Some would prefer that we also allow editing of the report format from the print preview screen. We think that’s a bad idea because the report as presented is often not representative of the banded layout. Fields’ ‘trim’ attribute, placement and properties of totals, and the potential for multiple columns and variations between pages renders making changes to the report layout here causing more problems that it solves. R&R xBase Edition Version 9.0 Enhancements Page 24 Drill-down in Result Set Browser

R&R V8.1 first included a feature that allowed end-users with Report Designer to see the data that R&R used to build the report: the result set. There was some capabilities to reorganize the data presented on the screen, but that involved mostly just rearranging the columns and, if desired, displaying just the records at the end of each group.

Version 9.0’s Result Set Browser (RSB) allows for immediate drill-down, sorting and grouping based on any field on the screen. Click (or right-click for grouping) the headings and the grid will adjust according to your selections.

There is also a new button to revert the table back to its original state. RSB also provides direct export to 5. R&R xBase Edition Version 9.0 Enhancements Page 25 Visual dBase Support

The old-time xBase patron, dBase, has been under a new publisher for a few years and they have been busy making modifications to the file and index structure. R&R V9.0 catches up (at least for now) with the major changes to Visual dBase 7.

dBase is not the powerhouse it once was, but since their story and ours are similar, we wish them well and will try to keep R&R xBase completely compatible with their innovations.

Written by:

Daniel Levin President, Liveware Publishing,Inc.

For more information on R&R xBase V9.0, check our web site: www.livewarepub.com or call 800-936-6202. Email inquiries may be addressed to [email protected]

R&R xBase V9.0 pricing information:

Single User New License $ 450 5-User New License 1,900 10-User New License 3,500 Upgrade from xBase V8.0, all SQL and prior (pricing is per seat) units 1-5 300 units 6-10 250 units 11-20 200 units 21+ 150 Upgrade from V8.1 ( xBase only -- per seat) Requires confirmation of valid license(s) units 1-10 150 units 11-20 100 units 21+ call for quote Rapid Runner Distribution License up to 25 workstation installations 250 over 250 workstation installations call for quote

Unit discounts not applicable to resellers. Regular reseller discount schedule applies. Upgrade from V8.1 not sold through resellers, but resellers can refer customers and we will drop-ship and provide an incentive payment.

‘Liveware’ is a registered service mark of Liveware Inc. R&R Report Writer is a registered trademark of Liveware Publishing, Inc. All rights reserved. This document may be reproduced freely. Screens shown are copyrighted and cannot be duplicated in software applications, except by permission.

Other product names referenced are registered trademarks of their respective publishers.