A command to describe the hash file
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 197
- Joined: Mon Feb 17, 2003 11:20 pm
- Location: India
A command to describe the hash file
Hi All,
Is there any command to describe a Hash File (like Describe of Oracle).
A command that expects the hash file name and when executed returns all the columns present in the hashfile with their datatypes.
Regards,
Sumit
Is there any command to describe a Hash File (like Describe of Oracle).
A command that expects the hash file name and when executed returns all the columns present in the hashfile with their datatypes.
Regards,
Sumit
-
- Participant
- Posts: 197
- Joined: Mon Feb 17, 2003 11:20 pm
- Location: India
Select * from file uses the default listing for a file. The default list of fields is stored in the DICT in @. @ is a phrase. It has PH in line 1 and a list of fields on line 2 separated by spaces. The @KEY is also displayed. It is a phrase which has all the fields which are part of the primary key.
You can select any field in the LIST DICT. Try it.
You can select any field in the LIST DICT. Try it.
Mamu Kim
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Time to be a little bit pedantic again.
The columns that are displayed by an SQL query are specified by a phrase in the dictionary called @SELECT (it only defaults to @ if there is no @SELECT phrase defined). Usually @SELECT is the same as @ but incldues the key column explicitly. But it doesn't have to be thus.
Secondly, Ascential made a deliberate decision not to document every column of the Repository tables in their metadata, so you can only look at a very limited subset. In particular, records in DS_JOBOBJECTS have different structures depending on OLETYPE; one record type has only 26 columns; another has over 300. And what's in each column is different for different record types (for example Annotations don't have (or need) column definitions).
The columns that are displayed by an SQL query are specified by a phrase in the dictionary called @SELECT (it only defaults to @ if there is no @SELECT phrase defined). Usually @SELECT is the same as @ but incldues the key column explicitly. But it doesn't have to be thus.
Secondly, Ascential made a deliberate decision not to document every column of the Repository tables in their metadata, so you can only look at a very limited subset. In particular, records in DS_JOBOBJECTS have different structures depending on OLETYPE; one record type has only 26 columns; another has over 300. And what's in each column is different for different record types (for example Annotations don't have (or need) column definitions).
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 197
- Joined: Mon Feb 17, 2003 11:20 pm
- Location: India
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
OK, here we go...
@ defines the default output fields for the RetrieVe query language; if there is no @ entry only the key field is displayed
@LPTR defines the default output fields for the RetrieVe query language if the LPTR keyword appears in the query; if there is no @LPTR entry @ entry is used.
@REVISE defines the default fields to be prompted for when data are being entered/updated using the dictionary-driven REVISE tool (part of the RetrieVe query language); if no @REVISE entry appears all fields are prompted for, multi-valued fields on separate screens per association
@SELECT defines the default display fields (columns) for SQL SELECT queries (and, by implication, the effect of the asterisk for "all records"); if there is no @SELECT entry, the @ entry is used
@INSERT defines the default columns used in an SQL INSERT statement if there is no column list specified; if there is no @INSERT entry a column list must be specified
@KEY lists the columns making up the primary key
@KEY_SEPARATOR defines the separator character used to separate columns in a multi-column primary key; if there is no @KEY_SEPARATOR entry a text mark (accessible via the @TM system variable) is used
(@SELECT, @KEY and, if necessary, @KEY_SEPARATOR are emplaced by the CREATE TABLE statement.)
@EMPTY.NULL, if present, enables presentation of "" as NULL in ODBC-initiated queries.
All of these, and others (!), are documented in appropriate UniVerse manuals.
@ defines the default output fields for the RetrieVe query language; if there is no @ entry only the key field is displayed
@LPTR defines the default output fields for the RetrieVe query language if the LPTR keyword appears in the query; if there is no @LPTR entry @ entry is used.
@REVISE defines the default fields to be prompted for when data are being entered/updated using the dictionary-driven REVISE tool (part of the RetrieVe query language); if no @REVISE entry appears all fields are prompted for, multi-valued fields on separate screens per association
@SELECT defines the default display fields (columns) for SQL SELECT queries (and, by implication, the effect of the asterisk for "all records"); if there is no @SELECT entry, the @ entry is used
@INSERT defines the default columns used in an SQL INSERT statement if there is no column list specified; if there is no @INSERT entry a column list must be specified
@KEY lists the columns making up the primary key
@KEY_SEPARATOR defines the separator character used to separate columns in a multi-column primary key; if there is no @KEY_SEPARATOR entry a text mark (accessible via the @TM system variable) is used
(@SELECT, @KEY and, if necessary, @KEY_SEPARATOR are emplaced by the CREATE TABLE statement.)
@EMPTY.NULL, if present, enables presentation of "" as NULL in ODBC-initiated queries.
All of these, and others (!), are documented in appropriate UniVerse manuals.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Yep sure does! Probably one or two other things you didn't know about CREATE TABLE in the following example.
In this example the separator character (@KEY_SEPARATOR) in the physical primary key (@ID) is an asterisk. The I-descriptors that isolate keycol1 and keycol2 in the dictionary will make reference to this character as the second argument of their FIELD functions.
Code: Select all
CREATE TABLE MyTable
(
TYPE 18, MODULO 4211, SEPARATION 4,
keycol1 INTEGER NOT NULL DEFAULT NEXT AVAILABLE,
keycol2 DATE NOT NULL,
othercol1 INTEGER NOT NULL DEFAULT 0,
othercol2 VARCHAR(254),
CONSTRAINT MyTablePKC PRIMARY KEY '*' (keycol1, keycol2)
);
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.