Data

Data Location

The user has the option of where data is located, either locally or on a remote server. That includes application data as well as system (VPM) data (data dictionary system files can be local or remote). Also, different installations of the same application may require the data to be located differently, either locally or on a remote server. Since an application is normally prototyped with only local data, VPME has the ability to “point” a particular installation of an application to its data. What this means is that for every local view used in prototyping, VPME can be told whether to continue to use that local view or its equivalent remote view after installation. This ability to “point” an application to its data is also needed when prototyping the application and when you want to start testing using remote data. To accomplish this, VPME has a Remote View Properties table that is always kept locally and holds the name of local views, the names of the databases that contain their equivalent remote views (of the same name), which view should be used, and other remote view properties. This table is edited through the Data Manager/Builder.
Any VPM function that deals with data can handle both local and remote tables since the user has the option as to where each individual table resides. To do this VPME uses views to access data, even when dealing with local tables. That way, the same code can be used regardless of where the data is located by simply switching between local and remote views. For example, to get a validation rule for a field VPME does not open the DD2 table and SEEK the field’s record. VPME uses a view of the DD2 table to retrieve the field’s record.
The VPME documentation will describe how to determine where tables should reside, which means locating data on the optimal platform to achieve maximum performance. Criteria used in determining where data should be located include file size, how often a table is changed, security requirements, etc..

Data Security

The VPME documentation will document the issues involved in the data security that is provided by the server-side database. One issue is the assigning of the user rights needed to create and access server data. Another issue to document involves putting sensitive data on the server to take advantage of the database’s security features.

Data Integrity

On the server side, the remote database has the ability to enforce Referential and Entity integrity.
On the client side, the VPME functionality works with both local and remote data (DD, Audit Trail, as well as the tables being updated).
If the VPME RI routine is being run for a record in a local table or view, it works as it does now in VPM 6.0. It will only cascade updates and deletions to local tables.
For remote views, the user can determine if the VPME RI routine or the server side database RI should be used. That determination is made on the Remote page of the Data Builder/Manager. When the VPM routine is used, it can cascade updates and deletions through both local and remote data.

Remote Data Creation

The VPME documentation will describe how to use the Upsizing Wizard to create remote data.
The VPME documentation will describe the different ways that an application can be prototyped:
Create remote views to existing remote data.
Prototype with local views/tables that will eventually connect to existing remote data.
Prototype with local views/tables and upsize to create remote data in SQL Server or Oracle.

Remote View Creation

Remote views can be created in the DBC but information about them is not stored in the VPME DD. Since each remote view is created to be equivalent to the associated local view, information in the DD for the local view that was used while prototyping is used when using the remote view.
Connections need to be created to gain access to remote data. The VPME documentation will provide instructions for the creation of connections. The VPME documentation will also describe the use of multiple connections vs. shared connections.
Remote views should not be set up which use pessimistic buffering, which is not supported by SQL Server. This was true with SQL Server 6.x. We need to check to see if this is still the case in SQL Server 7.

Primary Key Generation

To provide for the possibility that the DD2 table might reside on the server side, we have changed the way our Default Value routine accesses the DD2 table. It no longer accesses the DD2 table as a local table.
Databases like SQL Server have the ability to generate surrogate keys when the record is saved.
Keys can also be generated on the server side for remote views by creating a stored procedure in the remote database that will return the key value.

Reindex/Pack Tables

The Reindex/Pack Tables routine will only work on local tables. The Reindex/Pack Tables form does not show in the tables list those local tables whose associated remote view is currently being used (checks Remote View Properties table).

Validation

Server side databases have record and/or field validation rules that are enforced at save time. If these are used, the VPME error handler will properly handle a validation rule failure. The VPM validation routine can handle access to remote data since any table may be located on the server side.

Uniqueness Check

The VPM 6.0 uniqueness check works when the ISA (InitialSelectedAlias) is a view by opening the view field’s source table and performing the check on that table. This is done because the view cursor may not contain all records in the source table. This will not work for remote views since we can’t simply open the source table. For remote data VPME relies on the use of candidate tags, which perform the same function, only at save time instead of at validation time.

