Bound Databases

Bound Databases

Binding a database ensures that the MicroKernel enforces the database’s defined security, referential integrity (RI), and triggers, regardless of the method you use to access the data. The MicroKernel enforces these integrity controls as follows:

•

When you define security on a bound database, Btrieve users cannot access it.

•

When you define security on an unbound database, Btrieve users can access it.

•

When no security is defined on a bound database, Btrieve users can access the data files as follows:


Bound File’s Constraint	Level of Access Using Btrieve
RI constraints defined	Users can access and do anything within RI constraints
INSERT triggers defined	Read-only, update, and delete access
UPDATE triggers defined	Read-only, insert, and delete access
DELETE triggers defined	Read-only, insert, and update access

If more than one constraint exists on the bound file, the access level follows the most restrictive constraint. For example, if a file has both INSERT and UPDATE triggers defined, then you have read-only and delete access.

Note: Even if you do not bind your database, Pervasive PSQL automatically stamps a data file as bound if it has a trigger, has a foreign key, or has a primary key that is referenced by a foreign key. Thus, a data file may be part of an unbound database, but be bound. In such cases, the MicroKernel enforces integrity constraints on the file as if it were part of a bound database.

The dictionary and data files in a bound database cannot be referenced by other named databases. Also, bound data files cannot be referenced by other tables in the database.

When you create a bound database or bind an existing database, Pervasive PSQL stamps every dictionary and data file with the name of the bound database. Also, Pervasive PSQL stamps every data file with the name of the table associated with that data file. In addition, when you add new tables or dictionary files to the database, Pervasive PSQL automatically binds them.