Temp-tables are effectively database tables that reside in client memory with potential overflow to disk on the client machine. (The point at which the overflow occurs is based on the setting of the Buffer Size for Temporary Tables (-Bt) startup parameter.) You use temp-tables when you need temporary storage for multiple rows of data during a session, and when you need to pass data between OpenEdge sessions on different machines, such as between a server and a client using the application server. Temp-tables exist only for the duration of the procedure that defines them or, at most, for the duration of a OpenEdge session. Note that the temporary database is managed entirely on the ABL client, with no database server involvement. (For application servers, this means that the temporary database resides on the application server.)

A temp-table is private, visible only to the session that creates it or receives it as a parameter passed from another session. Because, temp-tables use the same support code that actual database tables use, you can take advantage of almost all database features that do not require persistence of data and multi-user access to data, for example defining indexes for fields in the temp-table.

Temp-tables are a wonderfully useful construct in ABL, and you can apply them to different types of programming problems. Fundamentally, you can think of them as providing two basic capabilities:

  1. Temp-tables allow you to define a table within a session that does not map to any single database table. A temp-table can be based on a database table, to which you can add fields that represent calculations or fields from other tables or any other type of data source. You can define a temp-table that is not related in any way to any database table, that is used for example to store calculations requiring a two-dimensional table of data that is then used in a report or in some other way.
  2. Temp-tables allow you to pass data between OpenEdge sessions. When you begin to build distributed applications, which you can do with your own application server statements in ABL, you allow your application to be divided between procedures that are on the same machine with your application database and procedures that execute on a client machine that produces the user interface and interacts with the user. You use the application server to communicate between client sessions and server sessions. When a client procedure needs to get data from the server, it runs an ABL procedure on the server that returns data as an OUTPUT parameter, or that accepts updates from the client as an INPUT parameter. You define these parameters as temp-tables that you pass between the sessions. You cannot pass record buffers as parameters between sessions, so whether you need to pass a single row or many rows together, you do this in the form of a temp-table as a parameter.

Because the client session is sending and receiving only temp-tables and not dealing directly with database records, your client sessions can run without a database connection of any kind, which makes it easier to build flexible and efficient distributed applications. Temp-tables are therefore a fundamental part of any distributed application. Writing your own ABL statements to use the application server is beyond the scope of this book, but in these topics you will write a procedure that passes a temp-table as a parameter to a user interface program, so that you can begin to get a feel for what it means to design your procedures for this kind of separation of user interface from database access and business logic.

ABL ProDataSets

ABL ProDataSets are ABL objects that extend the capabilities of temp-tables. In essence, a ProDataSet is an "in-memory database" that is filled with a set of related records in potentially multiple temp-tables. It is important to have a solid understanding of temp-tables and how you can use them before you work with ProDataSets. The discussion of ProDataSets is beyond the scope of this book. See Use ProDataSets for a detailed discussion of these powerful objects.

ABL work-tables

Before you proceed, you should know that there is a variation on the temp-table supported in ABL called a work-table. You use a DEFINE WORK-TABLE statement to define one. This is an older feature that predates temp-tables and lacks some of their features. Most important, a work-table is memory-bound, and you must make sure your session has enough memory to hold all of the records you create in it. In addition, you cannot create indexes on work-tables. You also cannot pass a work-table as a parameter between procedures. Although you could use a work-table for an operation that needed to define a small set of temporary records that do not need a lot of memory and do not need an index, it is better to think of work-tables as being fully superseded by temp-tables. You should use the newer temp-tables for all of your temporary data storage needs.

The temporary database for temp-tables

The temporary database for temp-tables is largely invisible to you. You can design and use temp-tables as if they were entirely memory resident, even though the ABL Virtual Machine (AVM) automatically flushes temp-table records to disk when this is necessary. The temp-table database is stored in whatever you have designated as your temporary directory. By default, this is your working directory, but you can change this by specifying a temporary directory with the –T startup option to your OpenEdge session. If you need to adjust the amount of buffer space that the AVM uses in memory before it writes temp-tables to disk, you can use the –Bt startup option to set this size. You can learn more about these and other startup options in Startup Command and Parameter Reference.