Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
Version 1.9 Build 1556 |
|
Package | utility | |
Module | table | |
Tool | table |
Most of the arguments are rarely used: most of the time, you'll just need to use the tablename, and perhaps readonly.
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.
tablename | in | Name of table on disk | |
Allowed: | String|Bool | ||
Default: | F | ||
tabledesc | in | Table descriptor | |
Allowed: | Descriptor|Bool | ||
Default: | F | ||
nrow | in | Number of rows | |
Allowed: | Int | ||
Default: | 0 | ||
readonly | in | Open Read-only? | |
Allowed: | Bool | ||
Default: | T | ||
lockoptions | in | locking to be used | |
Allowed: | String|Record | ||
Default: | default | ||
ack | in | Acknowledge creations, etc | |
Allowed: | Bool | ||
Default: | T | ||
dminfo | in | Data manager info for new table | |
Allowed: | Record | ||
Default: | F | ||
endian | in | Endian format of new table | |
Allowed: | String | ||
Default: | aipsrc | ||
memorytable | in | Hold new table in memory? | |
Allowed: | Bool | ||
Default: | F | ||
tableserver | in | Table handler to be used | |
Allowed: | Any tableserver | ||
Default: | defaulttableserver | ||
tablenote | in | note function to be used | |
Allowed: | Any note function | ||
Default: | note | ||
handle | in | attach to this table handle | |
Allowed: | for internal use only | ||
Default: | F |
table1:=table("3C273XC1.MS"); table1.browse();
The first line opens an existing table 3C273XC1.MS, the second browses it using the browse tool function.
table2:=table("name", readonly=F, lockoptions='user', endian='local'); table2.lock(); table2.addRows(); table2.unlock();In this example explicit user locking is used. The function lock is needed to acquire a (write) lock before the addRows is done. Thereafter the lock is released to give other processes the chance to operate on the table.