Whether a R:BASE application uses file-based or in-memory temporary tables, there are many advantages to using the feature.
•Raw Speed - Temporary tables/views are fast! With no concurrency checks in multi-user environments, using temporary tables/views lessens access to database resources. For a slow performance report that prints from a view, project a temporary table containing only the rows needed and base the report on the temporary table. The report generation which takes several minutes will now be decreased to seconds.
•Flexibility - Because of the speed, you can do things you would never do with permanent tables. If you have an application which performs an extraordinary amount of massaging of data placed in a temporary table, the work would take far longer to accomplish with a permanent table. And with permanent tables, deleting your scratch work takes time and database resources. With temporary tables, reconnect the database and all the temporary tables are gone.
•No Database Growth - A principal temporary table feature is that the actual data is not part of the RX2 file, but is rather written into a temporary file. For example, if a routine is using an actual table and starts with a 100MB data file, adds 5MB of "temporary data" to the database, then drops the working table, the data file is now 105MB. Then, if the routine is run again and the data file increases to 110MB. Running the routine two more times increases the data file is 120MB, and so forth. A PACK or RELOAD would have to be performed to return the data file back to 100MB after processing the temporary data within the real tables. On the other hand, if the routine uses temporary tables, the data file does not grow, lessening periodic database maintenance.
•Independent - Temporary tables/views are specific to each session of R:BASE, and that specific user. For example, five different users can create the same temporary table (with the same name) and the table not interfere with the one another. Only the user that created the temporary table can see and use it. Essentially, the five different users can be using a temporary table with the same name and all five users could have different data in the table.
•Usability - Temporary tables/views can be treated just as real tables/views. Forms, reports, and labels can be created based upon temporary tables/views. A powerful use of temporary tables is to PROJECT or CREATE a temporary table to collect (LOAD) data and allow easy editing prior to an INSERT into a targeted destination table. An example would be collecting accounting data prior to allowing the user to post the transactions to formal journal tables. In instances where a routine must add rows into a table based on rows already in the table (INSERT ... SELECT), a temporary table is the ideal solution by projecting from the table and inserted where the permanent table columns match the temporary table column, to circumvent the inability to INSERT values into the table used in the SELECT clause.
