[SQL Server / Cobol] Requête sur Varchar

Requête sur Varchar [SQL Server / Cobol] - SQL/NoSQL - Programmation

Marsh Posté le 22-09-2015 à 10:13:31    

Bonjour,
 
J'ai une table avec, entre autre, une données de type Varchar de longueur 38. Je dois faire en cobol une requête SÉLECT avec un critère sur cette donnée à partir d'une donnée de longueur 35 tirée d'un fichier. Voilà mes cas :
- donnée du fichier de longueur 10 par exemple : enregistrement trouvé
- donnée du fichier de longueur 35 : pas d'enregistrement alors qu'il existe.
 
D'où cela vient-il ? De la copy cobol dont voici un extrait ?
01 Nom-table.
   05 DATA PIC X(38).
Il ne manquerait pas une zone associée à la longueur du Varchar ?
 
Merci beaucoup. :jap:


---------------
Nous ne sommes pas des êtres humains vivant une exprérience spirituelle. Nous sommes des êtres spirituels vivant une expérience humaine.
Reply

Marsh Posté le 22-09-2015 à 10:13:31   

Reply

Marsh Posté le 22-09-2015 à 12:35:46    

Personne ? :/


---------------
Nous ne sommes pas des êtres humains vivant une exprérience spirituelle. Nous sommes des êtres spirituels vivant une expérience humaine.
Reply

Marsh Posté le 22-09-2015 à 14:16:20    

Désolé, mais la question n'est pas claire pour moi, bien que vous ayez fait un effort pour l'expliquer longuement.
Je vais tout de même proposer des pistes pour faire avancer le schmilblick.
Mais comme je ne sais pas quel est votre niveau, je vais peut-être dire des choses que vous savez déjà.
 
Vous parlez de Varchar. C'est très curieux, car cela n'existe pas en Cobol ordinaire.
Cela existe en SQL, ou en Pro*Cobol qui est une version de Cobol pour Oracle.
 
La commande SELECT existe en Cobol ordinaire, mais elle existe aussi en SQL.
Ces deux SELECT n'ont pas la même syntaxe, et pas le même usage.
 
Peut-être feriez-vous une confusion entre le Cobol et le SQL, qui sont deux langages différents, mais que l'on retrouve ensemble exceptionnellement en Pro*Cobol.
 
En Cobol ordinaire, il n'y a pas de champ de longueur variable. Tous les champs ont une longueur fixe.
En SQL, il y a des champs de longueur variable, dont VARCHAR et VARCHAR2 sont les exemples les plus courants (il y a aussi les BLOB).
 
Le langage SQL sert à lire et écrire des données dans une base de données relationnelles.
De manière tout à fait exceptionnelle, il peut aussi servir à lire et écrire des données dans des fichiers plats.
 
Ici, vous parlez d'une lecture de fichier plat. Il y a 99% de chances pour que vous deviez faire une lecture sans SQL.
Donc, pas de SQL, signifie, pas de Varchar, et pas de Select du SQL, mais par contre des Pic X et des Select du Cobol.
 
J'espère que ça vous aide un peu.
Je me tiens à votre disposition pour toutes informations complémentaires, parce que j'adore le Cobol au point que j'ai écrit un compilateur Cobol.


Message édité par olivthill le 22-09-2015 à 14:17:10
Reply

Marsh Posté le 22-09-2015 à 14:27:05    

Merci mais non aucune confusion entre SQL et Cobol. J'en fais depuis 10 ans. ;)
Sur SQL Server j'ai une table avec une donnée de type Varchar(38). Dans la copy cobol la variable hôte correspondante est déclarée en PIC X(38).
Dans mon programme Cobol j'ai écrit un ordre SELECT avec un WHERE <donnée Varchar> = :variable-hôte.
On en revient au résultat obtenu que j'ai décrit dans mon message initial.
 
Voilà, j'espère que c'est plus clair.


Message édité par Kilyn le 22-09-2015 à 14:28:14

---------------
Nous ne sommes pas des êtres humains vivant une exprérience spirituelle. Nous sommes des êtres spirituels vivant une expérience humaine.
Reply

Marsh Posté le 22-09-2015 à 14:44:23    

Ce n'est pas beaucoup plus clair.
 
La syntaxe que vous décrivez SELECT avec un WHERE <donnée Varchar> = :variable-hôte n'est ni du SQL ordinaire, ni du Cobol ordinaire. Cela semble être un mixte des deux, comme le pro*Cobol dont je parlais, mais le pro*Cobol est pour Oracle. D'après la section du sujet, vous utilisez SQL Server, et non pas Oracle. Je ne connais pas l'équivalent du pro*Cobol pour SQL Server.
 
Ensuite, je ne comprends pas quelle est la difficulté ?
Est-ce que vous n'avez aucun exemple ?
Pourquoi vouloir faire du SQL pour une lecture de fichier plat ? C'est extrêmement étrange, parce que le SQL n'est pas prévu pour ça, et parce que le Cobol est prévu pour ça.
Je pense qu'il faut utiliser un Select cobolien, et non pas un Select sqlien.
La syntaxe du SELECT en Cobol ordinaire dépend du mode d'ouverture du fichier :
 

