UniVerse RetrieVe how do I query a file for all of its columns' values? - u2

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 columns' 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

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 2

LIST.ITEM filename.
This will return all the values

Answer 3

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 4

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 5

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.