National Radio
Astronomy Observatory

table.table - Function

3.2.1 Construct table tool


Description

Use this constructor to construct a table tool inside casapy from the name of a disk file containing a CASA Table. A new table may also be created from a table descriptor (see tablecreatedesc). When creating a new table, detailed data manager information can be given using the dminfo argument. This is a record as returned by the getdminfo function.

Most of the arguments are rarely used: most of the time, you’ll just need to use the tablename, and perhaps nomodify.

A table can be shared by multiple processes by using the appropriate locking options. The possible options are:
- auto: let the system take care of locking. At regular time intervals these autolocks are released to give other processes the opportunity to access the table. The aipsrc variable
table.relinquish.reqautolocks.interval defines the number of seconds between releasing autolocks on tables needed in another process.
table.relinquish.allautolocks.interval defines the number of seconds between releasing all autolocks.
- autonoread: as auto, but no read locking is needed. This must be used with care, because it means that reading can be done while the table tool is not synchronized with the table file (as is normally done when a lock is acquired). The function resync can be used to explicitly synchronize the table tool
- user: the user takes care by explicit calls to lock and unlock
- usernoread: as user and the no readlocking behaviour of autonoread.
- permanent: use a permanent lock; the constructor fails when the table is already in use in another process
- permanentwait: as above, but wait until the other process releases its lock
- default: this is the default option. If the given table is already open, the locking option in use is not changed. Otherwise it reverts to auto.
When auto locking is used, it is possible to give a record containing the fields option, interval, and/or maxwait. In this way advanced users have full control over the locking options. In practice this is hardly ever needed.

When creating a new table, the endian format in which the data should be stored, can be specified. The possible values are:
- big: big endian format (as used on e.g. SUN)
- little: little endian format (as used on e.g. PC)
- local: use the endian format of the machine being used
- aipsrc: use the endian format specified in aipsrc variable table.endianformat (which defaults to big).
The default is aipsrc.
Note that usually it is best to store data in local endian format, because that requires the least amount of byte swapping. However, if the table must be accessible with AIPS++ version 1.7 or before, big endian should be used.

When creating a new table, the table will normally reside on disk. It is, however, possible to specify that the table should be held in memory. In such a case the table is process specific, thus cannot be seen by other processes. Note that a memory table uses the MemoryStMan storage manager for all its stored columns, but it is still possible to use virtual columns as well.

Arguments

Example

__________________________________________________________________

More information about CASA may be found at the CASA web page

Copyright © 2016 Associated Universities Inc., Washington, D.C.

This code is available under the terms of the GNU General Public Lincense