Don,

> I've heard that. This will be a small table. Other Client/Server
> systems provide a means of creating and using temp tables, though. Temp
> tables help much when one is doing things like cross tab reports. In my
> case, I run thru a series of 2 stored procedures before I save the
> results into a temp table. The only reason of using the temp table is
> to fill-in a new field of running differences.

Small or Huge, no difference at all. The problem is that you will be
changing metadata a lot.

If you have the main data on another table, another option is to create
this temporary field on that table. You can use something like TMP_ to
identify that the field will be temporary. Since you are using this just
for report purposes, you will have this values just on the scope of your
transaction, and you may keep them always invisible to other
transactions, and you can rollback all of this after you print it. Don't
worry about the space that this field will take on the database.

Another option will be using a permanent table, with just 2 fields (I
use this method a lot): one for ID, another for the result I want to be
temporary. It's very easy to pick up values from this table any time I
want. Sometimes I had an extra field to this table, just to add an extra
control so that it can work outside the transaction.

But, most of the times, you will need just the results of a selectable
stored procedure to do the job.

> I would gladly use an in-memory table for this but management doesn't
> want us adding new components, even if they are free, without going thru
> red-tape. They have some valid reasons.

Just don't create and delete tables all the time. Keep your metadata
static. You can do exactly what you are doing now just creating the
table and let it be there. That should be your concern.

Cya,

Artur