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