HP 3000 Manuals

Differences in Accessing Databases [ Up and Running with ALLBASE/SQL ] MPE/iX 5.0 Documentation


Up and Running with ALLBASE/SQL

Differences in Accessing Databases 

TurboIMAGE and ALLBASE/SQL both offer a variety of tools for accessing
databases, and both provide techniques for concurrency control, to
regulate access by more than one user at a time.

Interactive Access 

TurboIMAGE interactive access is through Query/V, which lets you find
database entries and report on them using the Query command language.  In
ALLBASE/SQL, the interactive interface is known as ISQL, which uses
Structured Query Language (SQL) to access the database and display query
results.

For sophisticated reporting, Business Report Writer supports both
TurboIMAGE and ALLBASE/SQL databases.

Programmatic Access 

A major difference between TurboIMAGE and ALLBASE/SQL is in the
programmatic interface.  TurboIMAGE uses a set of intrinsics which you
use in application programs to open databases, obtain locks, retrieve
data, unlock data items and data sets, and close a database.

ALLBASE/SQL uses embedded SQL programming.  You insert standard SQL
statements in an application program, then you preprocess the program to
convert the SQL statements into valid procedure calls in the language you
are using.  The converted code is compiled and linked with a library of
ALLBASE/SQL routines.  The use of embedded SQL means that you can
prototype and test your queries in ISQL before running them in an
application, thus saving development time.  Embedded SQL also includes a
set of dynamic commands which let your end users perform ad hoc queries 
through your applications.

4GL 

You can use ALLBASE/4GL as a programming tool to create applications that
can access both TurboIMAGE and ALLBASE/SQL databases--even at the same
time.  Simply define the appropriate data sets and/or tables in
ALLBASE/4GL's dictionary, then create screens and menus.  As a
fourth-generation tool, ALLBASE/4GL lets you avoid tedious and repetitive
coding.

Differences in Concurrency Control 

Concurrency control is needed to protect the consistency of a database
when it is in multiuser operation.  TurboIMAGE permits concurrent access
through a mechanism known as access mode.  You choose one of the eight
modes of access as you open the database.  These modes offer a wide range
from very restrictive single user exclusive access to multiuser access
with updates permitted by different users.  Some access modes enforce the
application's locking of data sets; others do not.

ALLBASE/SQL uses two DBEnvironment access modes:  SINGLE and MULTI user
mode, which you set when you create the DBEnvironment.  (You can also
change modes using SQLUtil.)  In addition, tables have an access mode,
which you specify when you create them.  Tables may be PUBLIC,
PUBLICREAD, or PRIVATE, as follows:

PUBLIC          may be read or updated by anyone who has authority to
                CONNECT to the DBEnvironment.

PUBLICREAD      may be read by anyone but only updated by one user at a
                time.

PRIVATE         may only be read or updated by a single user at a time.

Locking Mechanisms 

In TurboIMAGE, you use the DBLOCK intrinsic in certain access modes to
provide locking at the database level, the data set level, or the data
item level.  Locking must be explicitly requested by the user; it is
required for concurrent updates.  You can request locks conditionally in
TurboIMAGE, which means that the call returns if the lock request fails.

ALLBASE/SQL provides automatic locking for all data manipulation
commands--reads and writes.  Locking is unconditional, and it applies at
the level of the table or the data page; row level locking is not
supported.  You can also use the explicit LOCK TABLE command.  Further,
you can specify an isolation level, which determines the kinds of locks
obtained by ALLBASE/SQL. Isolation level applies to transactions, which
are bounded by the SQL BEGIN WORK and COMMIT WORK commands.  Four
isolation levels are possible:

RR      Repeatable Read.  The strongest locks are used to assure
        continuity of data from one read to another within the same
        transaction.
CS      Cursor Stability.  Weaker locks are obtained and released as
        needed during the scan of a particular database table.
RC      Read Committed.  Weaker locks are obtained but released even
        sooner during the scan of a particular database table.
RU      Read Uncommitted.  No locks are obtained.

For complete information about these isolation levels, refer to the
chapter "Concurrency Control Through Locks and Isolation Levels" in the
ALLBASE/SQL Reference Manual.

Concurrency control is complex, and no exact mapping between the two
systems is possible.



MPE/iX 5.0 Documentation