1

I am Extracting dictionary info and data(flat files) for the unidata tables through a java program where i used 'table name' for getting both the things, now we are having other project where the Unidata db is divided into multiple modules(Directories) each directory contains files and more directories, Now my question is 1)how can we say a particular file is Unidata table? 2)for some files we able to get dictionary info but not data, are these two things are not available at same location ? if not, how can we relate both the things?
I am very new to Unidata, please ignore my naiveness on this subject and shed some light. Thanks

syed99
  • 332
  • 1
  • 5
  • 20
  • When you mention "unidata tables" I assume you are referring to SQL access. In order for a UniData file to be accessible from SQL, you will need to execute the CONVERT.SQL command on the file. Once this is done the SQL privileges are set and you will have access to the table. With that being said, what are you using to access the file from Java (UOJ or JDBC)? Also, have you loaded the Visual Schema Generator onto the client to view the Tables/Schema. – Mike Nov 18 '15 at 15:48

1 Answers1

1

If you login to Unidata and look at it from inside, it's may be little clearer. A unidata "account" (database) contains files and dictionaries. A file is like a database table, but with no metadata about the contents or columns. A dictionary is a special kind of table that does contain metadata about the corresponding file. So if I do:

:CREATE.FILE MY.FILE 37,1
Create file D_MY.FILE, modulo/1,blocksize/1024
Hash type = 0
Create file MY.FILE, modulo/37,blocksize/1024
Hash type = 0
Added "@ID", the default record for UniData to DICT MY.FILE.

I get two unix-level files created in the current account. Both are empty. Because I didn't specify, the system created a hashed file, as well as a pointer in the "master dictionary" or VOC.

:ED VOC MY.FILE
Top of "MY.FILE" in "VOC", 3 lines, 19 characters.
*--: P
001: F
002: MY.FILE
003: D_MY.FILE
Bottom.

The first attribute tells us the type of file. The 2nd and 3rd are pointers to where the data and dictionary files are (they don't have to be in the current account). Other types include DIR-type, LD (multi-level files where there are sub-files with a shared dictionary) and some less usual combinations. More info from:

:HELP CREATE.FILE
CREATE.FILE

Syntax

CREATE.FILE [DICT | DATA] [DIR | MULTIFILE | MULTIDIR] filename [,subfile]
[modulo [,block.size.multiplier]] [TYPE hashtype] [DYNAMIC [KEYONLY
| KEYDATA] [PARTTBL part_tbl]] [RECOVERABLE] [OVERFLOW]
Note: The PARTTBL option is available on UniData for UNIX only.
Synonym
CREATE-FILE

Description

The ECL CREATE.FILE command creates a UniData file. If you do not
indicate the kind of file to create (such as dictionary, data, or
directory), UniData creates filename (both the data and dictionary
files) as a static hashed file. If an operating system-level file
of the same name already exists in the target account, CREATE.FILE
fails.

So, if you're successfully extracting data already, but want to know about the type of new tables and where their dictionaries are, the answer is to look in the VOC table.

Ian McGowan
  • 3,461
  • 3
  • 18
  • 23
  • wow Thanks , you did clear some of my doubts. Now i am able to retrieve tables from a account path i am getting table names like AVOC,BVOC,CVOC..XVOC other than normal tables, my doubt is there are similar to what VOC (MASTER Directory) is (which can be ignored as table in MSSQL) or they need to be consider as normal tables? – syed99 Nov 24 '15 at 07:46
  • Basically which files are default files for a unidata account path, and can we ignore it for data migration? – syed99 Nov 24 '15 at 11:04
  • The easiest way to answer that is to run 'newacct' and create a new, empty, unidata account. Or look in $UDTHOME/demo which tends to be untouched. But it's really application dependent, so a difficult question to answer. Most applications have some "junk" or "temp" tables that you probably don't want. If you can, using the touch command to set the date of all files/tables to the same value and letting the system go for a few weeks is one way to figure out what's actually used. Dangerous to assume though! – Ian McGowan Dec 08 '15 at 01:06