OpenEdge Data Management: DataServer for Microsoft SQL Server

Initial Programming Considerations
2–14
The following ABL code example retrieves data from a view:
OPEN QUERY query-name FOR EACH view-name.
REPEAT:
GET NEXT query-name.
DISPLAY view-name.
. . .
END.
If a view has a unique combination of columns, you can simulate a unique index using the Data
Dictionary. You can then access a view that has a simulated unique index just as you do a table;
that is, you can scroll backward and forward, and update, create, and delete data. See the
“Modifying field-level information” section on page 7–33 for information on how to do this.
Some views are the results of joins and contain data from more than one table. You can also
provide unique index information for these views if they have a unique combination of columns.
You can then scroll backward and forward, but the MS SQL Server data source does not allow
you to create or delete data in a multi-table view. You can, however, update data in some views.
The DataServer does not support access to columns in views that are the results of aggregates
or computations unless the calculated column has a name associated with it. You assign a
specific name to a calculated column when you define a data source view. For example, the
following SQL statement names a computed column in a view definition:
create view view-name as select cc = count(cust_num) from customer
You can also access those views by using the RUN STORED–PROC send–sql–statement option to
send a SQL statement to select the data from the view. In this case, you can access the view
without adding index definitions for the view to the schema holder.
Although the schema holder contains your views, the Data Dictionary’s SQL View Report
does not list them, nor can you access them through the PRO/SQL menu functions.
Triggers
Triggers are code that an application associates with a data source object and an action. For
example, writing a record might cause code associated with that object or action to execute. The
DataServer allows an application to execute triggers for both OpenEdge databases (including
the schema holder) and MS SQL Server data sources. In an application that executes both types,
the OpenEdge trigger (CREATE, FIND, UPDATE, DELETE) executes first. If processing an OpenEdge
trigger results in a data source request, the DataServer passes the request to the MS SQL Server
data source and the operation (INSERT, UPDATE, DELETE) executes.
Triggers for OpenEdge databases and MS SQL Server data sources are independent of each
other. A data source trigger that rolls back does not affect OpenEdge triggers. Defining a trigger
in OpenEdge does not create a data source trigger definition. An OpenEdge trigger that rolls
back does so independently of the data source’s transaction scope. Note, however, that although
triggers for OpenEdge databases and MS SQL Server data sources are independent, they might
affect each other based on the kind of transaction your application is executing. For example,
ensure that triggers running in both OpenEdge and at the data source do not dead lock on the
same record access.