MUNECA Y MANO

Figure 3. In this example, a relation has been established between the customer_id field in the Customer table and customer_i index of the Orders table.

Removing tables, views, and relations

To remove a table or view from the Data Environment window, right-click the table or view and select Remove. You may also select the table or view, and then select DataEnvironment | Remove from the main VFP Menu bar.

To remove a relation from the Data Environment, click on the line that represents the relation and press the Delete key. You may also use this method to delete a table or view.

Browsing a table or view

You may browse the data in any table or view opened in the Data Environment rather easily.

Select the table or view you want to browse and select DataEnvironment | Browse from the main VFP Menu bar. You may also right-click on the table or view and then select Browse.

The Properties window

The standard VFP Properties window can be used to access the Properties, Events, and Methods of the Data Environment itself as well as the tables, views, and relations within the Data Environment. If the Properties window is not already active, you can display it by selecting Window | Properties Window from the main VFP Menu bar. You can also right-click on an open area in the Data Environment window and select Properties.

The Properties window may also be displayed from the VFP Command Window. Press Ctrl-F2 to activate the Command Window. Then, enter

“ACTIVATE WINDOW properties” (without the quotes).

Many of the Properties, Events, and Methods (PEMs) used in the Data Environment are the same PEMs used throughout Visual FoxPro and should already be familiar to you. In this section, I’m only going to discuss the PEMs that are unique or special to reports.

‡

The Data Environment PEMs

These PEMs relate to the overall Data Environment.

• AfterCloseTables event: This event is fired after the report is finished running and after the tables and views are closed. You can use the method associated with this event to do any special cleanup. It’s especially handy if you’ve used the BeforeOpenTables method to open some tables that need to be closed.

• AutoCloseTables: This property determines whether the VFP Report Writer automatically closes the tables and views defined in the Data Environment. The default is true (.t.). If this property is false, the AfterCloseTables event is not fired.

An example of when you wouldn’t want the tables or views closed is when the program or form that calls the Report Writer needs to access the tables or views when the report is finished.

• AutoOpenTables: This property determines whether the VFP Report Writer automatically opens the tables and views defined in the Data Environment. The default is true (.t.). If this property is false, the BeforeOpenTables event and the OpenTables method are not fired. An example of when you wouldn’t want the tables and views automatically opened is when the program or form that calls the Report Writer has already set up the tables and views.

• BeforeOpenTables event: This event is fired before any tables or views are opened by the Data Environment. This event is extremely useful when you need to open some tables or views yourself, when you need to change the path of the tables or views, or when you need to build data on-the-fly.

• CloseTables: This method closes the tables and views defined in the Data Environment. It’s run automatically if the AutoCloseTables property is true.

However, you may also call this method yourself if needed.

• InitialSelectedAlias: This property determines which table or view is made current when the Data Environment is loaded. This is very important, as it determines which table or view is the main table or view driving the report.

• OpenTables: This method opens the tables and views defined in the Data

Environment. It’s run automatically if the AutoOpenTables property is true. As part of this method’s default behavior, it fires the BeforeOpenTables method just before it opens the tables.

• OpenViews: This property determines which views are opened by the OpenTables method. The valid choices are 0-Local and Remote (the default), 1-Local Only, 2-Remote Only, and 3-None.

The order in which the OpenTables method and the BeforeOpenTables event fire is a little confusing. First, the BeforeOpenTables event fires and processes the custom code within the OpenTables method. Then, just before the OpenTables method exits, it processes the custom code in the

BeforeOpenTables method. Lastly, control is returned to the OpenTables method,

‡

which, in turn, opens any defined tables and views. Use NODEFAULT and DODEFAULT() within the OpenTables method if you need to circumvent this native behavior.

The cursor PEMs

These PEMs relate to tables and cursors defined in the Data Environment.

• Alias: This property determines the alias used to reference this table or view. The default is the same name as the table or view.

• BufferModeOverride: This property determines the buffering of the table or view.

The valid options are 1-Use Form Setting (the default), 3-Optimistic row buffering, and 5-Optimistic table buffering. You may be asking, “What in the world does this have to do with reports? I’m reading the data, not writing the data!” Usually, this is a true statement and this property would be irrelevant. However, it’s possible to write to the data through the use of User Defined Functions within your report.

• CursorSource: This property identifies the name of the table or view of this cursor.

This is a read-only property.

• Database: This property identifies the database that this table or view belongs to.

This is a read-only property.

• Exclusive: This property determines whether this table is opened exclusively. For tables, the default is false (.f.). For views, this is a read-only property that is set to true (.t.).

• Filter: This property is used to enter an expression to apply a filter to the table or view. For example, enter COUNTRY = ‘USA’ to limit the Customer table to only those records that have a value of “USA” in the Country field.

• Name: As tables and views are added to the Data Environment, they’re named cursor1, cursor2, cursor3, and so on.

• NoDataOnLoad: This property determines whether views are loaded with or without data. A true (.t.) tells the Report Writer to open the view without retrieving any information. The default is false (.f.) for views, and this property is not applicable to tables. An example of when you would set this property to true is when you need to prime some variables for a parameterized view.

• Order: This property identifies the index to set for this table or view.

• ReadOnly: This property determines whether updates are allowed to the table or view. The default is false (.f.).

If the report is defined with a Private Data Session, do not put code in the Init method of a cursor. Reports do not have a DataSessionID assigned to them, so there’s no way to be assured the code will run in the correct Data Session. Therefore, it’s suggested (by Microsoft) that you place any Init code in the Init method of the Data Environment instead of the Init method of the cursor.

‡

The relation PEMs

These PEMs relate to the relations defined between tables and/or views.

• ChildAlias: This property identifies the alias name of the child table in the relation.

It’s a read-only property.

• ChildOrder: This property identifies the index tag used on the child table.

• Name: As relations are added to the Data Environment, they’re named Relation1, Relation2, Relation3, and so on.

• OneToMany: This property determines whether the record pointer remains on the same parent record until the child table has moved through all the corresponding records. For example, when a Customer table is related to an Order table, it’s a one-to-many relation because there may be many records in the Order table that relate to a single record in the Customer table.

• ParentAlias: This property identifies the alias name of the parent table in the relation. It’s a read-only property.

• RelationalExpr: This property identifies the expression used to relate the parent table to the child table.

Note: If the report is defined with a Private Data Session, do not put code in the Init method of a relation. Reports do not have a DataSessionID assigned to them, so there’s no way to be assured the code will run in the correct Data Session. Therefore, it’s suggested (by Microsoft) that you place any Init code in the Init method of the Data Environment instead of the Init method of the relation.