User Tools

Site Tools

Navigation:  Language Reference > 4 - Entity Declarations > View Structures >====== VIEW (declare a “virtual” file) ====== Previous pageReturn to chapter overviewNext page
label VIEW(primary file) [,FILTER( )] [,ORDER( )]
[JOIN( )
[JOIN( )


VIEW Declares a “virtual” file as a composite of related files.
label The name of the VIEW.
primary file The label of the primary FILE of the VIEW.
FILTER Declares an expression used to filter valid records for the VIEW (PROP:FILTER).
ORDER Declares an expression or list of expressions used to define the sorted order of records for the VIEW (PROP:ORDER or PROP:SQLOrder).
PROJECT Specifies the fields from the primary file, or the secondary related file specified by a JOIN structure, that the VIEW will retrieve. If omitted, all fields from the file are retrieved.
JOIN Declares a secondary related file.

VIEW declares a “virtual” file as a composite of related data files. The data elements declared in a VIEW do not physically exist in the VIEW, because the VIEW structure is a logical construct. VIEW is a separate method of addressing data physically residing in multiple, related FILE structures. At run-time, the VIEW structure is not assigned memory for a data buffer, so the fields used in the VIEW are placed in their respective FILE structure's record buffer.

A VIEW structure must be explicitly OPENed before use, and all primary and secondary related files used in the VIEW must have been previously OPENed.

Either a SET statement on the VIEW's primary file before the OPEN(view), or a SET(view) statement after the OPEN(view), must be issued to set the VIEW's processing order and starting point, then NEXT(view) or PREVIOUS(view) allow sequential access to the VIEW.

The VIEW data structure is designed for sequential access, but also allows random access using the REGET statement. The REGET statement is also available for VIEW, but only to specify the primary and secondary related file records that should be current in their respective record buffers after the VIEW is CLOSEd. If no REGET statement is issued immediately before the CLOSE(view) statement, the primary and secondary related file record buffers are set to no current record.

The processing sequence of the primary and secondary related files is undefined after the VIEW is CLOSEd. Therefore, SET or RESET must be used to establish sequential file processing order, if necessary, after closing the VIEW.

The VIEW data structure is designed to facilitate database access on client-server systems. It accomplishes two relational operations at once: the relational “Join” and “Project” operations. On client-server systems, these operations are performed on the file server, and only the result of the operation is sent to the client. This can dramatically improve performance of network applications.

A relational “Join” retrieves data from multiple files, based upon the relationships defined between the files. The JOIN structure in a VIEW structure defines the relational “Join” operation. There may be multiple JOIN structures within a VIEW, and they may be nested within each other to perform multiple-level “Join” operations. The VIEW structure defaults to a “left outer join,” where all records for the VIEW's primary file are retrieved whether the secondary file named in a JOIN structure contains any related records or not. The secondary file fields are implicitly CLEARed (zero or blank) for those primary file records without related secondary records. You can override the default left outer join by specifying the INNER attribute on the JOIN (creating an “inner join”) so that only those primary file records with related secondary file records are retrieved.

A relational “Project” operation retrieves only specified data elements from the files involved, not their entire record structure. Only those fields explicitly declared in PROJECT statements in the VIEW structure are retrieved if there are any PROJECT statements declared. Therefore, the relational “Project” operation is automatically implemented by the VIEW structure. The contents of any fields that are not contained in PROJECT statements are undefined.

The FILTER attribute restricts the VIEW to a sub-set of records. The FILTER expression may include any of the fields explicitly declared in the VIEW structure and restrict the VIEW based upon the contents of any of the fields. This makes the FILTER operate across all levels of the “Join” operation.


VIEWs have no THREAD attribute by syntax, but VIEWs declared in the local scope of a PROCEDURE or ROUTINE are treated as threaded. A VIEW declared in the global or module scope is treated as threaded if at least one joined FILE is threaded.

Related Procedures:


Customer  FILE,DRIVER('Clarion'),PRE(Cus) !Declare customer file layout
AcctKey    KEY(Cus:AcctNumber)
Record     RECORD
AcctNumber  LONG
OrderNumber LONG
Name        STRING(20)
Addr        STRING(20)
City        STRING(20)
State       STRING(20)
Zip         STRING(20)
Header    FILE,DRIVER('Clarion'),PRE(Hea) !Declare header file layout
AcctKey    KEY(Hea:AcctNumber)
OrderKey   KEY(Hea:OrderNumber)
Record      RECORD
AcctNumber   LONG
OrderNumber  LONG
ShipToName   STRING(20)
ShipToAddr   STRING(20)
ShipToCity   STRING(20)
ShipToState  STRING(20)
ShipToZip    STRING(20)
Detail    FILE,DRIVER('Clarion'),PRE(Dtl) !Declare detail file layout
OrderKey  KEY(Dtl:OrderNumber)
Record     RECORD
OrderNumber LONG
Item        LONG
Quantity    SHORT
Product   FILE,DRIVER('Clarion'),PRE(Pro) !Declare product file layout
ItemKey    KEY(Pro:Item)
Record      RECORD
Item         LONG
Description  STRING(20)
Price        DECIMAL(9,2)
ViewOrder VIEW(Customer)                   !Declare VIEW structure
     JOIN(Hea:AcctKey,Cus:AcctNumber)     !Join Header file
      JOIN(Dtl:OrderKey,Hea:OrderNumber)  !Join Detail file
       JOIN(Pro:ItemKey,Dtl:Item)         !Join Product file

See Also:





view_declare_a_virtual_file_.htm.txt · Last modified: 2023/09/08 08:27 by carlbarnes