UniVerse RetreiVe how do I query a file for all of its column's values?

Question

Kind of a follow up to my self-answered question about finding the column names.

In UniVerse you can't query a file for all of its columns unless the @ phrase in your file's dictionary is set to all of the tables columns. If it isn't how do you query a table for all of its column's values?

So I can get the total column listing (column name & display name) using:

LIST DICT file NAME

This will return a listing of all columns and their display names. How do I then query the table for all of the columns it has?

LIST file

Will only query it for LIST file @id (@id is the only thing in @).

UPDATE I found a blog -- a living breathing person who id using a version of UniVerse older than mine!! where he complains about the same thing, but says there is no solution shy of updating @ with all of the columns, please god someone prove him (Dan Watts) wrong.

What if you have a 200 column table and you want SELECT * to return all 200 columns? Sorry, but you’ll have to enter all 200 column names in that "@" record. And if you add, delete or rename a column, you’ll have to remember to edit that "@" record. I feel your pain! This cumbersome approach dates back to UniVerse’s ODBC driver, and I suppose they can’t change it now without breaking a lot of applications. You can find the details described in inscrutable IBM-ese in the UniVerse ODBC Guide.

Answer 1

Try

LIST file ALL

Of course, there is a limit to how many it can actually do, so it may file. What do you actually want to achieve?

Also, more generally, you should visit Rocket Software's U2 Site. You will be able to download the full manual set there.

There is also a mailing list that usually gives fast responses to help people out. You can find details of that at the U2 User Group site.

Answer 2

LIST ALL does not work on Universe.

One thing you can do is LIST.ITEM or LIST-ITEM depending on your flavor. This will list every attribute in the file that has data in it like this:

>LIST.ITEM ACTIVITY
LIST.ITEM ACTIVITY 06:52:10pm  14 Jan 2010  PAGE    1

1
001 LEXMARK MULTI PRINT
002 THD
003 PJ
007 10355
009 Y
010 CAGNEW
011 15349
012 52111
014 1ý2ý3ý4ý5
015 Deinstall Make/ModelýDeinstall LocationýSigned Off ByýData/Voice AvailableýR
elocated Location
016 1ý2ý3ý4ý5

2
001 OMN
002 OMN
003 PJ
004 OMN*8437
005 6
009 N
010 CAGNEW
011 15349
012 51958

>  

If you're looking to do something with the data then write a program and do something like this:

OPEN "ACTIVITY" TO F.ACTIVITY ELSE STOP
SELECT F.ACTIVITY
LOOP
    READNEXT ID ELSE EXIT
    READ R.ACTIVITY FROM F.ACTIVITY, ID THEN
    ..................
    END
REPEAT

Answer 3

A couple of points:

IBM's ADO.NET provider Dan refers to will not be part of UniVerse (or UniData) going forward. The IBM U2 business (including UniVerse) was sold to Rocket Software last fall, and a couple of pieces didn't make the transition.

Second, there are a couple of standard PHrases for DICTionaries. @ is the default listing to CRT. @SELECT specifies the fields returned from a SQL style SELECT.

>ED DICT VOC @SELECT
New record.

----: I
0001= PH
0002= NAME TYPE
0003= 
Bottom at line 2.
----: FI
"@SELECT" filed in file "DICT VOC".
>SELECT * FROM VOC;
NAME.......... TYPE

VERIFY.SQL     V
DIVX           V
INVISIBLE      K
QUIT.KEY       X
LEADING        K
DELETE.LIST    V
...

Answer 4

For most Universe/Pick installations, the programmers usually build some standardized shorthand ways to make ad hoc access to data via RECALL/RETRIEVE/ENGLISH/LIST easier. I've often seen entries in the VOC file with names like F1, F2, F3 and so on that look like "S" or "D" dictionaries. Usually they're something standard like 10 characters wide and left justified with a column heading like "Field 1". Using "*A1", "*A2" and the like seems to be another standard that's evolved for generic field names.

You can use these in any list command and if the file dictionary doesn't have an F1 (or whatever) it will use the one from the VOC file. So a command like:

LIST {filename} F1 F2 F3

Will work. It's nice because you just have to set it up once and then it's available anywhere you don't want to take the time looking up the dictionary names.

Also, there's no reason you can't set up a group type dictionary item in the VOC called "ALL.FIELDS" and stuff a gazillion "F1" type items in there. It would look like this:

001: PH 002: F1 F2 F3 F4 F5 F6 F7 F8 F9 {....} F200

Which is pretty much what your @ dictionary item would look like except it would have all of the proper dictionary items in it. For that matter, you could build an "ALL.FIELDS" dictionary item in the dictionary of the actual file and put the proper dictionary items with all of the proper formatting in there.

The caveat with this is that there is no guarantee that a UV dictionary is going to be complete and accurate as there are really no rules anywhere that force programmers to build dictionary items for data fields they use. If you care that much, you'd need to write a program to scan through the file and analyze the data to generate a report of how the fields actually work out.

If you can get to the point where the dictionary is going to be reliable, then it's worthwhile making sure that each field has one and only one corresponding "A" type dictionary item. Then it's trivial to write a program that does a SELECT on the dictionary for all of the "A" type records and builds an "ALL.FIELD" group dictionary item that lists them all. Then just make sure that everyone adding alternate dictionary items for different formatting or conversions uses only "S", "I" and "D" type items.

Personally, I find loading up the @ dictionary item with every field possible annoying when doing everyday stuff inside the PICK environment. Usually, you want stuff that fits nicely across an 80 column display with sort and totaling options that make sense. I'd prefer to see SQL stuff set up and named accordingly.

Answer 5

Your statement about IBM.NET is incorrect.

Answer 6

LIST.ITEM filename. This will return all the values