ABL advantages over 3GL for database updating

Posting on behalf of Mary.

ABL BUFFERS versus SQL TUPLES

In a 3GL, SQL reads a record type into a tuple via SELECT. The tuple may be a row in a sqlresultset, or an element of a collection. If the SELECT is a join, all levels of join will be represented by a single tuple or row.

The ABL reads a record type from the database into an ABL BUFFER via FOR EACH / FIND/ QUERY. If there is a join, the record types in the join are read into separate BUFFERs for each level of join.

What is the difference between an ABL BUFFER and a tuple or row in a

sqlresultset or collection?

SQL TUPLE

The user must do his/her own start/stop commit/rollback of transactions.

The user must keep track of possible multiple copies of a single record type. Updating may be risky in this environment.

The user must manage the multiple levels of join in the tuple or row.

Language support is limited to traversing the sqlresultset or collection with FOR EACH, MOVE next/prev, etc.

The tuple is independent from the database -- column/row mapping is required to get updates back to the database.

ABL BUFFER

The ABL BUFFER is automatically transactional. By default, all transaction logic is built-in but can be overridden.

The ABL BUFFER points to the memory version of the database record. If more than one ABL BUFFER reads the same database record, it will be linked with all other BUFFERs pointing to the same record, and only 1 copy of the record will ever exist in memory. This makes updating safe.

Multiple levels of join are automatically managed by way of the multiple BUFFERS for a join.

The ABL BUFFER is supported by a rich language which allows among other things:

FOR EACH (is automatically transactional, no data mapping)

FIND (can upgrade locks, determine change status, etc)

BUFFER-COPY (can do name-matching and mapping for disparate record types)

BUFFER-COMPARE (same thing as copy)

UNDO (automatically backs out all scoped buffer operations)

The ABL BUFFER knows all metadata info for its record type and has direct knowledge of the database involved. Updates go automatically to the database with no need for mapping or special syntax other than simple assignments: order-date = today. Data can be referenced directly from the buffer: DISPLAY order-date.

What about DataSets?

Recently, DataSets and Service Data Objects (SDO's) have become important in 3GL's. These are caches of data in tables with explicit join information for related tables. They deliver joined data from a SQL process in the very convenient way that the ABL has always delivered it: in separate tables as opposed to a single wide matrix with all levels of join represented in each row.

The DataSet object is associated with a database data-source, and then is populated with a FILL method. Once populated, the dataset can be transformed easily to and from XML. This makes it an ideal parameter for all manner of application API's, especially Web services, allowing easy caching of data to a remote client.

If the data in the DataSet is updated on a remote client, before-images can be kept during change-tracking, so that later the changes can be delivered back to the database with optimistic locking.

ABL DataSets (ProDataSets) versus 3GL DataSets (.NET DataSets and Java SDO's)

The main difference between ProDataSets and 3GL DataSets is that the ProDataSet is built on the ABL BUFFER. It therefore has all the benefits of BUFFERs listed above. All the rich ABL language is available to access/copy/compare/update the BUFFERs in a ProDataSet.

The ProDataSet also has a sense of currency when it is being managed within a single process. If a FOR EACH (of a QUERY or FILL) or FIND on one or more BUFFERS within a dataset has positioned those BUFFERS at a particular set of records, they will remain so when the ProDataSet is passed as a parameter by reference anywhere else in the application.

The currency of the buffers in a ProDataSet means that when for example, an event is fired during FILLing or when the dataset is passed to a viewer during browsing, the code in the event or viewer will see all the current records in all the levels of join automatically.

--

Mary Szekely

Fellow