Transcript Note 4

DBT544
DB2/400 Advanced Features
• Level Check Considerations
• Database Constraints
• File Overrides
• Object and Record Locks
• Trigger Programs
Level Check Considerations
• Have you noted that when you create an externally described file, the
system assigns a unique level identifier to each record format in the
file.
• When you compile a program that uses the file, the compiler includes
the format- level identifiers in the compiled program.
• Use the Display File Description (DSPFD) command to display the
record format-level identifiers for the file.
• Use the Display Program References (DSPPGMREF) command to
display the record format level identifiers that were used when the
program was created.
• If they are the same, you do not need to recompile the program to
avoid a level-check error.
• Only changes to the following will affect the record format-level
identifier:
– Record format name.
– Field names.
– Length of the record format.
– Number of fields in the record format.
– Field attributes such as length and decimal positions.
– The order of the fields in the record format.
– You can change field attributes such as highlight, underline, reverse
image, and colors without recompiling programs. Constants such as
headings or labels can be added, changed, or deleted.
Object and Record Locks
• To see how objects and database file records are being locked
• WRKBOJLCK (Work with Object Locks)  To see the locks held on
an object by all jobs [for members use F6]
• DSPRCDLCK (Display Record Locks)  To see the records in a
physical file that have locks on them
• DSPJOB (Display Job)  To see all external locks for a job, both
those already held and those for which the job is waiting
Level Check Considerations
• Have you noted that when you create an externally described file, the
system assigns a unique level identifier to each record format in the
file.
• When you compile a program that uses the file, the compiler includes
the format- level identifiers in the compiled program.
• Use the Display File Description (DSPFD) command to display the
record format-level identifiers for the file.
• Use the Display Program References (DSPPGMREF) command to
display the record format level identifiers that were used when the
program was created.
• If they are the same, you do not need to recompile the program to
avoid a level-check error.
File Overrides
•
File overrides  used to temporarily [and dynamically] change the attributes (i.e.,
the definition) of a file during program execution
•
Purpose  so that you don't need to create permanent files or programs for every
combination of attributes your applications might need.
OvrPrtF File(Report) +
ToFile(QPrint) +
Copies(&Copies)
Call HLLPrint
•
Because of the override, program HLLPrint opens file QPrint rather than file Report
and generates the specified number of reports
File Overrides [SQL/400 access]
•
A file override  a way to redirect file access or to specify a runtime change to
one or more file-access properties.
•
You specify a file override by executing an OvrDbF (Override with Database File)
CL command.
•
File overrides are commonly used with applications that use built-in HLL I/O
statements to access physical and logical files; however, you can also use file
overrides with applications that use SQL to access tables and views.
File Overrides
• Common uses of the OvrDbF command  to redirect an unqualified table
name from its default collection (or library) to a different one.
• With the OvrDbF command, you can explicitly direct the system to resolve
a name to a particular collection:
OvrDbF File( Customer ) ToFile( AppDta/CustName )
Call Pgm( ListCust )
Override Scope
• When you execute an OvrDbF command, you can specify one of the
following values for the OvrScope parameter to indicate the override
scope:
– *CallLvlA
• *CallLvl (call level) scope means that the override is in effect for any tables
or views subsequently opened by the same program or any program at a
higher call level
– *ActGrpDfn (the default scope)
– *Job
Override Scope
•
The DltOvr command deletes overrides. The following command deletes the
override for the Customer table:
DltOvr File( Customer )
•
Instead of a specific table name, you can specify *All to delete all file overrides.
Database Triggers
•
In genearl A Trigger  is a condition that causes some procedure to be
executed.
•
A trigger program  is a program that UDB/400 calls when an application
program tries to insert, update, or delete a database record.
•
You write and compile a trigger program just as you do any other HLL program and
then use the AddPfTrg (Add Physical File Trigger) command to associate the
trigger program with a table.
•
UDB/400 supports six trigger conditions for a table:
– before insert
– before update
– before delete
– after insert
– after update
– after delete
Database Triggers
•
The AddPfTrg command associates a trigger program with one or more of these
conditions for a physical file
• The advantage of trigger programs  you can be sure the actions of the
trigger program occur regardless of which application or system utility tries
to change the table.
• Use trigger programs to block table inserts, updates, and deletes that don't
meet specified conditions, to propagate table updates to other tables, or to
log changes to specific columns.
• Trigger programs provide an important tool to extend UDB/400 capabilities
for enforcing database integrity and providing other database functions.
•
Implementing triggers is a two-step process:
– You code the trigger program
– and then associate it with one or more trigger conditions for a table. (The same trigger
program can be used for multiple conditions or even for multiple tables.)
– Suppose you've written a trigger program named CustChk to make additional integrity
checks before permitting a row insert or update and you want to associate the trigger
program with the Customer table.
AddPfTrg File( AppDta/Customer )
TrgTime( *Before )
TrgEvent( *Insert )
Pgm( AppExc/CustChk )
RplTrg( *Yes )
AddPfTrg File( AppDta/Customer )
TrgTime( *Before )
TrgEvent( *Update )
Pgm( AppExc/CustChk )
RplTrg( *Yes )
– You can specify either *Before or *After for the TrgTime parameter.
•
A trigger program that's called before file changes occur can perform actions
before UDB/400 checks other constraints, such as foreign key constraints.
•
Because a trigger program can itself perform file I/O, a before trigger program can
take necessary actions to ensure that the constraints are satisfied.
•
When you specify TrgTime(*After), UDB/400 calls the trigger program after the file
is updated
Uses of Triggers
• Three possible uses of a trigger program:
– to enforce constraints (validity checks) that can not be directly
implemented with other UDB/400 features
– to log changes to specific records or fields
– to propagate primary key changes in a “parent” file to the foreign key(s) in
“dependent” file(s)
DB2/400 Advanced Features
•
•
•
•
•
•
•
•
•
•
•
•
Level Check Considerations
Database Constraints
File Overrides
Object and Record Locks
Journals, Journal Receivers, WRKJRN, Applying and Removing
Journaled changes
Trigger Programs
Distributed Database
DDM, DRDA, ODBC
Database Security
Backup and Recovery
Check Constraints
UDB and Binary Large Objects, User Defined Fucntions, User
Defined Data Types and Data Links
L
i b
r a
r y
F i l e
M
e
R
m
e
b
e
r
c o r d
F i e l d