A few things you should know about temporary tables

  • May 10, 2010
How do you set a table temporary:
  • You can set the property ‘temporary’ in the AOT to yes –> this table is always temporary
  • You can declare a buffer of a table and call the method setTemp() or setTempData(), from that moment on the buffer contains temporary data.
    CustTable custTable;
    if (custTable.isTmp())
        // Do something with your temporary table
Things to know:
  • When you declare a buffer of a record of temporary table type, the table does not contain any values.
  • Memmory and filespace aren’t allocated for a temporary table till the first record is inserted. This means that you have to watch out for client/server problems.
    When the first record is inserted in a buffer on the client tier, the memory is allocated there. All actions (insert / update / delete) to this buffer will run trough that tier, so try to reduce round-trips and improve your performance.
  • When you declare 2 different buffers of the same temporary table, they will both have a life of their own. To share the date between the tables use the setTmpData method.
    for example: tmpCommonBuffer1.setTmpData(tmpCommonBuffer2);
  • You can’t (normally) set up logging on temporary tables.
  • Use the method isTmp() to know if a record is temporary or not (true –> temporary, false –> phisical)

My opinion: Temporary tables are very useful and can help you to easily manipulate data you don’t need store permanently, but watch out where and how you use them.

  1. Luegisdorf left a comment on May 10, 2010 at 9:16 am

    When working with temporary tables which are permanent as default (f.ex. CustTable), use doInsert(), doUpdate() and doDelete() instead of insert(), update() and delete() to avoid unwanted permanent database side effects. Keep in mind, the data methods on CustTable may contains code which modifies database.

  2. C.Wyns left a comment on March 17, 2011 at 4:36 pm

    To enhance the comment of Luegisdorf :

    Don’t call methods “doInsert”,”doUpdate”,”doDelete”, always call insert,update,delete but by calling first “skipDataMethods(true)” on table buffer.

    This way you can always find which methods do insertion/updates/deletions by implementing these methods on the table and then running cross-references on it, because you can’t implement the “do…” methods so their calls cannot be found by the cross-references.

Comments are closed.