Audit Trail

The VPM 6.0 Audit Trail routine is tied to the RI routine so that it can include cascading updates and deletions. This was changed in VPME so that changes to a remote view cursor record are still recorded, even though our RI routine is not run because RI is being handled on the server side. This does not record the cascaded updates and deletions that take place on the server side, only the changes or deletion of the view cursor record.
If the RI is performed on the server-side data by VPME’s RI routine, then audit trail records can be created for cascading updates and deletions. The VPME RI routine has the ability to work with both local and remote views rather than just local tables and views.

Forms

Switching Between Local and Remote Views

Forms have local views in their DataEnvironment, regardless of whether they are using local or remote views when run from within the application. The user must add a line of code to the BeforeOpenTables method of the DE that calls a routine that will change local view property values in the DE, re-pointing the views to their equivalent remote views. The remote view property values will come from the Remote View Properties table.

Working with Subsets of Records

Forms can limit the number of records that are contained in the view cursors. To do this, a form can be displayed that allows the user to enter record selection criteria. That information is then used to REQUERY() the remote view. This form is similar to our Find form where the values entered are used to find a single record or multiple records. Like our Find form, if multiple records are found the List form will be presented so the user can select the record to initially be displayed.

Toolbar Controls

The standard toolbar works just fine with remote views. If the ISA remote view cursor contains a single record, the appropriate navigation, Find, Locate, etc. buttons are disabled. If the cursor contains multiple records, the controls work as they do in VPM 6.0 on whatever records are in the cursor.
VPME has an alternate Find form for entering record selection criteria. This Find form is used whenever the ISA is a remote view and the form is either first brought up or the Find button is clicked.
The Group Delete functions on the ISA table or view cursor. If the ISA is a view cursor that contains only a subset of the records in the source table, it will only delete from that subset of records.

Related Forms

Our Related Forms functionality works with local views and remote views. However, remote views will usually only contain a small subset of records whereas local views usually contain all records. When it is determined that the form is a Related Forms child form, VPME assumes that the child view has a parameter on the FK field and uses the parent record’s PK value to REQUERY() the child view.

Start With Find

VPME has a new form property, lStartWithFind, that when .T. (the default) will cause the Find form to come up automatically when the form is first activated. This functionality will be disabled if the form is coming up in a Related Forms situation.

Reports

Switching Between Local and Remote Views

Reports have local views in their DataEnvironment, regardless of whether they are using local or remote views when run from within the application. The user must add a line of code to the BeforeOpenTables method of the DE that calls a routine that will change local view property values in the DE, re-pointing the views to their equivalent remote views. The remote view property values will come from the Remote View Properties table.

Working with Subsets of Records

Since parameterized views may be used in reports, the VPME documentation will document how a record selection criteria entry form would be used in a report so that the value(s) entered into the form would be used as the parameter(s) when the view cursor is created. This basically involves running a record selection criteria form from the BeforeOpenTables method of the report’s DE and putting the entry(ies) from the form into a memory variable(s) that will later be used as the view’s parameter(s).

Miscellaneous Functionality

Data Manager/Builder

All data handling functionality has been changed into calls to methods of the Application Object. This was done to provide for the possibility that any of the tables that are used might reside on the server side. All Data Manager/Builder tables have been converted to views, which may be local or remote. Consequently, all tables may reside on the server side.
The Tables/Views pageframe contains a page whose caption is “Remote”. The page allows for the editing of remote view properties that are stored in the Remote View Properties table.

Error Handler

The VPME error handler handles errors generated by the remote database.

VPM Security

VPM’s security implementation has not change. However, it was changed to use local or remote views to allow for the access of remote data if the security tables reside on the server.

Business Rules COM Object

VPME creates a Business Rules automation server (COM object) that can contain the methods and properties used when enforcing business rules. Through the New Project form, the user can identify whether the Business Rules class library should be built into the project or put into a separate new project (for creation of an automation server).