Within a single run-time session, if one routine calls another and passes a temp-table as a parameter, you wind up with two complete copies of the temp-table and all its data within that session. This is unnecessary in many cases and can be expensive. It takes a lot of memory to copy a large table, and (relatively speaking) a lot of time to copy it. In many cases, your application does not need two copies of the table. To avoid copying the table and thereby gain a significant performance advantage, you can pass temp-table parameters by reference or by binding. These optional means of passing static temp-tables as parameters are described in Define and Use Temp-tables.

Alternately, you can simply pass a temp-table’s HANDLE. Remember that for any kind of object, if you make the handle of the object available to another routine within the session, the other routine can access that object, its data, and its attributes regardless of where the object was defined or created. This holds true for a temp-table as well. Using the temp-table handle your routine can get at its buffer, along with all the data in the table.

When should you consider passing the TABLE within a session? If both routines use static temp-table definitions and static ABL statements to access the table, then you need to pass the table itself instead of its handle. If you pass the handle, then the routine that receives the temp-table can only manipulate it through its handle, using dynamic buffer and buffer field methods and attributes. If the two routines have compatible but different definitions of the same table with, for example, different field names for the fields in the same relative positions within the temp-table buffer, you can successfully pass this table from one routine to the other. In the course of copying it, the AVM moves the data into the fields as they are defined in the routine that receives the table.

If you need to pass the table itself because your routines need to manage it with static ABL statements, then do what you can to minimize the amount of data you pass. If the routine is only going to look at a subset of the records in the temp-table (for example, those that have been changed since they were created or since the receiving routine last saw them), then it might be more efficient to create a second smaller temp-table containing only those records that really need to be passed. If you simply keep in mind that there is an overhead to passing the table, this should influence your design and programming to minimize the overhead.