The Database Access Control record is used to give administrators special powers. Administrators can force users to log off, restrict logons, and broadcast warnings or other messages, for example, in preparation for system maintenance, data loading, or shutdown. Screen records help in creating security rules for restricting user access to particular user interface objects in the web site (menus, buttons, forms, links).

If there is no activity from a user for a specified amount of time, the client is automatically logged off to prevent unauthorized access or wasted resources. Every web page is classified as to whether logon authentication is required to access the page. Secured pages cannot be accessed without valid logon, even if the complete URL of the page is entered into the browser. (This prevents unauthorized access, for example, using the "History" feature of the browser.)

The bulk of the Base One sample web site code is devoted to building a secure, flexible, database reporting system. Users can create their own custom reports, save them, share them with others in their User Group, produce high-quality printouts, and export them to Excel or Word. The application allows users to set the selection criteria for a database query, which is used to produce a table of results.

Advanced reporting features demonstrated include:

• Reporting on large volumes of data, broken into multiple web pages
• Report linking, with "drill-down" navigation between reports
• High quality printing
• Saving report specifications for future use
• Sharing saved reports with other users
• Controlling report access based on user privileges

Reports can be linked. The sample web site demonstrates how each detail line (row) can be hyperlinked, so that clicking a row takes the user to another related report, run with the appropriate selection criteria. There can be series of such steps, i.e. user can "drill-down" from one report to next logical report, and the lists of selected items are preserved where they apply to the new report.

When a report is presented as an HTML page, using the “Print” menu of the browser invariably gives poor quality results:

• a fragmented look caused by wrapping lines and improperly split images
• extra junk that comes from printing the entire screen, such as URLs, hyperlinks and all other objects on the page
• formatted report headers, page headers, and footers are not available
• if the report spans more than one page, another Print command has to be issued for each page

When a user generates a report by setting all of the required query parameters, that report specification can be saved for reuse. This means the user can run the report again by just a single click, without having to provide values for the parameters.

When a user initially works on a report specification, it is only temporary. The user can run the report, but upon exit these temporary report specifications are discarded. Temporary new reports are named "New Report 1", "New Report 2", etc., stored in temporary records. 

Users can name any temporary report, which then automatically turns it into a saved report. When a report specification is saved, the user provides a report name and optional explanatory remarks. Note that only the report specification is saved, not the data. The data is always obtained afresh from the database every time the report is run.

It is also possible to copy one type of report to a different type of report. This operation copies as much of the list of selected items as applies to the new report. The new report specification can be automatically pre-filled with the original selection criteria, so the user can both run this new report and also change the list of selected items.

The supplied Report record types (database tables) provide a structure that is easily extended with new report types and additional user-specifiable selection criteria. This allows interesting "canned" (i.e. commonly used) reports to be added to the web site.