j'ai un truc bizarre :
sur un programme d'une dizaine d'années, commercialisé actuellement en WD
5.5b, et en cours de migration vers WD9, j'ai un comportement de WDMODFIC
que je ne m'explique pas.
En effet, depuis sa création, ce programme a vu son analyse évoluer
constamment; ce n'est pas par mauvaise analyse initiale, mais bien parce que
ce programme, relatif au domaine administratif médical, dépend donc des lois
qui ne cessent d'évoluer d'année en année...
Aujourd'hui donc, il passe d'une version 62 à la 65, et la moulinette est
lancée automatiquement par le biais d'un batch MODFIC.BAT, qui est repris ci
dessous :
---------- MODFIC.BAT
@echo off
set reper=%cd%
wdmodfic "ANALYSE.WD5" /WD /F /INST /NOLOC /REP=%reper%
del %reper%\*.bin > %reper%\62_65.txt
---------- Fin du MODFIC.BAT
Ce qui s'est toujours bien passé auparavant, et continue aujourd'hui à bien
se dérouler, SAUF sur des machines toujours sous W98 (non, les clients n'ont
pas tous W2000 ou Xp).
J'ai donc reconfiguré une vieille bécane qui traînait (PII 400, 256 Mb) sous
W98, et fait le test moi-même, ce qui m'a permis de réaliser que sous W98,
la migration, une fois lancée, s'enclenche bien, mais lorsqu'elle atteint
les niveaux 62 et suivants de l'analyse, là où, sous un autre Windows, la
moulinette s'enclenche, c'est ici le mutisme complet, SAUF pour la dernière
version (65) où seul le dernier fichier dont la structure a été modifiée
subit la migration (en effet, l'évolution de 64 > 65 implique plusieurs
fichiers modifiés, mais seul le dernier paraît détecté...).
Dernier détail, le WDMODFIC.EXE utilisé est bien toujours le même que les
précédentes fois, il s'agit de celui dont voici les propriétés:
Taille : 229.776 octets
Date : 17/01/2001 à 16:36
Version : 5.50Bk
Connaissez-vous le cas ?
Si oui, l'explication existe-t-elle ? Quelle est-elle en ce cas ?
Merci d'avance de vos lumières et expériences sur ce sujet qui me coince
très désagréablement pour le moment...
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
titou44
Patrick COQUE avait soumis l'idée :
Salut à tous,
j'ai un truc bizarre : sur un programme d'une dizaine d'années, commercialisé actuellement en WD 5.5b, et en cours de migration vers WD9, j'ai un comportement de WDMODFIC que je ne m'explique pas.
En effet, depuis sa création, ce programme a vu son analyse évoluer constamment; ce n'est pas par mauvaise analyse initiale, mais bien parce que ce programme, relatif au domaine administratif médical, dépend donc des lois qui ne cessent d'évoluer d'année en année...
Aujourd'hui donc, il passe d'une version 62 à la 65, et la moulinette est lancée automatiquement par le biais d'un batch MODFIC.BAT, qui est repris ci dessous :
---------- MODFIC.BAT
@echo off set reper=%cd% wdmodfic "ANALYSE.WD5" /WD /F /INST /NOLOC /REP=%reper% del %reper%*.bin > %reper%62_65.txt
---------- Fin du MODFIC.BAT
Ce qui s'est toujours bien passé auparavant, et continue aujourd'hui à bien se dérouler, SAUF sur des machines toujours sous W98 (non, les clients n'ont pas tous W2000 ou Xp). J'ai donc reconfiguré une vieille bécane qui traînait (PII 400, 256 Mb) sous W98, et fait le test moi-même, ce qui m'a permis de réaliser que sous W98, la migration, une fois lancée, s'enclenche bien, mais lorsqu'elle atteint les niveaux 62 et suivants de l'analyse, là où, sous un autre Windows, la moulinette s'enclenche, c'est ici le mutisme complet, SAUF pour la dernière version (65) où seul le dernier fichier dont la structure a été modifiée subit la migration (en effet, l'évolution de 64 > 65 implique plusieurs fichiers modifiés, mais seul le dernier paraît détecté...).
Dernier détail, le WDMODFIC.EXE utilisé est bien toujours le même que les précédentes fois, il s'agit de celui dont voici les propriétés: Taille : 229.776 octets Date : 17/01/2001 à 16:36 Version : 5.50Bk
Connaissez-vous le cas ? Si oui, l'explication existe-t-elle ? Quelle est-elle en ce cas ?
Merci d'avance de vos lumières et expériences sur ce sujet qui me coince très désagréablement pour le moment...
Amicalement, Patrick ;-((
bonjour
ne serait pas du à un/des fichiers avec des noms longs et ne respectant pas la structure 8.3 (ou était-ce 5.3) ?
titou44 chez freesurf.fr
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Patrick COQUE avait soumis l'idée :
Salut à tous,
j'ai un truc bizarre :
sur un programme d'une dizaine d'années, commercialisé actuellement en WD
5.5b, et en cours de migration vers WD9, j'ai un comportement de WDMODFIC
que je ne m'explique pas.
En effet, depuis sa création, ce programme a vu son analyse évoluer
constamment; ce n'est pas par mauvaise analyse initiale, mais bien parce que
ce programme, relatif au domaine administratif médical, dépend donc des lois
qui ne cessent d'évoluer d'année en année...
Aujourd'hui donc, il passe d'une version 62 à la 65, et la moulinette est
lancée automatiquement par le biais d'un batch MODFIC.BAT, qui est repris ci
dessous :
---------- MODFIC.BAT
@echo off
set reper=%cd%
wdmodfic "ANALYSE.WD5" /WD /F /INST /NOLOC /REP=%reper%
del %reper%*.bin > %reper%62_65.txt
---------- Fin du MODFIC.BAT
Ce qui s'est toujours bien passé auparavant, et continue aujourd'hui à bien
se dérouler, SAUF sur des machines toujours sous W98 (non, les clients n'ont
pas tous W2000 ou Xp).
J'ai donc reconfiguré une vieille bécane qui traînait (PII 400, 256 Mb) sous
W98, et fait le test moi-même, ce qui m'a permis de réaliser que sous W98,
la migration, une fois lancée, s'enclenche bien, mais lorsqu'elle atteint
les niveaux 62 et suivants de l'analyse, là où, sous un autre Windows, la
moulinette s'enclenche, c'est ici le mutisme complet, SAUF pour la dernière
version (65) où seul le dernier fichier dont la structure a été modifiée
subit la migration (en effet, l'évolution de 64 > 65 implique plusieurs
fichiers modifiés, mais seul le dernier paraît détecté...).
Dernier détail, le WDMODFIC.EXE utilisé est bien toujours le même que les
précédentes fois, il s'agit de celui dont voici les propriétés:
Taille : 229.776 octets
Date : 17/01/2001 à 16:36
Version : 5.50Bk
Connaissez-vous le cas ?
Si oui, l'explication existe-t-elle ? Quelle est-elle en ce cas ?
Merci d'avance de vos lumières et expériences sur ce sujet qui me coince
très désagréablement pour le moment...
Amicalement,
Patrick ;-((
bonjour
ne serait pas du à un/des fichiers avec des noms longs et ne respectant
pas la structure 8.3 (ou était-ce 5.3) ?
titou44 chez freesurf.fr
--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com
j'ai un truc bizarre : sur un programme d'une dizaine d'années, commercialisé actuellement en WD 5.5b, et en cours de migration vers WD9, j'ai un comportement de WDMODFIC que je ne m'explique pas.
En effet, depuis sa création, ce programme a vu son analyse évoluer constamment; ce n'est pas par mauvaise analyse initiale, mais bien parce que ce programme, relatif au domaine administratif médical, dépend donc des lois qui ne cessent d'évoluer d'année en année...
Aujourd'hui donc, il passe d'une version 62 à la 65, et la moulinette est lancée automatiquement par le biais d'un batch MODFIC.BAT, qui est repris ci dessous :
---------- MODFIC.BAT
@echo off set reper=%cd% wdmodfic "ANALYSE.WD5" /WD /F /INST /NOLOC /REP=%reper% del %reper%*.bin > %reper%62_65.txt
---------- Fin du MODFIC.BAT
Ce qui s'est toujours bien passé auparavant, et continue aujourd'hui à bien se dérouler, SAUF sur des machines toujours sous W98 (non, les clients n'ont pas tous W2000 ou Xp). J'ai donc reconfiguré une vieille bécane qui traînait (PII 400, 256 Mb) sous W98, et fait le test moi-même, ce qui m'a permis de réaliser que sous W98, la migration, une fois lancée, s'enclenche bien, mais lorsqu'elle atteint les niveaux 62 et suivants de l'analyse, là où, sous un autre Windows, la moulinette s'enclenche, c'est ici le mutisme complet, SAUF pour la dernière version (65) où seul le dernier fichier dont la structure a été modifiée subit la migration (en effet, l'évolution de 64 > 65 implique plusieurs fichiers modifiés, mais seul le dernier paraît détecté...).
Dernier détail, le WDMODFIC.EXE utilisé est bien toujours le même que les précédentes fois, il s'agit de celui dont voici les propriétés: Taille : 229.776 octets Date : 17/01/2001 à 16:36 Version : 5.50Bk
Connaissez-vous le cas ? Si oui, l'explication existe-t-elle ? Quelle est-elle en ce cas ?
Merci d'avance de vos lumières et expériences sur ce sujet qui me coince très désagréablement pour le moment...
Amicalement, Patrick ;-((
bonjour
ne serait pas du à un/des fichiers avec des noms longs et ne respectant pas la structure 8.3 (ou était-ce 5.3) ?
titou44 chez freesurf.fr
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Patrick COQUE
> bonjour
ne serait pas du à un/des fichiers avec des noms longs et ne respectant pas la structure 8.3 (ou était-ce 5.3) ?
titou44 chez freesurf.fr
Salut et, avant tout, merci de ta réponse,
mais non, il n'y a pas de fichier autre que 8.3. "Vieux" développeur (aventure commencée avec du Zx 81...) j'ai gardé la vielle habitude du 8.3 dans mon développement (en tout cas, en ce qui concerne les fichiers car pour ce qui est des noms de fenêtres, évidemment, j'allonge, et c'est très pratique!...). Ce n'est donc pas là que réside, je crois, la cause de mon problème...
Amicalement, Patrick ;-)
> bonjour
ne serait pas du à un/des fichiers avec des noms longs et ne respectant
pas la structure 8.3 (ou était-ce 5.3) ?
titou44 chez freesurf.fr
Salut et, avant tout, merci de ta réponse,
mais non, il n'y a pas de fichier autre que 8.3.
"Vieux" développeur (aventure commencée avec du Zx 81...) j'ai gardé la
vielle habitude du 8.3 dans mon développement (en tout cas, en ce qui
concerne les fichiers car pour ce qui est des noms de fenêtres, évidemment,
j'allonge, et c'est très pratique!...).
Ce n'est donc pas là que réside, je crois, la cause de mon problème...
ne serait pas du à un/des fichiers avec des noms longs et ne respectant pas la structure 8.3 (ou était-ce 5.3) ?
titou44 chez freesurf.fr
Salut et, avant tout, merci de ta réponse,
mais non, il n'y a pas de fichier autre que 8.3. "Vieux" développeur (aventure commencée avec du Zx 81...) j'ai gardé la vielle habitude du 8.3 dans mon développement (en tout cas, en ce qui concerne les fichiers car pour ce qui est des noms de fenêtres, évidemment, j'allonge, et c'est très pratique!...). Ce n'est donc pas là que réside, je crois, la cause de mon problème...
Amicalement, Patrick ;-)
Patrick COQUE
Salut,
après pas mal de recherches (cela faisait déjà 2 jours déjà que je séchais sur le sujet avant mon post de ce matin...), j'ai cerné le problème : il est dans le batch que je rappelle ici : ---------- MODFIC.BAT
@echo off set reper=%cd% wdmodfic "ANALYSE.WD5" /WD /F /INST /NOLOC /REP=%reper% del %reper%*.bin > %reper%62_65.txt
---------- Fin du MODFIC.BAT bien que ce batch n'ait pas posé de problème précédemment, il apparaît que la variable " reper " qui est supposée accueillir le répertoire courant restitué par le %cd% est simplement vide... d'où les problèmes survenant lors de son appel à la ligne suivante.
Alors, ai-je une modification du batch que je ne perçois pas (il a été repris tel quel d'un précédent envoi lors du passage de la version 60 à la 62, effectué sans problème...) ou mes notions de DOS (qui vieillissent...) ne me laissent-elles pas percevoir mon erreur dans cette syntaxe?...
Le fait est que la solution sera simple dans mon cas: au démarrage de la nouvelle version, avant l'appel du batch, je vais le créer directement en fichier texte depuis Windev, avec le répertoire courant en clair dedans. Le lancement consécutif devrait alors se dérouler sans plus de problème car le test du même batch, où j'ai noté en clair le répertoire, plutôt que par la variable %reper% réalise la moulinette des fichiers sans aucun couac.
Toujours bon à savoir...
Merci à tout qui aurait été interpellé par mon problème. (et spécialement toi, titou44, ayant émis une hypothèse de solution)
Amicalement, Patrick ;-)))
Salut,
après pas mal de recherches (cela faisait déjà 2 jours déjà que je séchais
sur le sujet avant mon post de ce matin...), j'ai cerné le problème :
il est dans le batch que je rappelle ici :
---------- MODFIC.BAT
@echo off
set reper=%cd%
wdmodfic "ANALYSE.WD5" /WD /F /INST /NOLOC /REP=%reper%
del %reper%*.bin > %reper%62_65.txt
---------- Fin du MODFIC.BAT
bien que ce batch n'ait pas posé de problème précédemment, il apparaît que
la variable " reper " qui est supposée accueillir le répertoire courant
restitué par le %cd% est simplement vide... d'où les problèmes survenant
lors de son appel à la ligne suivante.
Alors, ai-je une modification du batch que je ne perçois pas (il a été
repris tel quel d'un précédent envoi lors du passage de la version 60 à la
62, effectué sans problème...)
ou mes notions de DOS (qui vieillissent...) ne me laissent-elles pas
percevoir mon erreur dans cette syntaxe?...
Le fait est que la solution sera simple dans mon cas: au démarrage de la
nouvelle version, avant l'appel du batch, je vais le créer directement en
fichier texte depuis Windev, avec le répertoire courant en clair dedans. Le
lancement consécutif devrait alors se dérouler sans plus de problème car le
test du même batch, où j'ai noté en clair le répertoire, plutôt que par la
variable %reper% réalise la moulinette des fichiers sans aucun couac.
Toujours bon à savoir...
Merci à tout qui aurait été interpellé par mon problème.
(et spécialement toi, titou44, ayant émis une hypothèse de solution)
après pas mal de recherches (cela faisait déjà 2 jours déjà que je séchais sur le sujet avant mon post de ce matin...), j'ai cerné le problème : il est dans le batch que je rappelle ici : ---------- MODFIC.BAT
@echo off set reper=%cd% wdmodfic "ANALYSE.WD5" /WD /F /INST /NOLOC /REP=%reper% del %reper%*.bin > %reper%62_65.txt
---------- Fin du MODFIC.BAT bien que ce batch n'ait pas posé de problème précédemment, il apparaît que la variable " reper " qui est supposée accueillir le répertoire courant restitué par le %cd% est simplement vide... d'où les problèmes survenant lors de son appel à la ligne suivante.
Alors, ai-je une modification du batch que je ne perçois pas (il a été repris tel quel d'un précédent envoi lors du passage de la version 60 à la 62, effectué sans problème...) ou mes notions de DOS (qui vieillissent...) ne me laissent-elles pas percevoir mon erreur dans cette syntaxe?...
Le fait est que la solution sera simple dans mon cas: au démarrage de la nouvelle version, avant l'appel du batch, je vais le créer directement en fichier texte depuis Windev, avec le répertoire courant en clair dedans. Le lancement consécutif devrait alors se dérouler sans plus de problème car le test du même batch, où j'ai noté en clair le répertoire, plutôt que par la variable %reper% réalise la moulinette des fichiers sans aucun couac.
Toujours bon à savoir...
Merci à tout qui aurait été interpellé par mon problème. (et spécialement toi, titou44, ayant émis une hypothèse de solution)
Amicalement, Patrick ;-)))
titou44
Patrick COQUE vient de nous annoncer :
Salut,
après pas mal de recherches (cela faisait déjà 2 jours déjà que je séchais sur le sujet avant mon post de ce matin...), j'ai cerné le problème : il est dans le batch que je rappelle ici : ---------- MODFIC.BAT
@echo off set reper=%cd% wdmodfic "ANALYSE.WD5" /WD /F /INST /NOLOC /REP=%reper% del %reper%*.bin > %reper%62_65.txt
---------- Fin du MODFIC.BAT bien que ce batch n'ait pas posé de problème précédemment, il apparaît que la variable " reper " qui est supposée accueillir le répertoire courant restitué par le %cd% est simplement vide... d'où les problèmes survenant lors de son appel à la ligne suivante.
Alors, ai-je une modification du batch que je ne perçois pas (il a été repris tel quel d'un précédent envoi lors du passage de la version 60 à la 62, effectué sans problème...) ou mes notions de DOS (qui vieillissent...) ne me laissent-elles pas percevoir mon erreur dans cette syntaxe?...
Le fait est que la solution sera simple dans mon cas: au démarrage de la nouvelle version, avant l'appel du batch, je vais le créer directement en fichier texte depuis Windev, avec le répertoire courant en clair dedans. Le lancement consécutif devrait alors se dérouler sans plus de problème car le test du même batch, où j'ai noté en clair le répertoire, plutôt que par la variable %reper% réalise la moulinette des fichiers sans aucun couac.
Toujours bon à savoir...
Merci à tout qui aurait été interpellé par mon problème. (et spécialement toi, titou44, ayant émis une hypothèse de solution)
Amicalement, Patrick ;-)))
merci pour le merci.
et surtout merci de nous donner la solution. il n'y a rien de plus frustant que d'essayer de participer à la résolution d'un problème et de : -soit ne plus avoir de nouvelles du posteur d'origine -soit d'avoir un message de type "j'ai trouvé" sans nous donner la solution. qui peut, elle, intéresser tout le monde !
titou44 chez freesurf.fr
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Patrick COQUE vient de nous annoncer :
Salut,
après pas mal de recherches (cela faisait déjà 2 jours déjà que je séchais
sur le sujet avant mon post de ce matin...), j'ai cerné le problème :
il est dans le batch que je rappelle ici :
---------- MODFIC.BAT
@echo off
set reper=%cd%
wdmodfic "ANALYSE.WD5" /WD /F /INST /NOLOC /REP=%reper%
del %reper%*.bin > %reper%62_65.txt
---------- Fin du MODFIC.BAT
bien que ce batch n'ait pas posé de problème précédemment, il apparaît que
la variable " reper " qui est supposée accueillir le répertoire courant
restitué par le %cd% est simplement vide... d'où les problèmes survenant
lors de son appel à la ligne suivante.
Alors, ai-je une modification du batch que je ne perçois pas (il a été
repris tel quel d'un précédent envoi lors du passage de la version 60 à la
62, effectué sans problème...)
ou mes notions de DOS (qui vieillissent...) ne me laissent-elles pas
percevoir mon erreur dans cette syntaxe?...
Le fait est que la solution sera simple dans mon cas: au démarrage de la
nouvelle version, avant l'appel du batch, je vais le créer directement en
fichier texte depuis Windev, avec le répertoire courant en clair dedans. Le
lancement consécutif devrait alors se dérouler sans plus de problème car le
test du même batch, où j'ai noté en clair le répertoire, plutôt que par la
variable %reper% réalise la moulinette des fichiers sans aucun couac.
Toujours bon à savoir...
Merci à tout qui aurait été interpellé par mon problème.
(et spécialement toi, titou44, ayant émis une hypothèse de solution)
Amicalement,
Patrick ;-)))
merci pour le merci.
et surtout merci de nous donner la solution.
il n'y a rien de plus frustant que d'essayer de participer à la
résolution d'un problème et de :
-soit ne plus avoir de nouvelles du posteur d'origine
-soit d'avoir un message de type "j'ai trouvé" sans nous donner la
solution. qui peut, elle, intéresser tout le monde !
titou44 chez freesurf.fr
--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com
après pas mal de recherches (cela faisait déjà 2 jours déjà que je séchais sur le sujet avant mon post de ce matin...), j'ai cerné le problème : il est dans le batch que je rappelle ici : ---------- MODFIC.BAT
@echo off set reper=%cd% wdmodfic "ANALYSE.WD5" /WD /F /INST /NOLOC /REP=%reper% del %reper%*.bin > %reper%62_65.txt
---------- Fin du MODFIC.BAT bien que ce batch n'ait pas posé de problème précédemment, il apparaît que la variable " reper " qui est supposée accueillir le répertoire courant restitué par le %cd% est simplement vide... d'où les problèmes survenant lors de son appel à la ligne suivante.
Alors, ai-je une modification du batch que je ne perçois pas (il a été repris tel quel d'un précédent envoi lors du passage de la version 60 à la 62, effectué sans problème...) ou mes notions de DOS (qui vieillissent...) ne me laissent-elles pas percevoir mon erreur dans cette syntaxe?...
Le fait est que la solution sera simple dans mon cas: au démarrage de la nouvelle version, avant l'appel du batch, je vais le créer directement en fichier texte depuis Windev, avec le répertoire courant en clair dedans. Le lancement consécutif devrait alors se dérouler sans plus de problème car le test du même batch, où j'ai noté en clair le répertoire, plutôt que par la variable %reper% réalise la moulinette des fichiers sans aucun couac.
Toujours bon à savoir...
Merci à tout qui aurait été interpellé par mon problème. (et spécialement toi, titou44, ayant émis une hypothèse de solution)
Amicalement, Patrick ;-)))
merci pour le merci.
et surtout merci de nous donner la solution. il n'y a rien de plus frustant que d'essayer de participer à la résolution d'un problème et de : -soit ne plus avoir de nouvelles du posteur d'origine -soit d'avoir un message de type "j'ai trouvé" sans nous donner la solution. qui peut, elle, intéresser tout le monde !
titou44 chez freesurf.fr
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
