You are here: Development Standards > OSAS Standards > Data Files > xxTB - Tables

# xxTB - Tables

The xxTB file contains application-specific tables, one of which is the options and interfaces for the application. You can store other information that fits the columnar structure of this file in the xxTB file. It resides in the application data directory. Create it at the BASIC prompt or with the _define utility program. Maintain the options tables through the Resource Manager Options and Interfaces function. Maintain other tables through the File Maintenance Tables function for each application.

Table record names can be 8 characters long. The table record key is the table record name and the company ID and is always padded on the right to 8 characters.

When you need a table record, code the program to first read the table with the current company ID. If the record is not found in the table, change the company ID to a space and try the read again. If the table is not found with this read, the table cannot be found. A table-not-found condition may or may not be an error condition.

The system uses some tables for storage of data between programs. Because these table names are not documented for end users, users do not know that the tables are stored in the table file. These tables need not follow the naming conventions outlined above. They most often use the terminal ID in the record key (for example, the USERxxxx record in Report Writer) and may show up in the maintenance key window in the Tables function. They are not usermodifiable.

Company Data

Most data files in OPEN SYSTEMS Accounting Software are named consistently using four to seven character names. The first two letters are the application ID. For company-specific data files, the third and fourth letters identify the data file; the fifth, sixth and seventh are the company ID. For data files that are not company-specific, the third and fourth (and in some cases, fifth) letters identify the data file.

WARNING: Data file names must not conflict with program names. You must not use the first four characters of a data file name in a program name unless the program name is 8-characters in length or contains and extension (such as .PUB). For example, the JOBSxxx file and Billing Summary Report program JOBSR will conflict when company R is used. The Software Development Utilities contains an audit report you can run to detect possible data/program file conflicts.

Adding Data Files to an Existing System

You can easily create data files for an add-on or enhancement in a system in which the base application's data files already exist. Simply merge the new data files’ information into the xxDATA.yyy file. Then instruct the user to run the Data File Creation function in Resource Manager for the application. The user should respond with NO to the Overwrite Existing Data Files prompt to make Resource Manager create only the data files that do not exist−the new data files.

Modifying Data Files

Keep these things in mind when you consider modifying existing data files:

- There are some reserved fields in existing data files (see the application's File Descriptions manual to find out which ones they are).
- You can redefine existing fields to carry more data or to accept more values.
- You should not add new record types to existing files. Adding multiple record types into one file is a non-normalized standard of storing data, and causes some limitations when using ODBC.
- You can create new data files. A new data file may require new BASIS and GENERAL Report Writer dictionary information, and new sample data. You must also update the xxDATA.yyy file to create the new files.

Scratch/Temporary Files

Sort/scratch files are named SCRT.xxx, where xxx is a unique sequence number stored in the global variable STBL(“SORTSEQ”).

Names of temporary files must be unique to ensure that the functions that use them work in multiuser and MDI environments.

In versions before 7.0, scratch files were named SCRTxxx, where Txxx represented the terminal identifier FID(0). For example, a scratch file created on terminal T100 is named SCRT100.

Record Length

OSAS generally uses standard record lengths. Performance improves when you keep records exactly on 64-byte boundaries. If a boundary is close, extend the record length to reach the boundary.

Many files have unused room at the end of each record. Avoid using this room by adding variables to the end of the file’s IOLIST when making modifications. If you do, you must change the IOLIST for every program in every application that reads or writes to the changed file. OSAS applications write entire records; if you do not modify all applications that touch the file, the unmodified applications erase whatever information the modified applications put into this space. Instead, make use of the ISV variables at the end of most OSAS data files for your data.