Mike Hanson - The Power of Views and the New View Manager

Posted September 1 1997

Printer-friendly version

Views have power for both hand-coders and Designer users. While the templates, employing the View Manager, handle views for you, understanding them is important to optimizing your use of those templates. They are used behind the scenes by all templates that access files. Hand-coders benefit from using views because views can obtain results not normally attainable and provide speed without worrying about the details of the file(s).

Views are abstract representations of a file or group of files, but manage keys and relations without explicit knowledge (i.e., worry) on your part. Yet without detailed knowledge of the file(s), you can do complex file access. Mike cited an example of using a view in a report reducing processing time from several minutes to a few seconds.

When you declare a view, except for SQL drivers, all file fields are included in the view. It is, therefore, a good idea to use the Project statement to select the fields you are specifically interested in. This is what the templates accomplish on the Hot Fields tab (and automatically including all key fields). You may filter or sort (Order) views using the syntax we are all used to or expression (which can include functions - both standard Clarion functions and user-written functions).

Because the view does not know anything about the file(s), you can obtain different results by starting in different places, i.e. declaring different files as the Primary file for the view. That is, although you know that two files exist in a parent-child relation, not only can either file be the primary file for a view, different results are obtained when different files are the primary file of the view. For example:

ViewCustomer  VIEW(Customer)
                  JOIN(INV:CustomerKey,CUS:CustomerNumber)
                    Project(INV:Date)
                  END
                END

will give all customers, whether there are invoices for that customer or not, and the Invoice Date for each invoice, if the customer has any invoices. Turning them "Inside-Out" and using the Invoice file as the primary view file:

ViewInvCust   VIEW(Invoice)
                  JOIN(CUS:InvoiceCustomer,INV:CustomerNumber)
                    PROJECT(CUS:Name)
                  END
                END

will contain records only for those customers who actually have invoices.

Notice that these view declarations do not refer to keys. The view will automatically seek appropriate keys and, when possible, use them. Otherwise, it will loop through the entire file.

Obviously, views are flexible. But there is much more flexibility. Views can be filtered on an expression (all variables and functions must be bound, for the compiler's sake). Views can be filtered right in the view declaration:

ViewCustomer  View(Customer),Filter('INV:Date > Date(1,1,1997)')

or, dynamically, at runtime:

VIEW{Prop:Filter} = 'INV:Date = Today()'

and you can even change this property during file processing (Mike wasn't too sure why one might want to do this, but you can do it).

Hand-coders will benefit from knowledge of Views, though Mike felt that using the C4 view manager might constitute overkill. Designer users need to understand views because they drive browses, reports and processes both in CW2.00x and C4.

Article comments