*    sequential file
     SELECT [OPTIONAL] file-identifier [ASSIGN [TO] { FILE-ID | file-name }]
            [ORGANIZATION [IS] SEQUENTIAL
            [ACCESS [MODE] [IS] SEQUENTIAL]
            [FILE STATUS [IS] data-name]
            .
 
*    relative file
     SELECT [OPTIONAL] file-identifier [ASSIGN [TO] { FILE-ID | file-name }]
            [ORGANIZATION [IS] RELATIVE]
            [ACCESS [MODE] [IS] { SEQUENTIAL | RANDOM | DYNAMIC }]
            RELATIVE KEY [IS] relative-key
            [FILE STATUS [IS] data-name]
            .
 
*    indexed file
     SELECT [OPTIONAL] file-identifier [ASSIGN [TO] { FILE-ID | file-name }]
            [ORGANIZATION [IS] INDEXED]
            [ACCESS [MODE] [IS] { SEQUENTIAL | RANDOM | DYNAMIC }]
            RECORD KEY [IS] record-key
            [FILE STATUS [IS] data-name]
            .


Vous voyez que c'est très différent d'un SELECT ... WHERE ....
 
La question principale est de savoir si vous voulez vraiment lire un fichier ou une base de données. Si c'est un fichier, alors il faut faire tout le tralala (et ce n'est pas simple) du Cobol pour lire le fichier.


Message édité par olivthill le 22-09-2015 à 14:45:18
Reply

Marsh Posté le 22-09-2015 à 18:25:18    

Merci BrisChri, je regarde. :jap:
Olivthill, je travaille sur une base de données. Ce que j'écris n'est pas clair ? Des requêtes SQL dans un programme Cobol j'en ai fait des tonnes avec une base de données DB2. Pas beaucoup de différences avec SQL Server non ?


Message édité par Kilyn le 22-09-2015 à 18:30:28

---------------
Nous ne sommes pas des êtres humains vivant une exprérience spirituelle. Nous sommes des êtres spirituels vivant une expérience humaine.
Reply

Marsh Posté le 23-09-2015 à 00:14:03    

Excusez-moi d'être parti sur le Select pour la lecture des fichiers. Vous n'aviez parlé nulle part de base de données, et au contraire vous aviez parlé "d'une donnée de longueur 35 tirée d'un fichier" et de "donnée du fichier". Si cette donnée se trouve en fait dans une base de données, alors vous avez raison de vouloir faire un Select...where...
 
Maintenant, effectivement, une variable déclarée en PIC X(38) n'est pas compatible avec une colonne de base de données déclarée en Varchar(38) (ou peut-être déclarée en Varchar(35) puisque vous parlez de 35 caractères par ailleurs, et que vous ne nous montrez pas la définition de cette colonne ; la différence de 3 octets, si elle est réelle, pourrait peut-être s'expliquer si la longueur du champ était inclue au début du champ, comme cela arrive parfois).
En Pro*Cobol (malheureusement, je ne connais pas l'équivalent pour le SQL server que vous utilisez, et dont vous connaissez certainement le nom, mais que vous ne révélez pas, bien que ça aiderait surement pour la réponse), il faut déclarer des variables spéciales avec des instructions spéciales qui sont compilées dans une phase préalable à la compilation normale du Cobol.
 
Edit : Par ailleurs, si vous n'avez pas d'erreur de syntaxe, pas d'erreur à la compilation, pas même de warning (vous ne le dites pas, mais c'est ce que je comprends en relisant votre premier message), et que le seul problème est celui d'un enregistrement (d'après ce que je crois comprendre maintenant, le mot "enregistrement" est encore un vocabulaire approximatif, car habituellement le mot "enregistrement" est employé pour un fichier, mais vous l’emploieriez ici pour le résultat d'une requête) non trouvé, alors il est possible que le problème vienne d'un champ nul concernant un des critères de la recherche (car c'est un problème classique), ou vienne de caractères non nuls à la fin de votre champ Cobol, par exemple qui aurait des espaces à la place de zéros binaires (ce qui est un autre problème classique, qui se résout parfois simplement en mettant un trim() (ou l'équivalent en SQL Server) sur la ligne SQL, par exemple  SELECT avec un WHERE <donnée Varchar> = TRIM(:variable-hôte) ).


Message édité par olivthill le 23-09-2015 à 00:32:11
Reply

Marsh Posté le 26-09-2015 à 14:18:21    

Problème résolu. Il y avait aussi une erreur dans mon code en plus de ce qu'a signalé BrisChris.
SQL Server est un SGBD édité par Microsoft. Je n'avais pas jugé nécessaire de le préciser tant il est connu. Mon programme Cobol travaille avec des fichiers et la base de données sur SQL Server.
Voilà, discussion close.


---------------
Nous ne sommes pas des êtres humains vivant une exprérience spirituelle. Nous sommes des êtres spirituels vivant une expérience humaine.
Reply

Marsh Posté le 29-09-2015 à 09:38:09    

Autant pour moi. :ange:


---------------
Nous ne sommes pas des êtres humains vivant une exprérience spirituelle. Nous sommes des êtres spirituels vivant une expérience humaine.
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed