RELEASE of the record

WayneFrank

WayneFrank

Member
In a progress program, I have a situation where I am making a TEMP-TABLE. What it looks like is happening is that if only one TEMP-TABLE record is produced, that one record does not show up in later processing when the program accesses this temp table..

If I change to program to do a RELEASE of the record, then the one record shows up in the processing.

And if there is more than one record generated in the temp-table, the RELEASE is not necessary.

My question is: Does this make sense? Has anyone else encountered this situation?

Progress Version 9.

Thanks, Wayne
 
That makes perfect sense. It's a question of buffer scope - there are no transactions on TEMP-TABLES.

If you use the default buffer that comes with the TEMP-TABLE then the scope is the whole procedure in which the TEMP-TABLE is defined. You may have noticed that you can't define a TEMP-TABLE in an internal procedure or function. Changes on a TEMP-TABLE record get written to the TEMP-TABLE either at the end of the buffer scope ( that's when the procedure goes out of scope ) or when you explicitly tell it to write them back with the RELEASE statement.

You should think about using a defined buffer in an internal procedure or function to modify the TEMP-TABLE. Using defined buffers is always good practice when updating records, be they TEMP-TABLES or database tables. That way you have better control over buffer scope and for example when the table triggers fire as when you use the default buffers that are associated with 'em.

But that's IMHO - of course.
 
Sometimes using temp-tables and additional buffers can cause unexpected errors.
For example (Progress 10.1C04):

Code: 
DEF TEMP-TABLE tt NO-UNDO LIKE _file.
DEF BUFFER bf FOR tt.

FIND FIRST _file NO-LOCK.

CREATE tt.
BUFFER-COPY _file EXCEPT _FILE-NAME TO tt.

/* RELEASE tt. */
/* FIND FIRST tt. */
/* tt._FILE-NAME = "xx". */

FIND FIRST bf. /* ERROR: ** FIND FIRST/LAST failed for table . (565)*/
Unless explicit transaction or one of commented statements happens record is not available. Progress waits until transaction ends (DO TRANSACTION: create, buffer-copy, END) or "buffer transaction" ends (either RELEASE tt or FIND FIRST tt) or all of primary key fields are assigned.
This error happens when you create record (using default or named buffer) without filling primary key fields (like buffer copy with excluding primary key components) and then you try to access (find / for each) record with another buffer.
 
Just to be clear:

Under a transaction I understand a transaction on the database server.

There are no such transactions involved when changing TEMP-TABLE and/or variables. Nevertheless, the default error behavior of blocks is an UNDO. Depending on the point of view one could also see this as some sort of transaction mechanism. The NO-UNDO option defines whether this default error behavior ( the UNDO ) will kick in and undo the changes made within the block in which the error occurred. Whereas a "real" transaction will undo all changes made within the transaction scope. In case of an error within a block within the "real" transaction scope, the whole transaction will get an error and will be rolled back regardless whether the changes were made within or outside the block.

The buffer scope of the borrowed default buffer associated with the TEMP-TABLE is always the procedure itself. In an earlier post I did not made myself too clear when changes made to the buffer will be assigned to the TEMP-TABLE record:

  1. At the end of the buffer scope: For the borrowed default buffer this will be when the procedure goes out of scope. For a defined buffer it will be the end of the block ( usually internal procedure or function ) in which the buffer was defined.
  2. You explicitly code the RELEASE statement.
  3. You create a new record in the buffer.
This may seem like a theoretic discussion but since it's one of the basics of how the 4GL works it's good to know when you need to find the root cause for your logic not working as you expect it to.


Heavy Regards, RealHeavyDude.
 
You must log in or register to reply here.
Back
Top