Raw Speed
Temporary Tables/Views are lightening fast! There is no multi-user checking going on.
Find a report that prints from a view whose performance is extremely slow, project a temporary table containing only the rows needed and drive the report from the temporary table. A report that takes 5-10 minutes to print might print in under a minute.
Flexibility
Because of the speed, you can do things you would never do with permanent tables. If you have systems that do an extraordinary amount of massaging of data placed in a temporary table. The work would take far longer (we are talking 10-100 times) to accomplish with a permanent table. And with permanent tables, deleting your scratch work takes a great deal of time and each record must have a user id in it to work correctly. With temp tables you just reconnect the database and all the temp tables are gone, just like that.
Temporary tables/views are also supported when STATICDB is set to ON.
No database growth
The data in the temporary tables is not part of File 2- the data file. The most important thing about temporary tables is that the actual data for a given user is written into a scratch file (.$$$). With an actual table that data is stored in the data file.
For example, if you are using an actual table and start with a 100MB data file and add 5MB of "temporary data" to a database, then drop the working table. Now, your data file is 105MB. Then, run the procedure again and you'll have 110MB. Running the procedure two more times and your data file is 120MB, and so on. You would have perform a PACK or RELOAD just to return back to the 100MB data file after processing temporary data within actual tables. On the other hand, if you use temporary tables your data file doesn't grow at all.
Views don't really make much difference since the only thing that would be stored in the database itself (and they still might be with temporary views) would be the structure. Everything else is generated when you actually use the view.
Independent
Temporary Tables/Views are specific to each session of R:BASE and that specific user.
For example, five different users or sessions, can create the same temporary table with the same name and not interfere with the others. Only the user that created the table can see/use it. So what it means is that 5 different uses can be using a running a report on the temporary table/view and all 5 users have different data in the table.
The "Sales Order" option in Running R:BASE Your Way sample applications, bundled with R:BASE, demonstrate the typical use of this feature.
Usability
You can treat a temporary table/view as a regular table/view. You can create Forms, Reports and Labels based upon the temporary table/view.
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. Since each session of R:BASE will project/create its own private temporary table (of the same name) this is an ideal solution, say for collecting some accounting data prior to allowing the user to post the transaction to the formal journal tables. As soon as the insert is done, a DISCONNECT/CONNECT will eliminate the temporary table and you are ready for next time.
Temporary tables are great when you are trying to take a huge vertical table with hundreds of thousands of rows and farm it out to some aggregate tables.
Sometimes when you need to insert row(s) into a table based on rows in the table, (the where clause cannot refer to the same table for the insert) You may project a temp table of the correct where conditions and insert where column in permanent table in (select column from temp table). You can do all kinds of variations of this one, such as using existing rows as a template which you house in a temp table, edit for the new values and re-insert back to the permanent table.
Disadvantages of Temporary Tables/View:
The advantage of temporary tables/views is also their disadvantage. They are not permanent. Any data you wish to be persistent must go in real tables/views.
