en fait je n'ai pas de docs; j'ai juste deux types de
fichiers un idx pour les index apparemment et un dat pour
les donnees.
et un fichier idx et un fichier dat correspond a une
table, c'est un SGF.
Je ne voudrais pas recreer le programme cobol, et je
voudrais donc avoir la possibiliter de creer un programme
VB qui recupere les infos de ces fichiers et les presente
a un utilisateur, qui pourra les modifies si il veut.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Alfred Wallace
Bonjour,
On peut tout à fait laisser cohabiter des données Cobol avec du VB; Nous le faisons quotidiennement. Les DLL peuvent etre en 16 bits si Cobol 16 bits ou en 32 Bits. Cobol permet également de développer des programmes "pure" Windows en mode API comme du C.
Bref, l'archaisme dénoncé est loin d'être manifeste, et il est bien plus facile de sous-classer un controle Windows en Cobol version API qu'en VB.
Pour revenir à ta demande, si tu connais au moins le découpage de tes fichiers et la version de Cobol que tu utilises, il y a naturellement des possibilités de migration ou d'exploitation des données.
Luc
"COBOL" a écrit dans le message de news:0afb01c3a9d2$fb6da8c0$
en fait je n'ai pas de docs; j'ai juste deux types de fichiers un idx pour les index apparemment et un dat pour les donnees. et un fichier idx et un fichier dat correspond a une table, c'est un SGF. Je ne voudrais pas recreer le programme cobol, et je voudrais donc avoir la possibiliter de creer un programme VB qui recupere les infos de ces fichiers et les presente a un utilisateur, qui pourra les modifies si il veut.
Est ce que le probleme est bien defini.
Bonjour,
On peut tout à fait laisser cohabiter des données Cobol avec du VB; Nous le
faisons quotidiennement. Les DLL peuvent etre en 16 bits si Cobol 16 bits ou
en 32 Bits. Cobol permet également de développer des programmes "pure"
Windows en mode API comme du C.
Bref, l'archaisme dénoncé est loin d'être manifeste, et il est bien plus
facile de sous-classer un controle Windows en Cobol version API qu'en VB.
Pour revenir à ta demande, si tu connais au moins le découpage de tes
fichiers et la version de Cobol que tu utilises, il y a naturellement des
possibilités de migration ou d'exploitation des données.
Luc
"COBOL" <anonymous@discussions.microsoft.com> a écrit dans le message de
news:0afb01c3a9d2$fb6da8c0$a401280a@phx.gbl...
en fait je n'ai pas de docs; j'ai juste deux types de
fichiers un idx pour les index apparemment et un dat pour
les donnees.
et un fichier idx et un fichier dat correspond a une
table, c'est un SGF.
Je ne voudrais pas recreer le programme cobol, et je
voudrais donc avoir la possibiliter de creer un programme
VB qui recupere les infos de ces fichiers et les presente
a un utilisateur, qui pourra les modifies si il veut.
On peut tout à fait laisser cohabiter des données Cobol avec du VB; Nous le faisons quotidiennement. Les DLL peuvent etre en 16 bits si Cobol 16 bits ou en 32 Bits. Cobol permet également de développer des programmes "pure" Windows en mode API comme du C.
Bref, l'archaisme dénoncé est loin d'être manifeste, et il est bien plus facile de sous-classer un controle Windows en Cobol version API qu'en VB.
Pour revenir à ta demande, si tu connais au moins le découpage de tes fichiers et la version de Cobol que tu utilises, il y a naturellement des possibilités de migration ou d'exploitation des données.
Luc
"COBOL" a écrit dans le message de news:0afb01c3a9d2$fb6da8c0$
en fait je n'ai pas de docs; j'ai juste deux types de fichiers un idx pour les index apparemment et un dat pour les donnees. et un fichier idx et un fichier dat correspond a une table, c'est un SGF. Je ne voudrais pas recreer le programme cobol, et je voudrais donc avoir la possibiliter de creer un programme VB qui recupere les infos de ces fichiers et les presente a un utilisateur, qui pourra les modifies si il veut.
