Why link Textbases?

The main reason that you link textbases together is to avoid having to replicate information that is common to many records or to more than one textbase. By storing the common information in one textbase, you can reference it from other textbases.

Deciding which textbases to link is an important, but not difficult, decision. Typically, you use linking to model a many-to-one relationship between different types of records.

In the simplest case, a many-to-one relationship can be accomplished with multiple entries in a field. For example, many phone calls to a particular customer can be logged in a single field in the customer record. However, if you need to track separately the date of the call, the person initiating the call, and a summary of the discussion, you should use linking instead. Create a record in a separate textbase for each call, and link these records back to the customer. Then it is easy to track how many call were made in a particular week, how many were made by a particular staff member, and so forth.

You can link a textbase to one or more other textbases to access the combination of information that you need. By linking textbases, you can conserve disk space and reduce or eliminate duplication of effort. You can access information from several textbases at once, but you only have to maintain the information in the textbase from which it originates. For example, a patron’s name and address can be stored in one textbase, but can be seen, searched, sorted, and printed from any record which links to it. If a patron’s address changes, you can edit the record in the Patrons textbase, and any linked records will show the new address.

Linking is done dynamically, by matching information in a field common to the linked textbases. If both textbases contain the same information in the specified field, a link is make for a particular record, and information from the secondary textbase becomes accessible. The textbase that contains the Link field is called the ‘primary textbase’. The other textbase is called the ‘secondary textbase’.

Part of the decision about linking textbases is to determine which textbase should be the primary and which should be the secondary. You will be able to edit information in the primary textbase, so make the primary textbase the one that you will be working in most frequently. Which accessed from a primary textbase, the secondary textbase information is available for reference only. Therefore, the secondary textbase should be the one that contains relatively stable information. To change information in a secondary textbase, open it directly.
Content integrity

You may want to protect your textbases from unwanted access. For example, you do not want library users to be able to edit records in your online catalog. One way to protect textbases is to place them in a directory to which users have read-only rights. Another option is to use a Silent password to keep library users from seeing confidential information and from editing the textbase structure or records. You may also want to assign various passwords to library staff, for certain purposes.

There are three types of passwords: Master, Field Access and Silent. The master password protects the structure of the textbase. Only the person who knows the master password can edit the textbase structure and perform all operations. The field access passwords provide different right for one or more users. This password can hide fields, make some fields read-only, and prohibit editing of validation and substitution lists. The silent password comes into play when you want to protect a textbase without requiring that every user have a password. When a textbase has a silent password, anyone can open the textbase, but the textbase structure cannot be edited and fields will be protected per your specifications.

Validation settings define what kind of information will be permitted in a field when a record is added or modified. You can specify validation rules for fields in a textbase. Applying validation is optional. The purpose of validation is to screen information being added to the textbase during data entry, import, and batch modifying operations to ensure consistency and reduce typographical errors. If information does not meet the validation criteria, DB/TextWorks informs the user and does not permit the change to be made (unless content validation overrides are allowed). For example, validation can ensure that a valid date is entered in a Date field, or that a key field is never left empty.