Obsydian Release 3.1 Highlights

Targeted availability: June 1998

Obsydian 3.1 contains enhancements to ODBC (SQL) access for generated applications as well as the availability of the Obsydian for Windows NT and Oracle generator.

ODBC 

SQL SELECT WHERE <string> operator in AD

Obsydian allows developers to use the POSITION and FETCH operators to specify data access in the Action Diagram. These statements provide the specification for SQL SELECT statements when the application is generated for the ODBC or NT BackOffice platforms. The syntax of the POSITION and FETCH operators constrain the functionality of the generated SQL. For example, the developer would not have a way to specify the upper bound to a selected set in order to better optimize the application.

Obsydian 3.1 will introduce the SELECT WHERE <string> operator to the AD. With this operator, the Obsydian developer will be able to specify the actual WHERE clause that will be generated into the SQL SELECT statement. The <string> parameter may be hard coded or include AD variables. This will allow Obsydian developers to create more flexible applications, by providing better control of the SQL code. Allowing the developer to use techniques such as enabling  application to dynamically determine the columns to be used in the search criteria.

New Function added to OBASE (to support implementation of WHERE clause described above)

The new function is based on the existing "Get Sequential" behavior and is scoped to a new entity "Entity with SQL data".

This function dynamically builds a SQL WHERE clause based on the field in the restrictor and positioner variables. The resulting set will be smaller and will contain only the desired rows.

In addition, instead of programmatically processing any selections specified by fields in the
Equal, Not equal, Less than, Less than or equal, Greater than, Greater than or equal, Contains and Starts with variables, the function includes these selections in the generated Where clause.

Improved Get Sequential processing

The processing in the initialization of the OBASE Get sequential function has been modified so that it is able to dynamically decide which Position instruction to use. The decision is based on the fields and values in the Restrictor and Positioner variables. This new functionality will improve the performance of ODBC access functions.

Where possible, the function uses the more efficient Position EQ Restrictor instruction, but will use the existing Position GE Positioner if necessary.

The generated code will examine each field in key set of the view from the Positioner variable. If any field is not also in Restrictor and does have a value, the Position GE Positioner instruction is used. In all other cases, the Position EQ Restrictor will be used.

Multiple Concurrent Database Connections

Obsydian 3.1 will allow developers to associate a logical connection name with each database. This allows the generated application to maintain multiple physical connections to ODBC data sources. Obsydian developers will be able to reducing network overhead and will be able to reduce the amount of Action Diagram code needed to handle database state information.

ODBC 3.0 Support

Obsydian 3.1 includes support for ODBC 3.0.

• There are new source code objects for the recently introduced ODBC API's.
• Support for generating Right Outer Joins when they are specified by the developer ( the 2.0 standard allowed ROJ's to default to Left Outer Joins )
• A change in nomenclature, renaming ODBC Options to ODBC Attributes.

Obsydian for Windows NT and Oracle

The Obsydian for Windows NT/BackOffice generator creates windows clients which call NT Server programs that access SQL Server through ODBC. While implementation of ODBC produces the best performing database access for SQL Server, the same server functions can use ODBC to access other relational DBMSs such as Oracle.

Obsydian 3.1 includes the capability to generate servers that access the Oracle DBMS through the native Oracle Call Interface (OCI). Applications generated for Oracle will benefit from faster database throughput and a more robust architecture through the elimination of the intermediary ODBC code layer.

Access through OCI to an Oracle database will be achieved through the Obsydian runtime DLL.

The diagram above illustrates. the Obsydian runtime calls into a database layer when access to an RDBMS is needed. The database layer manages the access to the target database through the OCI or ODBC layer, as appropriate.