UniVerse RetrieVe comment interroger un fichier pour toutes les valeurs de ses colonnes?

Question

Une sorte de suivre jusqu'à my self-answered question about finding the column names.

Dans UniVerse vous ne pouvez pas interroger un fichier pour toutes ses colonnes à moins que le dans le dictionnaire de votre fichier phrase @ est défini sur toutes les colonnes de tables. Si ce n'est pas le cas, comment interrogez-vous une table pour toutes les valeurs de ses colonnes?

Je peux obtenir la liste total de la colonne (nom colonne & nom d'affichage) à l'aide:

LIST DICT file NAME 

Ceci renvoie une liste de toutes les colonnes et leurs noms d'affichage. Comment puis-je interroger la table pour toutes les colonnes qu'elle a?

LIST file 

Est-ce que la requête pour LIST file @id (@id est la seule chose @).

MISE À JOUR Je trouve a blog -- a living breathing person who id using a version of UniVerse older than mine!! où il se plaint de la même chose, mais dit qu'il n'y a pas de solution de mise à jour timide @ avec toutes les colonnes, s'il vous plaît dieu quelqu'un lui prouver (Dan Watts) mal.

Que faire si vous avez une table de 200 colonne et que vous voulez SELECT * retourner toutes 200 colonnes? Désolé, mais vous aurez pour entrer tous les 200 noms de colonne dans cet enregistrement "@" . Et si vous ajoutez, supprimez ou renommer une colonne, vous devrez n'oubliez pas d'éditer cet enregistrement "@". I ressentez votre douleur! Cette approche lourde remonte au pilote ODBC d'UniVerse, et je suppose qu'ils ne peuvent pas le changer maintenant sans casser beaucoup des applications. Vous pouvez trouver les détails décrits dans IBM dans le Guide UniVerse ODBC.

Answer 1

LIST ALL ne fonctionne pas sur Universe.

Une chose que vous pouvez faire est LIST.ITEM ou LIST-ITEM selon votre goût.Cela liste tous les attributs dans le fichier qui contient des données comme ceci:

>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 

> 

Si vous cherchez à faire quelque chose avec les données écrire un programme et faire quelque chose comme alors ce:

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

Essayez

LIST file ALL 

Bien sûr, il y a une limite à combien il peut réellement faire, il peut déposer. Qu'est-ce que vous voulez réellement accomplir?

De même, plus généralement, vous devriez visiter Rocket Software's U2 Site. Vous pourrez télécharger le manuel complet ici.

Il y a aussi une liste de diffusion qui donne généralement des réponses rapides pour aider les gens. Vous pouvez trouver des détails à ce sujet au U2 User Group site.

Answer 3

Un couple de points:

Le fournisseur ADO.NET IBM Dan refers to ne fera pas partie de UniVerse (ou UniData) à l'avenir. L'entreprise IBM U2 (y compris UniVerse) a été vendue à Rocket Software l'automne dernier, et quelques pièces n'ont pas fait la transition. Deuxièmement, il y a deux PHrases standard pour DICTionaries. @ est la liste par défaut pour CRT. @SELECT spécifie les champs renvoyés par un style 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 
... 

Answer 4

Pour la plupart Univers/Pick installations, les programmeurs construisent généralement des moyens de sténographie normalisées pour faire ad hoc l'accès aux données via RECALL/RÉCUPÉRER/ANGLAIS/LIST plus facile. J'ai souvent vu des entrées dans le fichier VOC avec des noms comme F1, F2, F3 et ainsi de suite qui ressemblent à des dictionnaires "S" ou "D". Habituellement, ils sont quelque chose de standard comme 10 caractères de large et justifié à gauche avec un en-tête de colonne comme "Champ 1". L'utilisation de "* A1", "* A2" et autres semble être une autre norme qui a évolué pour les noms de champs génériques.

Vous pouvez les utiliser dans n'importe quelle commande de liste et si le dictionnaire de fichiers n'a pas de F1 (ou autre), il utilisera celui du fichier VOC. Une commande comme:

LIST {nom de fichier} F1 F2 F3

fonctionnera. C'est bien parce que vous avez juste à le configurer une fois et puis il est disponible partout où vous ne voulez pas prendre le temps de rechercher les noms de dictionnaire.

De même, il n'y a aucune raison pour laquelle vous ne pouvez pas configurer un élément de dictionnaire de type de groupe dans le COV appelé "ALL.FIELDS" et bourrer un gazillion "F1" des éléments de type là. Il ressemblerait à ceci:

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

Ce qui est à peu près ce que votre @ item dictionnaire ressemblerait à moins qu'il aurait tous les éléments du dictionnaire approprié en elle. D'ailleurs, vous pouvez créer un élément de dictionnaire "ALL.FIELDS" dans le dictionnaire du fichier actuel et mettre les éléments de dictionnaire appropriés avec tout le formatage approprié. L'inconvénient de ceci est qu'il n'y a aucune garantie qu'un dictionnaire UV sera complet et précis car il n'y a vraiment aucune règle qui force les programmeurs à construire des éléments de dictionnaire pour les champs de données qu'ils utilisent. Si cela vous tient à cœur, vous devez écrire un programme pour parcourir le fichier et analyser les données afin de générer un rapport sur la façon dont les champs fonctionnent.

Si vous pouvez arriver au point où le dictionnaire va être fiable, alors il vaut la peine de s'assurer que chaque champ a un et un seul élément de dictionnaire de type "A" correspondant. Ensuite, il est trivial d'écrire un programme qui fait un SELECT sur le dictionnaire pour tous les enregistrements de type "A" et construit un élément de dictionnaire de groupe "ALL.FIELD" qui les répertorie tous. Ensuite, assurez-vous que tout le monde ajoutant des éléments de dictionnaire alternatifs pour différentes mises en forme ou conversions n'utilise que des éléments de type "S", "I" et "D".

Personnellement, je trouve que le chargement de l'élément @ dictionary avec tous les champs possibles gênant lorsque l'on fait des choses quotidiennes dans l'environnement PICK. Habituellement, vous voulez des choses qui vont bien sur un affichage de 80 colonnes avec des options de tri et de totalisation qui ont du sens. Je préférerais que les choses SQL soient configurées et nommées en conséquence.

Answer 5

Nom de fichier LIST.ITEM. Cela va retourner toutes les valeurs