UniVerse RetrieVe 如何查询文件的所有列？价值观？

发布于 2024-08-18 02:49:44 字数 962 浏览 5 评论 0原文

在 UniVerse 中，除非将文件字典中的 @ 短语设置为所有列，否则您无法查询文件的所有列。表格列。如果不是，如何查询表中所有列的值？

因此，我可以使用以下方法获取总列列表（列名称和显示名称）：

LIST DICT file NAME

这将返回所有列及其显示名称的列表。然后我如何查询表中的所有列？

LIST file

只会查询LIST file @id（@id是@中唯一的东西）。

更新我发现一个博客——一个活生生的人，他使用比我的 UniVerse 版本早！！他抱怨同样的事情，但说没有解决方案可以用所有列更新 @，请上帝来证明他（丹·瓦茨）错了。

如果你有一个 200 列的表怎么办并且您希望 SELECT * 返回所有 200 列？抱歉，但是你会有在其中输入所有 200 个列名称 “@“ 记录。如果您添加、删除或重命名一列，你必须请记住编辑该“@”记录。我感受你的痛苦！这个麻烦该方法可以追溯到 UniVerse 的 ODBC 司机，我想他们不能立即更改，不会造成太大破坏应用程序。您可以找到细节描述深不可测 UniVerse ODBC 指南中的 IBM 语言。

原文

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.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

岁月苍老的讽刺 2024-08-25 02:49:44

LIST ALL 不适用于 Universe。

您可以做的一件事是 LIST.ITEM 或 LIST-ITEM，具体取决于您的口味。这将列出文件中包含数据的每个属性，如下所示：

>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

>

如果您想对数据执行某些操作，则编写一个程序并执行如下操作：

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

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

回复收藏 0 原文

迷鸟归林 2024-08-25 02:49:44

列表.ITEM 文件名。
这将返回所有值

回复收藏 0 原文

倦话 2024-08-25 02:49:44

尝试

LIST file ALL

当然，它实际能做的次数是有限的，所以它可能会归档。你真正想要实现什么？

另外，更一般地说，您应该访问 Rocket Software 的 U2 网站。您可以在那里下载完整的手册集。

还有一个邮件列表，通常可以提供快速响应来帮助人们解决问题。您可以在 U2 用户组网站找到详细信息。

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.

回复收藏 0 原文

离去的眼神 2024-08-25 02:49:44

几点：

IBM 的 ADO.NET 提供程序 Dan 指的是今后将不会成为 UniVerse（或 UniData）的一部分。去年秋天，IBM U2 业务（包括 UniVerse）被出售给 Rocket Software，但有几个业务未能完成过渡。

其次，字典有几个标准短语。 @ 是 CRT 的默认列表。 @SELECT 指定从 SQL 样式 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
...

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
...

回复收藏 0 原文

银河中√捞星星 2024-08-25 02:49:44

对于大多数 Universe/Pick 安装，程序员通常会构建一些标准化的速记方法，以便更轻松地通过 RECALL/RETRIEVE/ENGLISH/LIST 对数据进行临时访问。我经常看到 VOC 文件中的条目名称如 F1、F2、F3 等，看起来像“S”或“D”字典。通常它们是标准的，比如 10 个字符宽，左对齐，并带有“字段 1”这样的列标题。使用“*A1”、“*A2”等似乎是针对通用字段名称而发展的另一个标准。

您可以在任何列表命令中使用这些命令，如果文件字典没有 F1（或其他），它将使用 VOC 文件中的字典。所以像这样的命令：

LIST {filename} F1 F2 F3

将会起作用。这很好，因为您只需设置一次，然后就可以在任何您不想花时间查找字典名称的地方使用它。

另外，您没有理由不能在 VOC 中设置一个名为“ALL.FIELDS”的组类型字典项目，并在其中填充无数的“F1”类型项目。它看起来像这样：

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

这几乎就是你的@字典项目的样子，只不过它包含所有正确的字典项目。就此而言，您可以在实际文件的字典中构建一个“ALL.FIELDS”字典项目，并将具有所有正确格式的正确字典项目放入其中。

需要注意的是，不能保证 UV 字典是完整和准确的，因为实际上没有任何规则强制程序员为他们使用的数据字段构建字典项。如果您非常关心，则需要编写一个程序来扫描文件并分析数据以生成有关字段实际工作情况的报告。

如果您能够达到字典可靠的程度，那么值得确保每个字段都有一个且仅有一个对应的“A”类型字典项。然后，编写一个程序，对所有“A”类型记录的字典进行 SELECT 操作，并构建一个列出所有记录的“ALL.FIELD”组字典项，就很简单了。然后，只需确保为不同格式或转换添加备用词典项目的每个人仅使用“S”、“I”和“D”类型项目。

就我个人而言，我发现在 PICK 环境中执行日常操作时，加载 @dictionary 项以及每个可能的字段很烦人。通常，您想要的内容能够很好地适应 80 列的显示，并具有有意义的排序和总计选项。我更愿意看到 SQL 内容被相应地设置和命名。

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.

回复收藏 0 原文

~没有更多了~