J'ai récemment acheté la mise à jour vers WD8 et comme je m'attendais,
c'était nullement question de compiler et continuer avec l'ordre du jour.
Comme souvent avec WD, le problème ne sont pas nécessairement des bugs
mais des changements de comportement. Après compilation, j'ai rencontré
les problèmes suivants:
1) Plantage sur la commande HOptimiseRequête: je n'ai pas vu pourquoi et
les ai tout simplement supprimé. Je n'ai de toute façon jamais remarqué
de vrais améliorations de performances en WD7.5.
2) Plantages sur HLitRecherchePremière: la raison étaient des
valeurs de recherche alimenté par des combos avec "Null si vide" coché.
Dans WD 7.5 HLitRecherchePremière renvoyait simplement "Faux" ce qui me
semble toujours une solution adéquate.
On peut dire que la faute est dans mon code. Mais puisque WD 7.5 ne les
réclamais pas ces erreurs, alors comment peut-on dire qu'il suffit de
compiler un projet pour passer à WD8? Il faut au contraire le tester de
A à Z afin d'éviter des mauvaises surprises en clientèle!
En plus, avant de trouver la source de l'ennui, je me suis apperçu que
ce n'est pas si facile de filtrer la valeur Null. "Si MonChamp = Null
ALORS RETOUR" ne sert à rien; dès qu'il y a la valeur Null il n'y a plus
de test. Ca sert à quoi avoir la valeur Null dans HF si je ne peux pas
la tester? Est-ce que quelque chose m'échappe? Et attention: depuis ma
rectification de la combo c'est quoi la valeur de retour pour un entier
non signé avec comme valeur par défaut de 0 dans l'analyse? Bien
évidemment "", et ça passe sans problèmes comme valeur de recherche dans
HLitRecherchePremier, qui renvoie "Faux" comme auparavant aussi pour
Null... Si vous le considérez normal, OK, moi pas.
Autre chose, je ne comprends pas les messages disant que WD8 est plus
stable. Je travaille sous W2K Pro avec 512MB de RAM et je suis renvoyé
sur le bureau de Windows au moins autant de fois qu'avec WD7.5, la
raison étant vraisemblablement la même depuis bien deux ans: l'usage
extensif de procédures globales entraine un fort risque de plantage
total de WD7.5/8 lorsque WD veut enregistrer des modifications et que
ces objets ne sont pas déjà ouverts. Ceci surtout lorsque les messages
multi-lingues sont concernés. PCS sont au courant de ce bug depuis très,
très longtemps, mais soit ils sont incapables de le remédier, soit ils
s'en fichent.
Pire encore, je commence à faire la même expérience avec les méthodes
des classes.
Autres observations:
- je trouve triste que WD ne reprend pas la configuration de
l'éditeur de code (couleurs). En plus, les couleurs et polices sont
toujours pénibles à régler comparé à WD5.5 où on voyait toutes les
couleurs des différents types de code dans une table, au lieu de devoir
passer par une combo, une par une.
- l'exemple des fichiers index excessifs de WD/HF a trouvé une
continuation. J'ai laissé optimiser WD8 mes requêtes et sur mon exemple
de fichier avec 5.4MB de données, 19 index et un NDX de 10MB, WD8 a
rajouté 5 index composés, couvrant de 4 à 6 rubriques. Le fichier NDX a
maintenant 15.8MB pour toujours 5.4MB de données. Les perfs des
requêttes sur ce fichier étaient déjà bonnes et n'ont pour ainsi dire
pas changés. Les performances d'autres fenêtres sont devenues un peu
meilleures mais loins des facteurs cités par certains gens. Grace aux
coût bas de l'espace disque on peux payer le prix, mais toujours est-il
que d'autres produits n'ont pas besoin d'autant d'index pour donner
performances égaux ou meilleures.
Donc, le changement vers WD8 s'est fait dans le cadre de mes attentes.
Mais il s'agit bien d'une migration et je ne suis pas encore tranquille
car pour l'instant je n'ai pas testé en détail le comportement des
combos et tables, où on trouvait par le passée des inconsistences dans
les valeurs renvoyées d'une version à l'autre. Après une semaine de
travail, je n'ai pas noté une vraie amélioration par rapport à la 7.5
206h en ce qui concerne les mêmes fonctions et j'ai l'intention
d'attendre quelques mois avant de toucher au nouvelles.
J'ai récemment acheté la mise à jour vers WD8 et comme je m'attendais, c'était nullement question de compiler et continuer avec l'ordre du jour.
Merci pour ces infos précieuses qui m'ont peut être évité de faire une bétise.
J'ai un projet assez conséquent en 7.5 et je suis quasiment obligé de passer en 8. Mais étant donné que j'ai des délais à respecter, je vais attendre que l'appli soit livrée (en 7.5) pour 'migrer sans migration' après quand j'aurai plus de temps pour corriger les conneries (les miennes ou celles de PC$).
On va voir les réactions de ceux qui ont déjà l'expérience.
A+ Jan Van Wijk
Salut,
J'ai récemment acheté la mise à jour vers WD8 et comme je m'attendais,
c'était nullement question de compiler et continuer avec l'ordre du jour.
Merci pour ces infos précieuses qui m'ont peut être évité de faire une
bétise.
J'ai un projet assez conséquent en 7.5 et je suis quasiment obligé de passer
en 8. Mais étant donné que j'ai des délais à respecter, je vais attendre que
l'appli soit livrée (en 7.5) pour 'migrer sans migration' après quand
j'aurai plus de temps pour corriger les conneries (les miennes ou celles de
PC$).
On va voir les réactions de ceux qui ont déjà l'expérience.
J'ai récemment acheté la mise à jour vers WD8 et comme je m'attendais, c'était nullement question de compiler et continuer avec l'ordre du jour.
Merci pour ces infos précieuses qui m'ont peut être évité de faire une bétise.
J'ai un projet assez conséquent en 7.5 et je suis quasiment obligé de passer en 8. Mais étant donné que j'ai des délais à respecter, je vais attendre que l'appli soit livrée (en 7.5) pour 'migrer sans migration' après quand j'aurai plus de temps pour corriger les conneries (les miennes ou celles de PC$).
On va voir les réactions de ceux qui ont déjà l'expérience.
A+ Jan Van Wijk
Roumegou
Salut Mat, Merci pour ce retour d'expérience détaillé.
mat a exprimé avec précision :
Bonjour,
J'ai récemment acheté la mise à jour vers WD8 et comme je m'attendais, c'était nullement question de compiler et continuer avec l'ordre du jour.
Qui l'eut cru ? [nostalfie]Ce genre de promesses, je n'ai vu qu'IBM la respecter avec sa série 3X-AS400 [/nostalgie]
Comme souvent avec WD, le problème ne sont pas nécessairement des bugs mais des changements de comportement. Après compilation, j'ai rencontré les problèmes suivants:
1) Plantage sur la commande HOptimiseRequête: je n'ai pas vu pourquoi et les ai tout simplement supprimé. Je n'ai de toute façon jamais remarqué de vrais améliorations de performances en WD7.5.
2) Plantages sur HLitRecherchePremière: la raison étaient des valeurs de recherche alimenté par des combos avec "Null si vide" coché. Dans WD 7.5 HLitRecherchePremière renvoyait simplement "Faux" ce qui me semble toujours une solution adéquate.
On peut dire que la faute est dans mon code. Mais puisque WD 7.5 ne les réclamais pas ces erreurs, alors comment peut-on dire qu'il suffit de compiler un projet pour passer à WD8? Il faut au contraire le tester de A à Z afin d'éviter des mauvaises surprises en clientèle!
En plus, avant de trouver la source de l'ennui, je me suis apperçu que ce n'est pas si facile de filtrer la valeur Null. "Si MonChamp = Null ALORS RETOUR" ne sert à rien; dès qu'il y a la valeur Null il n'y a plus de test.
Normalement le test d'egalité avec la valeur null devrait fonctionner. Par contre Mavaleur<>1 ne séelectionnera pas les valeurs null car le test ne se fait pas Enfin dans une commande SQL
Ca sert à quoi avoir la valeur Null dans HF si je ne peux pas la tester? Est-ce que quelque chose m'échappe? Et attention: depuis ma rectification de la combo c'est quoi la valeur de retour pour un entier non signé avec comme valeur par défaut de 0 dans l'analyse? Bien évidemment "", et ça passe sans problèmes comme valeur de recherche dans HLitRecherchePremier, qui renvoie "Faux" comme auparavant aussi pour Null... Si vous le considérez normal, OK, moi pas.
Ah la valeur Null! à chacun sa vérité quelque fois.(moi je me range à celle d'Oracle qui à quand meme inventé ou tout au moins utilisé les premiers cette notion) N'existe-t-il pas en HF une instruction de conversion de valeur nulle genre NVL ou COALESCE.
Autre chose, je ne comprends pas les messages disant que WD8 est plus stable. Je travaille sous W2K Pro avec 512MB de RAM et je suis renvoyé sur le bureau de Windows au moins autant de fois qu'avec WD7.5, la raison étant vraisemblablement la même depuis bien deux ans: l'usage extensif de procédures globales entraine un fort risque de plantage total de WD7.5/8 lorsque WD veut enregistrer des modifications et que ces objets ne sont pas déjà ouverts. Ceci surtout lorsque les messages multi-lingues sont concernés. PCS sont au courant de ce bug depuis très, très longtemps, mais soit ils sont incapables de le remédier, soit ils s'en fichent.
Ah un début de réponse. Moi qui me réjouissait de la stabilité de l'éditeur de WD75 depuis que je l'utilise. Depuis quelques mois, je déchante un peu et c'est depuis que j'ai beaucoup de collections de procédures globales et de classes partagées entre projets WD et Webdev. Tout était sur réseau et je viens de tout ramener en local avec des sauvegardes pour stabiliser un peu le tout. Sinon j'ai essayé le Dispo Hors Connexion de windows, et cela a été la cata.
Pire encore, je commence à faire la même expérience avec les méthodes des classes.
je confirme.
Autres observations:
- je trouve triste que WD ne reprend pas la configuration de l'éditeur de code (couleurs). En plus, les couleurs et polices sont toujours pénibles à régler comparé à WD5.5 où on voyait toutes les couleurs des différents types de code dans une table, au lieu de devoir passer par une combo, une par une.
Ca bouge par rapport à 7.5 ? ce que je trouvais parfait.
- l'exemple des fichiers index excessifs de WD/HF a trouvé une continuation. J'ai laissé optimiser WD8 mes requêtes et sur mon exemple de fichier avec 5.4MB de données, 19 index et un NDX de 10MB, WD8 a rajouté 5 index composés, couvrant de 4 à 6 rubriques. Le fichier NDX a maintenant 15.8MB pour toujours 5.4MB de données. Les perfs des requêttes sur ce fichier étaient déjà bonnes et n'ont pour ainsi dire pas changés. Les performances d'autres fenêtres sont devenues un peu meilleures mais loins des facteurs cités par certains gens. Grace aux coût bas de l'espace disque on peux payer le prix, mais toujours est-il que d'autres produits n'ont pas besoin d'autant d'index pour donner performances égaux ou meilleures.
et oui les SGBD dont c'est le métier.
Donc, le changement vers WD8 s'est fait dans le cadre de mes attentes. Mais il s'agit bien d'une migration et je ne suis pas encore tranquille car pour l'instant je n'ai pas testé en détail le comportement des combos et tables, où on trouvait par le passée des inconsistences dans les valeurs renvoyées d'une version à l'autre. Après une semaine de travail, je n'ai pas noté une vraie amélioration par rapport à la 7.5 206h en ce qui concerne les mêmes fonctions et j'ai l'intention d'attendre quelques mois avant de toucher au nouvelles.
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Salut Mat,
Merci pour ce retour d'expérience détaillé.
mat a exprimé avec précision :
Bonjour,
J'ai récemment acheté la mise à jour vers WD8 et comme je m'attendais,
c'était nullement question de compiler et continuer avec l'ordre du jour.
Qui l'eut cru ?
[nostalfie]Ce genre de promesses, je n'ai vu qu'IBM la respecter avec
sa série 3X-AS400 [/nostalgie]
Comme souvent avec WD, le problème ne sont pas nécessairement des bugs
mais des changements de comportement. Après compilation, j'ai rencontré
les problèmes suivants:
1) Plantage sur la commande HOptimiseRequête: je n'ai pas vu pourquoi et les
ai tout simplement supprimé. Je n'ai de toute façon jamais remarqué de vrais
améliorations de performances en WD7.5.
2) Plantages sur HLitRecherchePremière: la raison étaient des
valeurs de recherche alimenté par des combos avec "Null si vide" coché.
Dans WD 7.5 HLitRecherchePremière renvoyait simplement "Faux" ce qui me
semble toujours une solution adéquate.
On peut dire que la faute est dans mon code. Mais puisque WD 7.5 ne les
réclamais pas ces erreurs, alors comment peut-on dire qu'il suffit de
compiler un projet pour passer à WD8? Il faut au contraire le tester de A à Z
afin d'éviter des mauvaises surprises en clientèle!
En plus, avant de trouver la source de l'ennui, je me suis apperçu que ce
n'est pas si facile de filtrer la valeur Null. "Si MonChamp = Null ALORS
RETOUR" ne sert à rien; dès qu'il y a la valeur Null il n'y a plus de test.
Normalement le test d'egalité avec la valeur null devrait fonctionner.
Par contre Mavaleur<>1 ne séelectionnera pas les valeurs null car le
test ne se fait pas
Enfin dans une commande SQL
Ca sert à quoi avoir la valeur Null dans HF si je ne peux pas la tester?
Est-ce que quelque chose m'échappe? Et attention: depuis ma rectification de
la combo c'est quoi la valeur de retour pour un entier non signé avec comme
valeur par défaut de 0 dans l'analyse? Bien évidemment "", et ça passe sans
problèmes comme valeur de recherche dans HLitRecherchePremier, qui renvoie
"Faux" comme auparavant aussi pour Null... Si vous le considérez normal, OK,
moi pas.
Ah la valeur Null! à chacun sa vérité quelque fois.(moi je me range à
celle d'Oracle qui à quand meme inventé ou tout au moins utilisé les
premiers cette notion)
N'existe-t-il pas en HF une instruction de conversion de valeur nulle
genre NVL ou COALESCE.
Autre chose, je ne comprends pas les messages disant que WD8 est plus
stable. Je travaille sous W2K Pro avec 512MB de RAM et je suis renvoyé
sur le bureau de Windows au moins autant de fois qu'avec WD7.5, la
raison étant vraisemblablement la même depuis bien deux ans: l'usage extensif
de procédures globales entraine un fort risque de plantage total de WD7.5/8
lorsque WD veut enregistrer des modifications et que ces objets ne sont pas
déjà ouverts. Ceci surtout lorsque les messages multi-lingues sont concernés.
PCS sont au courant de ce bug depuis très, très longtemps, mais soit ils sont
incapables de le remédier, soit ils s'en fichent.
Ah un début de réponse.
Moi qui me réjouissait de la stabilité de l'éditeur de WD75 depuis que
je l'utilise. Depuis quelques mois, je déchante un peu et c'est depuis
que j'ai beaucoup de collections de procédures globales et de classes
partagées entre projets WD et Webdev. Tout était sur réseau et je viens
de tout ramener en local avec des sauvegardes pour stabiliser un peu le
tout.
Sinon j'ai essayé le Dispo Hors Connexion de windows, et cela a été la
cata.
Pire encore, je commence à faire la même expérience avec les méthodes
des classes.
je confirme.
Autres observations:
- je trouve triste que WD ne reprend pas la configuration de
l'éditeur de code (couleurs). En plus, les couleurs et polices sont
toujours pénibles à régler comparé à WD5.5 où on voyait toutes les
couleurs des différents types de code dans une table, au lieu de devoir
passer par une combo, une par une.
Ca bouge par rapport à 7.5 ? ce que je trouvais parfait.
- l'exemple des fichiers index excessifs de WD/HF a trouvé une
continuation. J'ai laissé optimiser WD8 mes requêtes et sur mon exemple
de fichier avec 5.4MB de données, 19 index et un NDX de 10MB, WD8 a
rajouté 5 index composés, couvrant de 4 à 6 rubriques. Le fichier NDX a
maintenant 15.8MB pour toujours 5.4MB de données. Les perfs des requêttes sur
ce fichier étaient déjà bonnes et n'ont pour ainsi dire pas changés. Les
performances d'autres fenêtres sont devenues un peu meilleures mais loins des
facteurs cités par certains gens. Grace aux coût bas de l'espace disque on
peux payer le prix, mais toujours est-il que d'autres produits n'ont pas
besoin d'autant d'index pour donner performances égaux ou meilleures.
et oui les SGBD dont c'est le métier.
Donc, le changement vers WD8 s'est fait dans le cadre de mes attentes. Mais
il s'agit bien d'une migration et je ne suis pas encore tranquille car pour
l'instant je n'ai pas testé en détail le comportement des combos et tables,
où on trouvait par le passée des inconsistences dans les valeurs renvoyées
d'une version à l'autre. Après une semaine de travail, je n'ai pas noté une
vraie amélioration par rapport à la 7.5 206h en ce qui concerne les mêmes
fonctions et j'ai l'intention d'attendre quelques mois avant de toucher au
nouvelles.
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Salut Mat, Merci pour ce retour d'expérience détaillé.
mat a exprimé avec précision :
Bonjour,
J'ai récemment acheté la mise à jour vers WD8 et comme je m'attendais, c'était nullement question de compiler et continuer avec l'ordre du jour.
Qui l'eut cru ? [nostalfie]Ce genre de promesses, je n'ai vu qu'IBM la respecter avec sa série 3X-AS400 [/nostalgie]
Comme souvent avec WD, le problème ne sont pas nécessairement des bugs mais des changements de comportement. Après compilation, j'ai rencontré les problèmes suivants:
1) Plantage sur la commande HOptimiseRequête: je n'ai pas vu pourquoi et les ai tout simplement supprimé. Je n'ai de toute façon jamais remarqué de vrais améliorations de performances en WD7.5.
2) Plantages sur HLitRecherchePremière: la raison étaient des valeurs de recherche alimenté par des combos avec "Null si vide" coché. Dans WD 7.5 HLitRecherchePremière renvoyait simplement "Faux" ce qui me semble toujours une solution adéquate.
On peut dire que la faute est dans mon code. Mais puisque WD 7.5 ne les réclamais pas ces erreurs, alors comment peut-on dire qu'il suffit de compiler un projet pour passer à WD8? Il faut au contraire le tester de A à Z afin d'éviter des mauvaises surprises en clientèle!
En plus, avant de trouver la source de l'ennui, je me suis apperçu que ce n'est pas si facile de filtrer la valeur Null. "Si MonChamp = Null ALORS RETOUR" ne sert à rien; dès qu'il y a la valeur Null il n'y a plus de test.
Normalement le test d'egalité avec la valeur null devrait fonctionner. Par contre Mavaleur<>1 ne séelectionnera pas les valeurs null car le test ne se fait pas Enfin dans une commande SQL
Ca sert à quoi avoir la valeur Null dans HF si je ne peux pas la tester? Est-ce que quelque chose m'échappe? Et attention: depuis ma rectification de la combo c'est quoi la valeur de retour pour un entier non signé avec comme valeur par défaut de 0 dans l'analyse? Bien évidemment "", et ça passe sans problèmes comme valeur de recherche dans HLitRecherchePremier, qui renvoie "Faux" comme auparavant aussi pour Null... Si vous le considérez normal, OK, moi pas.
Ah la valeur Null! à chacun sa vérité quelque fois.(moi je me range à celle d'Oracle qui à quand meme inventé ou tout au moins utilisé les premiers cette notion) N'existe-t-il pas en HF une instruction de conversion de valeur nulle genre NVL ou COALESCE.
Autre chose, je ne comprends pas les messages disant que WD8 est plus stable. Je travaille sous W2K Pro avec 512MB de RAM et je suis renvoyé sur le bureau de Windows au moins autant de fois qu'avec WD7.5, la raison étant vraisemblablement la même depuis bien deux ans: l'usage extensif de procédures globales entraine un fort risque de plantage total de WD7.5/8 lorsque WD veut enregistrer des modifications et que ces objets ne sont pas déjà ouverts. Ceci surtout lorsque les messages multi-lingues sont concernés. PCS sont au courant de ce bug depuis très, très longtemps, mais soit ils sont incapables de le remédier, soit ils s'en fichent.
Ah un début de réponse. Moi qui me réjouissait de la stabilité de l'éditeur de WD75 depuis que je l'utilise. Depuis quelques mois, je déchante un peu et c'est depuis que j'ai beaucoup de collections de procédures globales et de classes partagées entre projets WD et Webdev. Tout était sur réseau et je viens de tout ramener en local avec des sauvegardes pour stabiliser un peu le tout. Sinon j'ai essayé le Dispo Hors Connexion de windows, et cela a été la cata.
Pire encore, je commence à faire la même expérience avec les méthodes des classes.
je confirme.
Autres observations:
- je trouve triste que WD ne reprend pas la configuration de l'éditeur de code (couleurs). En plus, les couleurs et polices sont toujours pénibles à régler comparé à WD5.5 où on voyait toutes les couleurs des différents types de code dans une table, au lieu de devoir passer par une combo, une par une.
Ca bouge par rapport à 7.5 ? ce que je trouvais parfait.
- l'exemple des fichiers index excessifs de WD/HF a trouvé une continuation. J'ai laissé optimiser WD8 mes requêtes et sur mon exemple de fichier avec 5.4MB de données, 19 index et un NDX de 10MB, WD8 a rajouté 5 index composés, couvrant de 4 à 6 rubriques. Le fichier NDX a maintenant 15.8MB pour toujours 5.4MB de données. Les perfs des requêttes sur ce fichier étaient déjà bonnes et n'ont pour ainsi dire pas changés. Les performances d'autres fenêtres sont devenues un peu meilleures mais loins des facteurs cités par certains gens. Grace aux coût bas de l'espace disque on peux payer le prix, mais toujours est-il que d'autres produits n'ont pas besoin d'autant d'index pour donner performances égaux ou meilleures.
et oui les SGBD dont c'est le métier.
Donc, le changement vers WD8 s'est fait dans le cadre de mes attentes. Mais il s'agit bien d'une migration et je ne suis pas encore tranquille car pour l'instant je n'ai pas testé en détail le comportement des combos et tables, où on trouvait par le passée des inconsistences dans les valeurs renvoyées d'une version à l'autre. Après une semaine de travail, je n'ai pas noté une vraie amélioration par rapport à la 7.5 206h en ce qui concerne les mêmes fonctions et j'ai l'intention d'attendre quelques mois avant de toucher au nouvelles.
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Philippe
> Qui l'eut cru ? [nostalfie]Ce genre de promesses, je n'ai vu qu'IBM la respecter avec sa série 3X-AS400 [/nostalgie] >
Tu me rappelles là le passage du CICS au RISC ! C'est pas PC$ qui serait capable de nous pondre des routines capables changer d'architecture et de recompiler tout les programmes sans autre formalités !
Philippe
> Qui l'eut cru ?
[nostalfie]Ce genre de promesses, je n'ai vu qu'IBM la respecter avec
sa série 3X-AS400 [/nostalgie]
>
Tu me rappelles là le passage du CICS au RISC ! C'est pas PC$ qui serait
capable de nous pondre des routines capables changer d'architecture et de
recompiler tout les programmes sans autre formalités !
> Qui l'eut cru ? [nostalfie]Ce genre de promesses, je n'ai vu qu'IBM la respecter avec sa série 3X-AS400 [/nostalgie] >
Tu me rappelles là le passage du CICS au RISC ! C'est pas PC$ qui serait capable de nous pondre des routines capables changer d'architecture et de recompiler tout les programmes sans autre formalités !
Philippe
Roumegou
Philippe a formulé la demande :
Qui l'eut cru ? [nostalfie]Ce genre de promesses, je n'ai vu qu'IBM la respecter avec sa série 3X-AS400 [/nostalgie]
Tu me rappelles là le passage du CICS au RISC ! C'est pas PC$ qui serait capable de nous pondre des routines capables changer d'architecture et de recompiler tout les programmes sans autre formalités !
C'est certainement pas les memes moyens non plus entre Rochester et Montpellier, et je dirais que Pcsoft ne s'en tire pas trop mal.
Mais c'est vrai que la migration en question avait été bluffante
Philippe
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Philippe a formulé la demande :
Qui l'eut cru ?
[nostalfie]Ce genre de promesses, je n'ai vu qu'IBM la respecter avec
sa série 3X-AS400 [/nostalgie]
Tu me rappelles là le passage du CICS au RISC ! C'est pas PC$ qui serait
capable de nous pondre des routines capables changer d'architecture et de
recompiler tout les programmes sans autre formalités !
C'est certainement pas les memes moyens non plus entre Rochester et
Montpellier, et je dirais que Pcsoft ne s'en tire pas trop mal.
Mais c'est vrai que la migration en question avait été bluffante
Philippe
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Qui l'eut cru ? [nostalfie]Ce genre de promesses, je n'ai vu qu'IBM la respecter avec sa série 3X-AS400 [/nostalgie]
Tu me rappelles là le passage du CICS au RISC ! C'est pas PC$ qui serait capable de nous pondre des routines capables changer d'architecture et de recompiler tout les programmes sans autre formalités !
C'est certainement pas les memes moyens non plus entre Rochester et Montpellier, et je dirais que Pcsoft ne s'en tire pas trop mal.
Mais c'est vrai que la migration en question avait été bluffante
Philippe
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Philippe
> C'est certainement pas les memes moyens non plus entre Rochester et Montpellier, et je dirais que Pcsoft ne s'en tire pas trop mal.
Là c'est vrai :) mais il pourrait faire encore mieux en consacrant son bubget à autre chose que de la publicité agressive et inutile .. Pied d'estale quand tu nous tiens !
Philippe
>
C'est certainement pas les memes moyens non plus entre Rochester et
Montpellier, et je dirais que Pcsoft ne s'en tire pas trop mal.
Là c'est vrai :) mais il pourrait faire encore mieux en consacrant son
bubget à autre chose que de la publicité agressive et inutile .. Pied
d'estale quand tu nous tiens !
> C'est certainement pas les memes moyens non plus entre Rochester et Montpellier, et je dirais que Pcsoft ne s'en tire pas trop mal.
Là c'est vrai :) mais il pourrait faire encore mieux en consacrant son bubget à autre chose que de la publicité agressive et inutile .. Pied d'estale quand tu nous tiens !
Philippe
mat
Roumegou wrote:
- je trouve triste que WD ne reprend pas la configuration de l'éditeur de code (couleurs). En plus, les couleurs et polices sont toujours pénibles à régler comparé à WD5.5 où on voyait toutes les couleurs des différents types de code dans une table, au lieu de devoir passer par une combo, une par une.
Ca bouge par rapport à 7.5 ? ce que je trouvais parfait.
Bonjour Eric, Non, j'espérais une amélioration à la 7.5 afin de voir de nouveau toutes les couleurs utilisés dans le code en une fois dans une table. Ma mémoire est si mauvaise qu'après une dizaine de positions, je ne me rappelle plus lesquelles j'ai déjà utilisé... :-)
Mat
Roumegou wrote:
- je trouve triste que WD ne reprend pas la configuration de
l'éditeur de code (couleurs). En plus, les couleurs et polices sont
toujours pénibles à régler comparé à WD5.5 où on voyait toutes les
couleurs des différents types de code dans une table, au lieu de devoir
passer par une combo, une par une.
Ca bouge par rapport à 7.5 ? ce que je trouvais parfait.
Bonjour Eric,
Non, j'espérais une amélioration à la 7.5 afin de voir de nouveau toutes
les couleurs utilisés dans le code en une fois dans une table. Ma
mémoire est si mauvaise qu'après une dizaine de positions, je ne me
rappelle plus lesquelles j'ai déjà utilisé... :-)
- je trouve triste que WD ne reprend pas la configuration de l'éditeur de code (couleurs). En plus, les couleurs et polices sont toujours pénibles à régler comparé à WD5.5 où on voyait toutes les couleurs des différents types de code dans une table, au lieu de devoir passer par une combo, une par une.
Ca bouge par rapport à 7.5 ? ce que je trouvais parfait.
Bonjour Eric, Non, j'espérais une amélioration à la 7.5 afin de voir de nouveau toutes les couleurs utilisés dans le code en une fois dans une table. Ma mémoire est si mauvaise qu'après une dizaine de positions, je ne me rappelle plus lesquelles j'ai déjà utilisé... :-)
Mat
SEINLET Nicolas
> Par contre Mavaleur<>1 ne séelectionnera pas les valeurs null car le test ne se fait pas Enfin dans une commande SQL
Dans une commande SQL, j'ai eu la bonne surprise de constater que <> ne correspondait pas à not = ... j'ai vait un test du genre "select nom from matable where matable.sonid<>"+matable2.sonid , et donc matable2.sonid correspond à l'id. prenons 10 comme exemple, et WD ressort tous les noms dont matable.sonid>10 ... fallait savoir que <> était interpreté comme > ...
> Par contre Mavaleur<>1 ne séelectionnera pas les valeurs null car le
test ne se fait pas
Enfin dans une commande SQL
Dans une commande SQL, j'ai eu la bonne surprise de constater que <> ne
correspondait pas à not = ...
j'ai vait un test du genre "select nom from matable where
matable.sonid<>"+matable2.sonid , et donc matable2.sonid correspond à l'id.
prenons 10 comme exemple, et WD ressort tous les noms dont matable.sonid>10
... fallait savoir que <> était interpreté comme > ...
> Par contre Mavaleur<>1 ne séelectionnera pas les valeurs null car le test ne se fait pas Enfin dans une commande SQL
Dans une commande SQL, j'ai eu la bonne surprise de constater que <> ne correspondait pas à not = ... j'ai vait un test du genre "select nom from matable where matable.sonid<>"+matable2.sonid , et donc matable2.sonid correspond à l'id. prenons 10 comme exemple, et WD ressort tous les noms dont matable.sonid>10 ... fallait savoir que <> était interpreté comme > ...
Roumegou
Salut Nicolas
SEINLET Nicolas avait énoncé :
Par contre Mavaleur<>1 ne séelectionnera pas les valeurs null car le test ne se fait pas Enfin dans une commande SQL
Dans une commande SQL, j'ai eu la bonne surprise de constater que <> ne correspondait pas à not = ... j'ai vait un test du genre "select nom from matable where matable.sonid<>"+matable2.sonid , et donc matable2.sonid correspond à l'id. prenons 10 comme exemple, et WD ressort tous les noms dont matable.sonid>10 ... fallait savoir que <> était interpreté comme > ...
et dans un message plus bas, tu préconises le hexecuterequetesql ????
pour le sql, je préfère m'en tenir aux comportements officiels des sgbd standards c.a.d. non trafiqués par des ordres propriétaires.
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Salut Nicolas
SEINLET Nicolas avait énoncé :
Par contre Mavaleur<>1 ne séelectionnera pas les valeurs null car le
test ne se fait pas
Enfin dans une commande SQL
Dans une commande SQL, j'ai eu la bonne surprise de constater que <> ne
correspondait pas à not = ...
j'ai vait un test du genre "select nom from matable where
matable.sonid<>"+matable2.sonid , et donc matable2.sonid correspond à l'id.
prenons 10 comme exemple, et WD ressort tous les noms dont matable.sonid>10
... fallait savoir que <> était interpreté comme > ...
et dans un message plus bas, tu préconises le hexecuterequetesql ????
pour le sql, je préfère m'en tenir aux comportements officiels des sgbd
standards
c.a.d. non trafiqués par des ordres propriétaires.
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Par contre Mavaleur<>1 ne séelectionnera pas les valeurs null car le test ne se fait pas Enfin dans une commande SQL
Dans une commande SQL, j'ai eu la bonne surprise de constater que <> ne correspondait pas à not = ... j'ai vait un test du genre "select nom from matable where matable.sonid<>"+matable2.sonid , et donc matable2.sonid correspond à l'id. prenons 10 comme exemple, et WD ressort tous les noms dont matable.sonid>10 ... fallait savoir que <> était interpreté comme > ...
et dans un message plus bas, tu préconises le hexecuterequetesql ????
pour le sql, je préfère m'en tenir aux comportements officiels des sgbd standards c.a.d. non trafiqués par des ordres propriétaires.
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Romain PETIT
mat a utilisé son clavier pour écrire :
Non, j'espérais une amélioration à la 7.5 afin de voir de nouveau toutes les couleurs utilisés dans le code en une fois dans une table. Ma mémoire est si mauvaise qu'après une dizaine de positions, je ne me rappelle plus lesquelles j'ai déjà utilisé... :-)
Essaye ça : - Lancer regedit - Exporter les paramétrages des couleurs des éditeurs : (empty) ou bien le code du USER (en focntion de si tu travaille avec ou sans login dans WD)
- ne garder dans le fichier .reg que les clés pour les couleurs de l'éditeur qui sont du style : ColorWLxxx (exemple ColorWLMember)
- voir si il y a des clés identiques pour WD8 (je n'ai pas WD8 donc je ne peux pas te confirmer cela) - modifier le fichier reg exporté (j'imagine qu'il suffit de remplacer 7.5 par 8)... - faire une sauvegarde de la branche HKEY_CURRENT_USERSoftwarePC SOFTWinDev8 (si c'est bien cette clé)... - double-cliquer pour enregistrer le .reg - relancer WD8 pour voir si ça a marché...
A+ (tiens-nous au courant)
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
mat a utilisé son clavier pour écrire :
Non, j'espérais une amélioration à la 7.5 afin de voir de nouveau toutes les
couleurs utilisés dans le code en une fois dans une table. Ma mémoire est si
mauvaise qu'après une dizaine de positions, je ne me rappelle plus lesquelles
j'ai déjà utilisé... :-)
Essaye ça :
- Lancer regedit
- Exporter les paramétrages des couleurs des éditeurs : (empty) ou bien
le code du USER (en focntion de si tu travaille avec ou sans login dans
WD)
- ne garder dans le fichier .reg que les clés pour les couleurs de
l'éditeur qui sont du style : ColorWLxxx (exemple ColorWLMember)
- voir si il y a des clés identiques pour WD8 (je n'ai pas WD8 donc je
ne peux pas te confirmer cela)
- modifier le fichier reg exporté (j'imagine qu'il suffit de remplacer
7.5 par 8)...
- faire une sauvegarde de la branche HKEY_CURRENT_USERSoftwarePC
SOFTWinDev8 (si c'est bien cette clé)...
- double-cliquer pour enregistrer le .reg
- relancer WD8 pour voir si ça a marché...
A+
(tiens-nous au courant)
--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)
Non, j'espérais une amélioration à la 7.5 afin de voir de nouveau toutes les couleurs utilisés dans le code en une fois dans une table. Ma mémoire est si mauvaise qu'après une dizaine de positions, je ne me rappelle plus lesquelles j'ai déjà utilisé... :-)
Essaye ça : - Lancer regedit - Exporter les paramétrages des couleurs des éditeurs : (empty) ou bien le code du USER (en focntion de si tu travaille avec ou sans login dans WD)
- ne garder dans le fichier .reg que les clés pour les couleurs de l'éditeur qui sont du style : ColorWLxxx (exemple ColorWLMember)
- voir si il y a des clés identiques pour WD8 (je n'ai pas WD8 donc je ne peux pas te confirmer cela) - modifier le fichier reg exporté (j'imagine qu'il suffit de remplacer 7.5 par 8)... - faire une sauvegarde de la branche HKEY_CURRENT_USERSoftwarePC SOFTWinDev8 (si c'est bien cette clé)... - double-cliquer pour enregistrer le .reg - relancer WD8 pour voir si ça a marché...
A+ (tiens-nous au courant)
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Adrien
Salut,
Est-ce qu'il t'arrive d'avoir des trucs interessant à dire ou ton plaisir c'est juste de poluer des forums ???
Pas A+ Adrien.
"Philippe" a écrit dans le message de news:4108baa5$0$31030$
> > C'est certainement pas les memes moyens non plus entre Rochester et > Montpellier, et je dirais que Pcsoft ne s'en tire pas trop mal. >
Là c'est vrai :) mais il pourrait faire encore mieux en consacrant son bubget à autre chose que de la publicité agressive et inutile .. Pied d'estale quand tu nous tiens !
Philippe
Salut,
Est-ce qu'il t'arrive d'avoir des trucs interessant à dire ou ton plaisir
c'est juste de poluer des forums ???
Pas A+
Adrien.
"Philippe" <lecitron@qpratools.com> a écrit dans le message de
news:4108baa5$0$31030$79c14f64@nan-newsreader-05.noos.net...
>
> C'est certainement pas les memes moyens non plus entre Rochester et
> Montpellier, et je dirais que Pcsoft ne s'en tire pas trop mal.
>
Là c'est vrai :) mais il pourrait faire encore mieux en consacrant son
bubget à autre chose que de la publicité agressive et inutile .. Pied
d'estale quand tu nous tiens !
Est-ce qu'il t'arrive d'avoir des trucs interessant à dire ou ton plaisir c'est juste de poluer des forums ???
Pas A+ Adrien.
"Philippe" a écrit dans le message de news:4108baa5$0$31030$
> > C'est certainement pas les memes moyens non plus entre Rochester et > Montpellier, et je dirais que Pcsoft ne s'en tire pas trop mal. >
Là c'est vrai :) mais il pourrait faire encore mieux en consacrant son bubget à autre chose que de la publicité agressive et inutile .. Pied d'estale quand tu nous tiens !
