Le 07/10/2004, Antoine a supposé :Tu as déjà eu différentes répoonse à ce sujet je crois.
Et alors ? je trouve que 15mn à 20mn pour générer une édition certes de 2700
pages mais partant d'un fichier de 3200 enregs (un fichier HF je précise),
sachant que cette édition ne fait aucun traitement ... cela ne relève pas
d'un comportement normal.
Que donnerait une édition Crystal Report là dessus ?Ta réponse est dans la question "une édition de 2700 pages", comment veux
tu que cela ne prenne pas de temps.
Ton spooler d'impression dois saturer au bon d'un moment.
je génère en html et j'ai le meme pb. J'espère que je ne passe pas par le
spooler d'impression là ?? (autre pb en html une image=multiplication des
.gif sur le disque donc 2700 fichiers là où 1 suffirait).
Et puis je fais cela sur une machine dotée de 768 MO de Ram, il devrait y
avoir ce qu'il faut non ?
Et sur des petites quantités, la cpu monte aussi à 100 %.
Je suis parti sur une solution déjà compliquée parce que ces éditions doivent
se lancer depuis un site WebDev donc s'executer sur le serveur en faisant
appel à un executable WinDev. Quand je vois que cela fait monter la cpu du
serveur à 100 % pendant 15mn pour un état, j'ai le droit légitime d'être
inquiet quand il y en aura une dizaine de demandés en meme temps non ?Tu as bien coché impression physique a chaque page ?
Ca c'est une information que je ne connaissais pas ? Mais je ne trouve pas
cette option dans les propriétés de l'état.
Je suis en WD75.
Antoine
Eric ... qui aimerait bien lui aussi poser moins de questions sur ce sujet
s'il n'avait pas de problèmes.
Roumegou Eric wrote:Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela prend
100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
Le 07/10/2004, Antoine a supposé :
Tu as déjà eu différentes répoonse à ce sujet je crois.
Et alors ? je trouve que 15mn à 20mn pour générer une édition certes de 2700
pages mais partant d'un fichier de 3200 enregs (un fichier HF je précise),
sachant que cette édition ne fait aucun traitement ... cela ne relève pas
d'un comportement normal.
Que donnerait une édition Crystal Report là dessus ?
Ta réponse est dans la question "une édition de 2700 pages", comment veux
tu que cela ne prenne pas de temps.
Ton spooler d'impression dois saturer au bon d'un moment.
je génère en html et j'ai le meme pb. J'espère que je ne passe pas par le
spooler d'impression là ?? (autre pb en html une image=multiplication des
.gif sur le disque donc 2700 fichiers là où 1 suffirait).
Et puis je fais cela sur une machine dotée de 768 MO de Ram, il devrait y
avoir ce qu'il faut non ?
Et sur des petites quantités, la cpu monte aussi à 100 %.
Je suis parti sur une solution déjà compliquée parce que ces éditions doivent
se lancer depuis un site WebDev donc s'executer sur le serveur en faisant
appel à un executable WinDev. Quand je vois que cela fait monter la cpu du
serveur à 100 % pendant 15mn pour un état, j'ai le droit légitime d'être
inquiet quand il y en aura une dizaine de demandés en meme temps non ?
Tu as bien coché impression physique a chaque page ?
Ca c'est une information que je ne connaissais pas ? Mais je ne trouve pas
cette option dans les propriétés de l'état.
Je suis en WD75.
Antoine
Eric ... qui aimerait bien lui aussi poser moins de questions sur ce sujet
s'il n'avait pas de problèmes.
Roumegou Eric wrote:
Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela prend
100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
Le 07/10/2004, Antoine a supposé :Tu as déjà eu différentes répoonse à ce sujet je crois.
Et alors ? je trouve que 15mn à 20mn pour générer une édition certes de 2700
pages mais partant d'un fichier de 3200 enregs (un fichier HF je précise),
sachant que cette édition ne fait aucun traitement ... cela ne relève pas
d'un comportement normal.
Que donnerait une édition Crystal Report là dessus ?Ta réponse est dans la question "une édition de 2700 pages", comment veux
tu que cela ne prenne pas de temps.
Ton spooler d'impression dois saturer au bon d'un moment.
je génère en html et j'ai le meme pb. J'espère que je ne passe pas par le
spooler d'impression là ?? (autre pb en html une image=multiplication des
.gif sur le disque donc 2700 fichiers là où 1 suffirait).
Et puis je fais cela sur une machine dotée de 768 MO de Ram, il devrait y
avoir ce qu'il faut non ?
Et sur des petites quantités, la cpu monte aussi à 100 %.
Je suis parti sur une solution déjà compliquée parce que ces éditions doivent
se lancer depuis un site WebDev donc s'executer sur le serveur en faisant
appel à un executable WinDev. Quand je vois que cela fait monter la cpu du
serveur à 100 % pendant 15mn pour un état, j'ai le droit légitime d'être
inquiet quand il y en aura une dizaine de demandés en meme temps non ?Tu as bien coché impression physique a chaque page ?
Ca c'est une information que je ne connaissais pas ? Mais je ne trouve pas
cette option dans les propriétés de l'état.
Je suis en WD75.
Antoine
Eric ... qui aimerait bien lui aussi poser moins de questions sur ce sujet
s'il n'avait pas de problèmes.
Roumegou Eric wrote:Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela prend
100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
Roumegou Eric a présenté l'énoncé suivant :Le 07/10/2004, Antoine a supposé :Tu as déjà eu différentes répoonse à ce sujet je crois.
Et alors ? je trouve que 15mn à 20mn pour générer une édition certes de
2700 pages mais partant d'un fichier de 3200 enregs (un fichier HF je
précise), sachant que cette édition ne fait aucun traitement ... cela ne
relève pas d'un comportement normal.
Que donnerait une édition Crystal Report là dessus ?Ta réponse est dans la question "une édition de 2700 pages", comment veux
tu que cela ne prenne pas de temps.
Ton spooler d'impression dois saturer au bon d'un moment.
je génère en html et j'ai le meme pb. J'espère que je ne passe pas par le
spooler d'impression là ?? (autre pb en html une image=multiplication des
.gif sur le disque donc 2700 fichiers là où 1 suffirait).
Et puis je fais cela sur une machine dotée de 768 MO de Ram, il devrait y
avoir ce qu'il faut non ?
Et sur des petites quantités, la cpu monte aussi à 100 %.
Je suis parti sur une solution déjà compliquée parce que ces éditions
doivent se lancer depuis un site WebDev donc s'executer sur le serveur en
faisant appel à un executable WinDev. Quand je vois que cela fait monter la
cpu du serveur à 100 % pendant 15mn pour un état, j'ai le droit légitime
d'être inquiet quand il y en aura une dizaine de demandés en meme temps non
?Tu as bien coché impression physique a chaque page ?
Ca c'est une information que je ne connaissais pas ? Mais je ne trouve pas
cette option dans les propriétés de l'état.
Je suis en WD75.
Antoine
Eric ... qui aimerait bien lui aussi poser moins de questions sur ce sujet
s'il n'avait pas de problèmes.
Roumegou Eric wrote:Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela prend
100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
Question peut-être idiote mais est ce que tes feuilles d'impressions
contiennent de images ou des pictogrammes..?
Roumegou Eric a présenté l'énoncé suivant :
Le 07/10/2004, Antoine a supposé :
Tu as déjà eu différentes répoonse à ce sujet je crois.
Et alors ? je trouve que 15mn à 20mn pour générer une édition certes de
2700 pages mais partant d'un fichier de 3200 enregs (un fichier HF je
précise), sachant que cette édition ne fait aucun traitement ... cela ne
relève pas d'un comportement normal.
Que donnerait une édition Crystal Report là dessus ?
Ta réponse est dans la question "une édition de 2700 pages", comment veux
tu que cela ne prenne pas de temps.
Ton spooler d'impression dois saturer au bon d'un moment.
je génère en html et j'ai le meme pb. J'espère que je ne passe pas par le
spooler d'impression là ?? (autre pb en html une image=multiplication des
.gif sur le disque donc 2700 fichiers là où 1 suffirait).
Et puis je fais cela sur une machine dotée de 768 MO de Ram, il devrait y
avoir ce qu'il faut non ?
Et sur des petites quantités, la cpu monte aussi à 100 %.
Je suis parti sur une solution déjà compliquée parce que ces éditions
doivent se lancer depuis un site WebDev donc s'executer sur le serveur en
faisant appel à un executable WinDev. Quand je vois que cela fait monter la
cpu du serveur à 100 % pendant 15mn pour un état, j'ai le droit légitime
d'être inquiet quand il y en aura une dizaine de demandés en meme temps non
?
Tu as bien coché impression physique a chaque page ?
Ca c'est une information que je ne connaissais pas ? Mais je ne trouve pas
cette option dans les propriétés de l'état.
Je suis en WD75.
Antoine
Eric ... qui aimerait bien lui aussi poser moins de questions sur ce sujet
s'il n'avait pas de problèmes.
Roumegou Eric wrote:
Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela prend
100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
Question peut-être idiote mais est ce que tes feuilles d'impressions
contiennent de images ou des pictogrammes..?
Roumegou Eric a présenté l'énoncé suivant :Le 07/10/2004, Antoine a supposé :Tu as déjà eu différentes répoonse à ce sujet je crois.
Et alors ? je trouve que 15mn à 20mn pour générer une édition certes de
2700 pages mais partant d'un fichier de 3200 enregs (un fichier HF je
précise), sachant que cette édition ne fait aucun traitement ... cela ne
relève pas d'un comportement normal.
Que donnerait une édition Crystal Report là dessus ?Ta réponse est dans la question "une édition de 2700 pages", comment veux
tu que cela ne prenne pas de temps.
Ton spooler d'impression dois saturer au bon d'un moment.
je génère en html et j'ai le meme pb. J'espère que je ne passe pas par le
spooler d'impression là ?? (autre pb en html une image=multiplication des
.gif sur le disque donc 2700 fichiers là où 1 suffirait).
Et puis je fais cela sur une machine dotée de 768 MO de Ram, il devrait y
avoir ce qu'il faut non ?
Et sur des petites quantités, la cpu monte aussi à 100 %.
Je suis parti sur une solution déjà compliquée parce que ces éditions
doivent se lancer depuis un site WebDev donc s'executer sur le serveur en
faisant appel à un executable WinDev. Quand je vois que cela fait monter la
cpu du serveur à 100 % pendant 15mn pour un état, j'ai le droit légitime
d'être inquiet quand il y en aura une dizaine de demandés en meme temps non
?Tu as bien coché impression physique a chaque page ?
Ca c'est une information que je ne connaissais pas ? Mais je ne trouve pas
cette option dans les propriétés de l'état.
Je suis en WD75.
Antoine
Eric ... qui aimerait bien lui aussi poser moins de questions sur ce sujet
s'il n'avait pas de problèmes.
Roumegou Eric wrote:Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela prend
100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
Question peut-être idiote mais est ce que tes feuilles d'impressions
contiennent de images ou des pictogrammes..?
Question peut-être idiote mais est ce que tes feuilles d'impressions
contiennent de images ou des pictogrammes..?
Oui il y a une image.
Elle provoque d'ailleurs à mon grand dam la génération d'un fichier
.gif par page si je choisis iaperçu(iHTML).
Mais j'ai essayé de la supprimer et les temps de réponses (un peu
meilleurs) restent encore très longs.
Question peut-être idiote mais est ce que tes feuilles d'impressions
contiennent de images ou des pictogrammes..?
Oui il y a une image.
Elle provoque d'ailleurs à mon grand dam la génération d'un fichier
.gif par page si je choisis iaperçu(iHTML).
Mais j'ai essayé de la supprimer et les temps de réponses (un peu
meilleurs) restent encore très longs.
Question peut-être idiote mais est ce que tes feuilles d'impressions
contiennent de images ou des pictogrammes..?
Oui il y a une image.
Elle provoque d'ailleurs à mon grand dam la génération d'un fichier
.gif par page si je choisis iaperçu(iHTML).
Mais j'ai essayé de la supprimer et les temps de réponses (un peu
meilleurs) restent encore très longs.
J-M des Grottes a pensé très fort :Roumegou Eric a présenté l'énoncé suivant :Le 07/10/2004, Antoine a supposé :Tu as déjà eu différentes répoonse à ce sujet je crois.
Et alors ? je trouve que 15mn à 20mn pour générer une édition certes de
2700 pages mais partant d'un fichier de 3200 enregs (un fichier HF je
précise), sachant que cette édition ne fait aucun traitement ... cela ne
relève pas d'un comportement normal.
Que donnerait une édition Crystal Report là dessus ?Ta réponse est dans la question "une édition de 2700 pages", comment veux
tu que cela ne prenne pas de temps.
Ton spooler d'impression dois saturer au bon d'un moment.
je génère en html et j'ai le meme pb. J'espère que je ne passe pas par le
spooler d'impression là ?? (autre pb en html une image=multiplication des
.gif sur le disque donc 2700 fichiers là où 1 suffirait).
Et puis je fais cela sur une machine dotée de 768 MO de Ram, il devrait y
avoir ce qu'il faut non ?
Et sur des petites quantités, la cpu monte aussi à 100 %.
Je suis parti sur une solution déjà compliquée parce que ces éditions
doivent se lancer depuis un site WebDev donc s'executer sur le serveur en
faisant appel à un executable WinDev. Quand je vois que cela fait monter
la cpu du serveur à 100 % pendant 15mn pour un état, j'ai le droit
légitime d'être inquiet quand il y en aura une dizaine de demandés en meme
temps non ?Tu as bien coché impression physique a chaque page ?
Ca c'est une information que je ne connaissais pas ? Mais je ne trouve pas
cette option dans les propriétés de l'état.
Je suis en WD75.
Antoine
Eric ... qui aimerait bien lui aussi poser moins de questions sur ce sujet
s'il n'avait pas de problèmes.
Roumegou Eric wrote:Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela prend
100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
Question peut-être idiote mais est ce que tes feuilles d'impressions
contiennent de images ou des pictogrammes..?
Oui il y a une image.
Elle provoque d'ailleurs à mon grand dam la génération d'un fichier .gif par
page si je choisis iaperçu(iHTML).
Mais j'ai essayé de la supprimer et les temps de réponses (un peu meilleurs)
restent encore très longs.
J-M des Grottes a pensé très fort :
Roumegou Eric a présenté l'énoncé suivant :
Le 07/10/2004, Antoine a supposé :
Tu as déjà eu différentes répoonse à ce sujet je crois.
Et alors ? je trouve que 15mn à 20mn pour générer une édition certes de
2700 pages mais partant d'un fichier de 3200 enregs (un fichier HF je
précise), sachant que cette édition ne fait aucun traitement ... cela ne
relève pas d'un comportement normal.
Que donnerait une édition Crystal Report là dessus ?
Ta réponse est dans la question "une édition de 2700 pages", comment veux
tu que cela ne prenne pas de temps.
Ton spooler d'impression dois saturer au bon d'un moment.
je génère en html et j'ai le meme pb. J'espère que je ne passe pas par le
spooler d'impression là ?? (autre pb en html une image=multiplication des
.gif sur le disque donc 2700 fichiers là où 1 suffirait).
Et puis je fais cela sur une machine dotée de 768 MO de Ram, il devrait y
avoir ce qu'il faut non ?
Et sur des petites quantités, la cpu monte aussi à 100 %.
Je suis parti sur une solution déjà compliquée parce que ces éditions
doivent se lancer depuis un site WebDev donc s'executer sur le serveur en
faisant appel à un executable WinDev. Quand je vois que cela fait monter
la cpu du serveur à 100 % pendant 15mn pour un état, j'ai le droit
légitime d'être inquiet quand il y en aura une dizaine de demandés en meme
temps non ?
Tu as bien coché impression physique a chaque page ?
Ca c'est une information que je ne connaissais pas ? Mais je ne trouve pas
cette option dans les propriétés de l'état.
Je suis en WD75.
Antoine
Eric ... qui aimerait bien lui aussi poser moins de questions sur ce sujet
s'il n'avait pas de problèmes.
Roumegou Eric wrote:
Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela prend
100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
Question peut-être idiote mais est ce que tes feuilles d'impressions
contiennent de images ou des pictogrammes..?
Oui il y a une image.
Elle provoque d'ailleurs à mon grand dam la génération d'un fichier .gif par
page si je choisis iaperçu(iHTML).
Mais j'ai essayé de la supprimer et les temps de réponses (un peu meilleurs)
restent encore très longs.
J-M des Grottes a pensé très fort :Roumegou Eric a présenté l'énoncé suivant :Le 07/10/2004, Antoine a supposé :Tu as déjà eu différentes répoonse à ce sujet je crois.
Et alors ? je trouve que 15mn à 20mn pour générer une édition certes de
2700 pages mais partant d'un fichier de 3200 enregs (un fichier HF je
précise), sachant que cette édition ne fait aucun traitement ... cela ne
relève pas d'un comportement normal.
Que donnerait une édition Crystal Report là dessus ?Ta réponse est dans la question "une édition de 2700 pages", comment veux
tu que cela ne prenne pas de temps.
Ton spooler d'impression dois saturer au bon d'un moment.
je génère en html et j'ai le meme pb. J'espère que je ne passe pas par le
spooler d'impression là ?? (autre pb en html une image=multiplication des
.gif sur le disque donc 2700 fichiers là où 1 suffirait).
Et puis je fais cela sur une machine dotée de 768 MO de Ram, il devrait y
avoir ce qu'il faut non ?
Et sur des petites quantités, la cpu monte aussi à 100 %.
Je suis parti sur une solution déjà compliquée parce que ces éditions
doivent se lancer depuis un site WebDev donc s'executer sur le serveur en
faisant appel à un executable WinDev. Quand je vois que cela fait monter
la cpu du serveur à 100 % pendant 15mn pour un état, j'ai le droit
légitime d'être inquiet quand il y en aura une dizaine de demandés en meme
temps non ?Tu as bien coché impression physique a chaque page ?
Ca c'est une information que je ne connaissais pas ? Mais je ne trouve pas
cette option dans les propriétés de l'état.
Je suis en WD75.
Antoine
Eric ... qui aimerait bien lui aussi poser moins de questions sur ce sujet
s'il n'avait pas de problèmes.
Roumegou Eric wrote:Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela prend
100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
Question peut-être idiote mais est ce que tes feuilles d'impressions
contiennent de images ou des pictogrammes..?
Oui il y a une image.
Elle provoque d'ailleurs à mon grand dam la génération d'un fichier .gif par
page si je choisis iaperçu(iHTML).
Mais j'ai essayé de la supprimer et les temps de réponses (un peu meilleurs)
restent encore très longs.
Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela prend
100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela prend
100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela prend
100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
Roumegou Eric wrote:Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Même pas un tout petit du genre un order by sur les clés du fichier ?
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela prend
100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
- un nombre excessif de colonnes parfois inutiles pour une impression (au
dessus de 50 çà commence à le faire).
- ne pas oublier de faire un HOptimise(nom_fichier_hf) pour aider un petit
peu HF
Roumegou Eric wrote:
Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Même pas un tout petit du genre un order by sur les clés du fichier ?
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela prend
100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
- un nombre excessif de colonnes parfois inutiles pour une impression (au
dessus de 50 çà commence à le faire).
- ne pas oublier de faire un HOptimise(nom_fichier_hf) pour aider un petit
peu HF
Roumegou Eric wrote:Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Même pas un tout petit du genre un order by sur les clés du fichier ?
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela prend
100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
- un nombre excessif de colonnes parfois inutiles pour une impression (au
dessus de 50 çà commence à le faire).
- ne pas oublier de faire un HOptimise(nom_fichier_hf) pour aider un petit
peu HF
free vient de nous annoncer :Roumegou Eric wrote:Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Même pas un tout petit du genre un order by sur les clés du fichier ?
Si une fonction de tri sur l'état. Sur 3 zones où existent un index.
Rien de très déconnant à mon sens ??Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela
prend 100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
- un nombre excessif de colonnes parfois inutiles pour une
impression (au dessus de 50 çà commence à le faire).
Oui mais c'était le principe de ces éditions sur des fichiers de
travail. Avoir dispo en ligne toutes mes zones repiquables dans ce
fichier (c'est pour gagner du temps, mais apparemment c'est raté). Et
puis 89 colonnes c'est quand meme pas énorme tout de mème ??
Un essai (un de plus), baser mon état sur une reqûete sur le fichier
HF. à suivre ...
- ne pas oublier de faire un HOptimise(nom_fichier_hf) pour aider un
petit peu HF
free vient de nous annoncer :
Roumegou Eric wrote:
Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Même pas un tout petit du genre un order by sur les clés du fichier ?
Si une fonction de tri sur l'état. Sur 3 zones où existent un index.
Rien de très déconnant à mon sens ??
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela
prend 100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
- un nombre excessif de colonnes parfois inutiles pour une
impression (au dessus de 50 çà commence à le faire).
Oui mais c'était le principe de ces éditions sur des fichiers de
travail. Avoir dispo en ligne toutes mes zones repiquables dans ce
fichier (c'est pour gagner du temps, mais apparemment c'est raté). Et
puis 89 colonnes c'est quand meme pas énorme tout de mème ??
Un essai (un de plus), baser mon état sur une reqûete sur le fichier
HF. à suivre ...
- ne pas oublier de faire un HOptimise(nom_fichier_hf) pour aider un
petit peu HF
free vient de nous annoncer :Roumegou Eric wrote:Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Même pas un tout petit du genre un order by sur les clés du fichier ?
Si une fonction de tri sur l'état. Sur 3 zones où existent un index.
Rien de très déconnant à mon sens ??Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela
prend 100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
- un nombre excessif de colonnes parfois inutiles pour une
impression (au dessus de 50 çà commence à le faire).
Oui mais c'était le principe de ces éditions sur des fichiers de
travail. Avoir dispo en ligne toutes mes zones repiquables dans ce
fichier (c'est pour gagner du temps, mais apparemment c'est raté). Et
puis 89 colonnes c'est quand meme pas énorme tout de mème ??
Un essai (un de plus), baser mon état sur une reqûete sur le fichier
HF. à suivre ...
- ne pas oublier de faire un HOptimise(nom_fichier_hf) pour aider un
petit peu HF
Roumegou Eric wrote:free vient de nous annoncer :Roumegou Eric wrote:Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Même pas un tout petit du genre un order by sur les clés du fichier ?
Si une fonction de tri sur l'état. Sur 3 zones où existent un index.
Rien de très déconnant à mon sens ??Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela
prend 100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
- un nombre excessif de colonnes parfois inutiles pour une
impression (au dessus de 50 çà commence à le faire).
Oui mais c'était le principe de ces éditions sur des fichiers de
travail. Avoir dispo en ligne toutes mes zones repiquables dans ce
fichier (c'est pour gagner du temps, mais apparemment c'est raté). Et
puis 89 colonnes c'est quand meme pas énorme tout de mème ??
Un essai (un de plus), baser mon état sur une reqûete sur le fichier
HF. à suivre ...
Pour moi le mieux dans ton cas :
- création d'une requete pour filtrer et ordonner tes données.
- état basé sur ta requete au lieu du fichier
- hoptimiserequete avant l'impression de ton fichier
Autre avantage, en WD8 on peut reagrder ce qui manque au fichier pour
optimiser la requete.
- ne pas oublier de faire un HOptimise(nom_fichier_hf) pour aider un
petit peu HF
Roumegou Eric wrote:
free vient de nous annoncer :
Roumegou Eric wrote:
Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Même pas un tout petit du genre un order by sur les clés du fichier ?
Si une fonction de tri sur l'état. Sur 3 zones où existent un index.
Rien de très déconnant à mon sens ??
Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela
prend 100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
- un nombre excessif de colonnes parfois inutiles pour une
impression (au dessus de 50 çà commence à le faire).
Oui mais c'était le principe de ces éditions sur des fichiers de
travail. Avoir dispo en ligne toutes mes zones repiquables dans ce
fichier (c'est pour gagner du temps, mais apparemment c'est raté). Et
puis 89 colonnes c'est quand meme pas énorme tout de mème ??
Un essai (un de plus), baser mon état sur une reqûete sur le fichier
HF. à suivre ...
Pour moi le mieux dans ton cas :
- création d'une requete pour filtrer et ordonner tes données.
- état basé sur ta requete au lieu du fichier
- hoptimiserequete avant l'impression de ton fichier
Autre avantage, en WD8 on peut reagrder ce qui manque au fichier pour
optimiser la requete.
- ne pas oublier de faire un HOptimise(nom_fichier_hf) pour aider un
petit peu HF
Roumegou Eric wrote:free vient de nous annoncer :Roumegou Eric wrote:Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Même pas un tout petit du genre un order by sur les clés du fichier ?
Si une fonction de tri sur l'état. Sur 3 zones où existent un index.
Rien de très déconnant à mon sens ??Il traite un fichier HF contenant 3200 enreg et gère (avec rupture)
une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela
prend 100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
- un nombre excessif de colonnes parfois inutiles pour une
impression (au dessus de 50 çà commence à le faire).
Oui mais c'était le principe de ces éditions sur des fichiers de
travail. Avoir dispo en ligne toutes mes zones repiquables dans ce
fichier (c'est pour gagner du temps, mais apparemment c'est raté). Et
puis 89 colonnes c'est quand meme pas énorme tout de mème ??
Un essai (un de plus), baser mon état sur une reqûete sur le fichier
HF. à suivre ...
Pour moi le mieux dans ton cas :
- création d'une requete pour filtrer et ordonner tes données.
- état basé sur ta requete au lieu du fichier
- hoptimiserequete avant l'impression de ton fichier
Autre avantage, en WD8 on peut reagrder ce qui manque au fichier pour
optimiser la requete.
- ne pas oublier de faire un HOptimise(nom_fichier_hf) pour aider un
petit peu HF
Il se trouve que Manu a formulé :Roumegou Eric wrote:free vient de nous annoncer :Roumegou Eric wrote:Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Même pas un tout petit du genre un order by sur les clés du
fichier ?
Si une fonction de tri sur l'état. Sur 3 zones où existent un index.
Rien de très déconnant à mon sens ??Il traite un fichier HF contenant 3200 enreg et gère (avec
rupture) une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela
prend 100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
- un nombre excessif de colonnes parfois inutiles pour une
impression (au dessus de 50 çà commence à le faire).
Oui mais c'était le principe de ces éditions sur des fichiers de
travail. Avoir dispo en ligne toutes mes zones repiquables dans ce
fichier (c'est pour gagner du temps, mais apparemment c'est raté).
Et puis 89 colonnes c'est quand meme pas énorme tout de mème ??
Un essai (un de plus), baser mon état sur une reqûete sur le fichier
HF. à suivre ...
Pour moi le mieux dans ton cas :
- création d'une requete pour filtrer et ordonner tes données.
je viens de le faire et je suis passé à 15 secondes au lieu de 4mn.
Super !!! mais Hélas, c'est vide !
Là ce doit être ma faute, Pas du faire la bonne manip.
J'ai créé une requête sur le fichier modèle que j'ai sauvegardé.
Ensuite j'ai changé la source pour se positionner sur cette requete.
dans le traitement, j'avais :
MonFicEdi est une source de données
MonFicEdi=HF_HISTOEDI.HEDI_FICHF
HChangeNom({MonFicMdl},fExtraitChemin(MonFicEdi,fFichier))
HChangeRep({MonFicMdl},fExtraitChemin(MonFicEdi,fDisque+fRépertoire))
donc je détournais mon fichier (EDI_PTS) vers mon fichier de travail
(EDI-PTSnn).
Maintenant je suppose que je dois changer la destination de la requête
???- état basé sur ta requete au lieu du fichier
Ok- hoptimiserequete avant l'impression de ton fichier
A quel moment ? dans l'état ou avant ? juste après avoir redirigé la
requête sur le fichier de travail ?
Autre avantage, en WD8 on peut reagrder ce qui manque au fichier pour
optimiser la requete.
mais je n'ais pas WD8 :'(
snif !
- ne pas oublier de faire un HOptimise(nom_fichier_hf) pour aider
un petit peu HF
Il se trouve que Manu a formulé :
Roumegou Eric wrote:
free vient de nous annoncer :
Roumegou Eric wrote:
Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Même pas un tout petit du genre un order by sur les clés du
fichier ?
Si une fonction de tri sur l'état. Sur 3 zones où existent un index.
Rien de très déconnant à mon sens ??
Il traite un fichier HF contenant 3200 enreg et gère (avec
rupture) une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela
prend 100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
- un nombre excessif de colonnes parfois inutiles pour une
impression (au dessus de 50 çà commence à le faire).
Oui mais c'était le principe de ces éditions sur des fichiers de
travail. Avoir dispo en ligne toutes mes zones repiquables dans ce
fichier (c'est pour gagner du temps, mais apparemment c'est raté).
Et puis 89 colonnes c'est quand meme pas énorme tout de mème ??
Un essai (un de plus), baser mon état sur une reqûete sur le fichier
HF. à suivre ...
Pour moi le mieux dans ton cas :
- création d'une requete pour filtrer et ordonner tes données.
je viens de le faire et je suis passé à 15 secondes au lieu de 4mn.
Super !!! mais Hélas, c'est vide !
Là ce doit être ma faute, Pas du faire la bonne manip.
J'ai créé une requête sur le fichier modèle que j'ai sauvegardé.
Ensuite j'ai changé la source pour se positionner sur cette requete.
dans le traitement, j'avais :
MonFicEdi est une source de données
MonFicEdi=HF_HISTOEDI.HEDI_FICHF
HChangeNom({MonFicMdl},fExtraitChemin(MonFicEdi,fFichier))
HChangeRep({MonFicMdl},fExtraitChemin(MonFicEdi,fDisque+fRépertoire))
donc je détournais mon fichier (EDI_PTS) vers mon fichier de travail
(EDI-PTSnn).
Maintenant je suppose que je dois changer la destination de la requête
???
- état basé sur ta requete au lieu du fichier
Ok
- hoptimiserequete avant l'impression de ton fichier
A quel moment ? dans l'état ou avant ? juste après avoir redirigé la
requête sur le fichier de travail ?
Autre avantage, en WD8 on peut reagrder ce qui manque au fichier pour
optimiser la requete.
mais je n'ais pas WD8 :'(
snif !
- ne pas oublier de faire un HOptimise(nom_fichier_hf) pour aider
un petit peu HF
Il se trouve que Manu a formulé :Roumegou Eric wrote:free vient de nous annoncer :Roumegou Eric wrote:Un état basé sur un fichier HF est désespéremment lent.
Il n'y a aucun traitement dans celui-ci.
Même pas un tout petit du genre un order by sur les clés du
fichier ?
Si une fonction de tri sur l'état. Sur 3 zones où existent un index.
Rien de très déconnant à mon sens ??Il traite un fichier HF contenant 3200 enreg et gère (avec
rupture) une édition de 2700 pages.
En sortie HTML ou en PDF Creator, c'est plus de 15mn ??? et cela
prend 100% de la cpu ???
Qu'est ce qui peut causer un tel pb ?
- un nombre excessif de colonnes parfois inutiles pour une
impression (au dessus de 50 çà commence à le faire).
Oui mais c'était le principe de ces éditions sur des fichiers de
travail. Avoir dispo en ligne toutes mes zones repiquables dans ce
fichier (c'est pour gagner du temps, mais apparemment c'est raté).
Et puis 89 colonnes c'est quand meme pas énorme tout de mème ??
Un essai (un de plus), baser mon état sur une reqûete sur le fichier
HF. à suivre ...
Pour moi le mieux dans ton cas :
- création d'une requete pour filtrer et ordonner tes données.
je viens de le faire et je suis passé à 15 secondes au lieu de 4mn.
Super !!! mais Hélas, c'est vide !
Là ce doit être ma faute, Pas du faire la bonne manip.
J'ai créé une requête sur le fichier modèle que j'ai sauvegardé.
Ensuite j'ai changé la source pour se positionner sur cette requete.
dans le traitement, j'avais :
MonFicEdi est une source de données
MonFicEdi=HF_HISTOEDI.HEDI_FICHF
HChangeNom({MonFicMdl},fExtraitChemin(MonFicEdi,fFichier))
HChangeRep({MonFicMdl},fExtraitChemin(MonFicEdi,fDisque+fRépertoire))
donc je détournais mon fichier (EDI_PTS) vers mon fichier de travail
(EDI-PTSnn).
Maintenant je suppose que je dois changer la destination de la requête
???- état basé sur ta requete au lieu du fichier
Ok- hoptimiserequete avant l'impression de ton fichier
A quel moment ? dans l'état ou avant ? juste après avoir redirigé la
requête sur le fichier de travail ?
Autre avantage, en WD8 on peut reagrder ce qui manque au fichier pour
optimiser la requete.
mais je n'ais pas WD8 :'(
snif !
- ne pas oublier de faire un HOptimise(nom_fichier_hf) pour aider
un petit peu HF
