Bonjour
j'ai vu pas mal d'exemple pour exploiter le contenu d'un fichier, seulement
ca fait un petit moment que je butte sur ceci:
- Comment copier dans un nouveau fichier les n dernieres lignes d'un autre
fichier
De plus si y a un moyen de ne pas compter la totalitée des lignes car mon
fichier fait environ 800 000 lignes alors le comptage prend plusieurs
minutes. Je me demandai si un truc du genre endofstream -100 ou quelque
chose comme ca n'existait pas :)
Bref mes connaissances vbs sont limitées pour aller plus loin dans ce genre
de chose si vous avez une idée
(une seule ligne, même si le texte brut tronque intempestivement).
Je sais, tu ne peux pas installer Python ; mais, tu vois ce que tu rates...
-- @-salutations
Michel Claveau
technicland
Gilles LAURENT wrote:
Temps de traitement : < 40 secondes (affichage inclus)
- Tests réalisés sur un fichier texte de 800 000 lignes - Les lignes sont composées de 80 caractères suivis d'un CrLf - Plateforme Pentium M 1500MHz 512 Mo - Mémoire physique disponible < 140 Mo
Merci en adaptant legerement je suis arrivé a ce que je voulais merci -------------------------- Const ForAppending = 8 Set oFs=CreateObject("Scripting.FileSystemObject") Set oFile=oFs.OpenTextFile ("c:zip.txt",1) arrLines=Split (oFile.ReadAll, VBCrLf)
Set objFSO = CreateObject("Scripting.FileSystemObject") Set objTextFile = objFSO.OpenTextFile ("c:toto.txt", ForAppending, True)
For i=1 To 1000 objTextFile.WriteLine (arrLines (UBound (arrLines) - i)) Next objTextFile.Close -------------------------- Laurent
Gilles LAURENT wrote:
Temps de traitement : < 40 secondes (affichage inclus)
- Tests réalisés sur un fichier texte de 800 000 lignes
- Les lignes sont composées de 80 caractères suivis d'un CrLf
- Plateforme Pentium M 1500MHz 512 Mo
- Mémoire physique disponible < 140 Mo
Merci en adaptant legerement je suis arrivé a ce que je voulais merci
--------------------------
Const ForAppending = 8
Set oFs=CreateObject("Scripting.FileSystemObject")
Set oFile=oFs.OpenTextFile ("c:zip.txt",1)
arrLines=Split (oFile.ReadAll, VBCrLf)
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objFSO.OpenTextFile ("c:toto.txt", ForAppending, True)
For i=1 To 1000
objTextFile.WriteLine (arrLines (UBound (arrLines) - i))
Next
objTextFile.Close
--------------------------
Laurent
Temps de traitement : < 40 secondes (affichage inclus)
- Tests réalisés sur un fichier texte de 800 000 lignes - Les lignes sont composées de 80 caractères suivis d'un CrLf - Plateforme Pentium M 1500MHz 512 Mo - Mémoire physique disponible < 140 Mo
Merci en adaptant legerement je suis arrivé a ce que je voulais merci -------------------------- Const ForAppending = 8 Set oFs=CreateObject("Scripting.FileSystemObject") Set oFile=oFs.OpenTextFile ("c:zip.txt",1) arrLines=Split (oFile.ReadAll, VBCrLf)
Set objFSO = CreateObject("Scripting.FileSystemObject") Set objTextFile = objFSO.OpenTextFile ("c:toto.txt", ForAppending, True)
For i=1 To 1000 objTextFile.WriteLine (arrLines (UBound (arrLines) - i)) Next objTextFile.Close -------------------------- Laurent
Fred
Dans : news:, technicland écrivait :
Salut
Re
oui c'est ReadLine la j'arrive a sortir la derniere ligne et mais j'en voudrais environ 500 et j ai du mal avec les tableaux!
Une tentative approximative non testée !
Dim buffer(499) Dim last = -1
'Lecture de la totalité du fichier While Not s.AtEndOfStream last = last + 1 If last = 500 Then last = 0 buffer(last) = s.ReadLine Wend
'Restitution des 500 dernière lignes '(en supposant que le fichier contient plus de 500 lignes) i=last+1 While i <500 Echo buffer(i) i = i+ 1 Wend i=0 While i<=last Echo buffer(i) i=i+1 Wend
À compléter (peut-être à corriger au niveau des indices) selon ton besoin.
-- Fred http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Dans : news:OiSbwazZHHA.4508@TK2MSFTNGP03.phx.gbl,
technicland écrivait :
Salut
Re
oui c'est ReadLine la j'arrive a sortir la derniere ligne et mais j'en
voudrais environ 500 et j ai du mal avec les tableaux!
Une tentative approximative non testée !
Dim buffer(499)
Dim last = -1
'Lecture de la totalité du fichier
While Not s.AtEndOfStream
last = last + 1
If last = 500 Then last = 0
buffer(last) = s.ReadLine
Wend
'Restitution des 500 dernière lignes
'(en supposant que le fichier contient plus de 500 lignes)
i=last+1
While i <500
Echo buffer(i)
i = i+ 1
Wend
i=0
While i<=last
Echo buffer(i)
i=i+1
Wend
À compléter (peut-être à corriger au niveau des indices) selon ton
besoin.
--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
oui c'est ReadLine la j'arrive a sortir la derniere ligne et mais j'en voudrais environ 500 et j ai du mal avec les tableaux!
Une tentative approximative non testée !
Dim buffer(499) Dim last = -1
'Lecture de la totalité du fichier While Not s.AtEndOfStream last = last + 1 If last = 500 Then last = 0 buffer(last) = s.ReadLine Wend
'Restitution des 500 dernière lignes '(en supposant que le fichier contient plus de 500 lignes) i=last+1 While i <500 Echo buffer(i) i = i+ 1 Wend i=0 While i<=last Echo buffer(i) i=i+1 Wend
À compléter (peut-être à corriger au niveau des indices) selon ton besoin.
-- Fred http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Jacques Barathon [MS]
"Michel Claveau" <Enleverles wrote in message news:
(une seule ligne, même si le texte brut tronque intempestivement).
Ce que j'adore dans les échanges des newsgroups, c'est la confrontation des expériences. Ta solution, Michel, m'a permis de vérifier que PowerShell est encore plus souple que je ne le croyais:
(type $input)[-$n..-1] > $output
Sur un fichier test de 800000 lignes, extraire les 100 dernières lignes avec la commande ci-dessus a pris 1mn15 sur mon poste. Pas super rapide, mais on peut faire beaucoup plus rapide en faisant directement appel aux classes .NET:
Sur le même fichier test de 800000 lignes, extraire les 100 dernières lignes a pris 10 secondes. Yeah! :-) La syntaxe est moins intuitive, mais pour un besoin en production, le gain de temps est considérable. Pour info, l'équipe Windows PowerShell a clairement reconnu que les performances de la v1 de PowerShell n'ont pas été optimisées. Une mise à jour devrait sortir (pas de délai à ce jour) qui apportera notamment une amélioration substantielle de ce côté-là.
Jacques
"Michel Claveau" <Enleverles XX.mcXX@XmXclaveauXX.XX.com> wrote in message
news:mn.7cee7d736d0816f3.34209@XmXclaveauXX.XX.com...
(une seule ligne, même si le texte brut tronque intempestivement).
Ce que j'adore dans les échanges des newsgroups, c'est la confrontation des
expériences. Ta solution, Michel, m'a permis de vérifier que PowerShell est
encore plus souple que je ne le croyais:
(type $input)[-$n..-1] > $output
Sur un fichier test de 800000 lignes, extraire les 100 dernières lignes avec
la commande ci-dessus a pris 1mn15 sur mon poste. Pas super rapide, mais on
peut faire beaucoup plus rapide en faisant directement appel aux classes
.NET:
Sur le même fichier test de 800000 lignes, extraire les 100 dernières lignes
a pris 10 secondes. Yeah! :-) La syntaxe est moins intuitive, mais pour un
besoin en production, le gain de temps est considérable. Pour info, l'équipe
Windows PowerShell a clairement reconnu que les performances de la v1 de
PowerShell n'ont pas été optimisées. Une mise à jour devrait sortir (pas de
délai à ce jour) qui apportera notamment une amélioration substantielle de
ce côté-là.
(une seule ligne, même si le texte brut tronque intempestivement).
Ce que j'adore dans les échanges des newsgroups, c'est la confrontation des expériences. Ta solution, Michel, m'a permis de vérifier que PowerShell est encore plus souple que je ne le croyais:
(type $input)[-$n..-1] > $output
Sur un fichier test de 800000 lignes, extraire les 100 dernières lignes avec la commande ci-dessus a pris 1mn15 sur mon poste. Pas super rapide, mais on peut faire beaucoup plus rapide en faisant directement appel aux classes .NET:
Sur le même fichier test de 800000 lignes, extraire les 100 dernières lignes a pris 10 secondes. Yeah! :-) La syntaxe est moins intuitive, mais pour un besoin en production, le gain de temps est considérable. Pour info, l'équipe Windows PowerShell a clairement reconnu que les performances de la v1 de PowerShell n'ont pas été optimisées. Une mise à jour devrait sortir (pas de délai à ce jour) qui apportera notamment une amélioration substantielle de ce côté-là.
Jacques
Jacques Barathon [MS]
"technicland" wrote in message news: ...
Lut Malheureusement je suis obligé de m en tenir a VBS c'est des serveurs en 2000 ou 2003 et je ne peux pas installer ce que je veux d apres ce que j'ai lu y a des trucs a installer pour PowerShell Laurent
Oui, il faut installer le Framework .NET 2.0 s'il ne l'est pas déjà, et PowerShell lui-même. De toute façon, PowerShell n'est pas supporté sur Windows 2000, donc raté pour une exécution en local sur ces serveurs-là.
Cela dit, tu peux aussi exécuter depuis un poste d'administration des scripts PowerShell qui vont "attaquer" des serveurs distants (notamment grâce à WMI, mais pas seulement). De nombreux administrateurs système le font pour ne pas avoir à installer PowerShell sur l'ensemble de leur parc. Mais dans ton cas, parcourir un fichier de 800000 lignes sur plusieurs serveurs à travers un réseau n'est sans doute pas la meilleure solution. Le script de Gilles que tu as adapté devrait donc très bien te convenir.
Jacques
"technicland" <webmasterpasdepourriels@technicland.com> wrote in message
news:uJt6eBzZHHA.5044@TK2MSFTNGP05.phx.gbl...
...
Lut
Malheureusement je suis obligé de m en tenir a VBS c'est des serveurs en
2000 ou 2003 et je ne peux pas installer ce que je veux d apres ce que
j'ai lu y a des trucs a installer pour PowerShell
Laurent
Oui, il faut installer le Framework .NET 2.0 s'il ne l'est pas déjà, et
PowerShell lui-même. De toute façon, PowerShell n'est pas supporté sur
Windows 2000, donc raté pour une exécution en local sur ces serveurs-là.
Cela dit, tu peux aussi exécuter depuis un poste d'administration des
scripts PowerShell qui vont "attaquer" des serveurs distants (notamment
grâce à WMI, mais pas seulement). De nombreux administrateurs système le
font pour ne pas avoir à installer PowerShell sur l'ensemble de leur parc.
Mais dans ton cas, parcourir un fichier de 800000 lignes sur plusieurs
serveurs à travers un réseau n'est sans doute pas la meilleure solution. Le
script de Gilles que tu as adapté devrait donc très bien te convenir.
Lut Malheureusement je suis obligé de m en tenir a VBS c'est des serveurs en 2000 ou 2003 et je ne peux pas installer ce que je veux d apres ce que j'ai lu y a des trucs a installer pour PowerShell Laurent
Oui, il faut installer le Framework .NET 2.0 s'il ne l'est pas déjà, et PowerShell lui-même. De toute façon, PowerShell n'est pas supporté sur Windows 2000, donc raté pour une exécution en local sur ces serveurs-là.
Cela dit, tu peux aussi exécuter depuis un poste d'administration des scripts PowerShell qui vont "attaquer" des serveurs distants (notamment grâce à WMI, mais pas seulement). De nombreux administrateurs système le font pour ne pas avoir à installer PowerShell sur l'ensemble de leur parc. Mais dans ton cas, parcourir un fichier de 800000 lignes sur plusieurs serveurs à travers un réseau n'est sans doute pas la meilleure solution. Le script de Gilles que tu as adapté devrait donc très bien te convenir.
Jacques
Michel Claveau
Bonsoir, Jacques !
Je suis bien content de t'avoir appris des trucs sur PowerShell. Et, inutile de me remercier, c'était involontaire ;o)
Pour les performances, elles sont très difficiles à mesurer. Cela dépend de la version de windows, de la config de l'antivirus, de la taille mémoire, de la config des multiples buffers de windows (mais aussi du contrôleur de disque dur), du format du disque, etc. Le jeu d'essai peut, lui aussi entrer en ligne de compte.
Par exemple, avec 800 000 lignes de 40 caractères (+'rn'), en dehors du premier lancement, mon code Python met 0,26 secondes [P4 1,6 GHz, 1Go, disque dur lent (portable)] ; et pourtant Python n'a pas une grande réputation de vitesse. Mais, comme il s'agit d'une petit fichier (<34 Mo), il est entièrement bufferisé.
-- @-salutations
Michel Claveau
Bonsoir, Jacques !
Je suis bien content de t'avoir appris des trucs sur PowerShell.
Et, inutile de me remercier, c'était involontaire ;o)
Pour les performances, elles sont très difficiles à mesurer. Cela
dépend de la version de windows, de la config de l'antivirus, de la
taille mémoire, de la config des multiples buffers de windows (mais
aussi du contrôleur de disque dur), du format du disque, etc.
Le jeu d'essai peut, lui aussi entrer en ligne de compte.
Par exemple, avec 800 000 lignes de 40 caractères (+'rn'), en dehors
du premier lancement, mon code Python met 0,26 secondes [P4 1,6 GHz,
1Go, disque dur lent (portable)] ; et pourtant Python n'a pas une
grande réputation de vitesse.
Mais, comme il s'agit d'une petit fichier (<34 Mo), il est entièrement
bufferisé.
Je suis bien content de t'avoir appris des trucs sur PowerShell. Et, inutile de me remercier, c'était involontaire ;o)
Pour les performances, elles sont très difficiles à mesurer. Cela dépend de la version de windows, de la config de l'antivirus, de la taille mémoire, de la config des multiples buffers de windows (mais aussi du contrôleur de disque dur), du format du disque, etc. Le jeu d'essai peut, lui aussi entrer en ligne de compte.
Par exemple, avec 800 000 lignes de 40 caractères (+'rn'), en dehors du premier lancement, mon code Python met 0,26 secondes [P4 1,6 GHz, 1Go, disque dur lent (portable)] ; et pourtant Python n'a pas une grande réputation de vitesse. Mais, comme il s'agit d'une petit fichier (<34 Mo), il est entièrement bufferisé.
-- @-salutations
Michel Claveau
Michel Claveau
Re !
Dans le genre optimisation, en Python, on pourrait écrire : open(filein,"w").writelines(open(fileout,"r").readlines()[-100:])
Je ne sais pas pourquoi je n'ai pas écrit ça du premier coup. La fatigue, sans doute...
Au passage, j'ai remarqué qu'en faisant ça en deux lignes, on était un peu plus rapide !!!???
-- @-salutations
Michel Claveau
Re !
Dans le genre optimisation, en Python, on pourrait écrire :
open(filein,"w").writelines(open(fileout,"r").readlines()[-100:])
Je ne sais pas pourquoi je n'ai pas écrit ça du premier coup. La
fatigue, sans doute...
Au passage, j'ai remarqué qu'en faisant ça en deux lignes, on était un
peu plus rapide !!!???
Dans le genre optimisation, en Python, on pourrait écrire : open(filein,"w").writelines(open(fileout,"r").readlines()[-100:])
Je ne sais pas pourquoi je n'ai pas écrit ça du premier coup. La fatigue, sans doute...
Au passage, j'ai remarqué qu'en faisant ça en deux lignes, on était un peu plus rapide !!!???
-- @-salutations
Michel Claveau
moi
Notre ami Michel Claveau tapota :
Re !
Dans le genre optimisation, en Python, on pourrait écrire : open(filein,"w").writelines(open(fileout,"r").readlines()[-100:])
Au passage, j'ai remarqué qu'en faisant ça en deux lignes, on était un peu plus rapide !!!???
Salut,
ça ne m'étonne pas. Dans la plupart des langages, l'optimisation du code (en terme de vitesse) est souvent incompatible avec l'optimisation "esthétique" qui consiste à chercher une formulation plus dense au risque de nécessiter beaucoup plus de travail en mémoire. Par exemple, pour des calculs complexes, il est souvent préférable de manipuler des "morceaux" de l'expression avant de terminer le calcul plutôt que de donner directement la formule complète. C'est particulièrement sensible dans les langages "directs" ( non préalablement compilés) comme VBS puisque l'analyse syntaxique et l'organisation des tâches à réaliser avant exécution peut y jouer un rôle non négligeable. Les cascades d'objets du type machin.truc.bidule.action sont à ce titre redoutables. Le programmeur n'ayant rien déclaré, c'est au moment de l'analyse que les sous-objets sont créés. Les séquences générées sont alors des formes standards construites de façon modulaire qui contiennent localement beaucoup plus que ce qui suffirait. L'enregistrement de macro VBA avec un prgm de la suite Office est très révélateur. Les codes obtenus sont imbuvables et, après netoyage, la taille et la complexité diminuent en général de façon radicale.
voili voilou, c'était la minute philosophique du professeur cosinus ;o)
A+
HB
Notre ami Michel Claveau tapota :
Re !
Dans le genre optimisation, en Python, on pourrait écrire :
open(filein,"w").writelines(open(fileout,"r").readlines()[-100:])
Au passage, j'ai remarqué qu'en faisant ça en deux lignes, on était
un
peu plus rapide !!!???
Salut,
ça ne m'étonne pas.
Dans la plupart des langages, l'optimisation du code (en terme de
vitesse) est souvent incompatible avec l'optimisation "esthétique" qui
consiste à chercher une formulation plus dense au risque de nécessiter
beaucoup plus de travail en mémoire.
Par exemple, pour des calculs complexes, il est souvent préférable de
manipuler des "morceaux" de l'expression avant de terminer le calcul
plutôt que de donner directement la formule complète. C'est
particulièrement sensible dans les langages "directs" ( non
préalablement compilés) comme VBS puisque l'analyse syntaxique et
l'organisation des tâches à réaliser avant exécution peut y jouer un
rôle non négligeable.
Les cascades d'objets du type machin.truc.bidule.action sont à ce
titre redoutables.
Le programmeur n'ayant rien déclaré, c'est au moment de l'analyse que
les sous-objets sont créés. Les séquences générées sont alors des
formes standards construites de façon modulaire qui contiennent
localement beaucoup plus que ce qui suffirait.
L'enregistrement de macro VBA avec un prgm de la suite Office est très
révélateur.
Les codes obtenus sont imbuvables et, après netoyage, la taille et la
complexité diminuent en général de façon radicale.
voili voilou,
c'était la minute philosophique du professeur cosinus ;o)
Dans le genre optimisation, en Python, on pourrait écrire : open(filein,"w").writelines(open(fileout,"r").readlines()[-100:])
Au passage, j'ai remarqué qu'en faisant ça en deux lignes, on était un peu plus rapide !!!???
Salut,
ça ne m'étonne pas. Dans la plupart des langages, l'optimisation du code (en terme de vitesse) est souvent incompatible avec l'optimisation "esthétique" qui consiste à chercher une formulation plus dense au risque de nécessiter beaucoup plus de travail en mémoire. Par exemple, pour des calculs complexes, il est souvent préférable de manipuler des "morceaux" de l'expression avant de terminer le calcul plutôt que de donner directement la formule complète. C'est particulièrement sensible dans les langages "directs" ( non préalablement compilés) comme VBS puisque l'analyse syntaxique et l'organisation des tâches à réaliser avant exécution peut y jouer un rôle non négligeable. Les cascades d'objets du type machin.truc.bidule.action sont à ce titre redoutables. Le programmeur n'ayant rien déclaré, c'est au moment de l'analyse que les sous-objets sont créés. Les séquences générées sont alors des formes standards construites de façon modulaire qui contiennent localement beaucoup plus que ce qui suffirait. L'enregistrement de macro VBA avec un prgm de la suite Office est très révélateur. Les codes obtenus sont imbuvables et, après netoyage, la taille et la complexité diminuent en général de façon radicale.
voili voilou, c'était la minute philosophique du professeur cosinus ;o)
A+
HB
technicland
Jacques Barathon [MS] wrote:
Oui, il faut installer le Framework .NET 2.0 s'il ne l'est pas déjà, et PowerShell lui-même. De toute façon, PowerShell n'est pas supporté sur Windows 2000, donc raté pour une exécution en local sur ces serveurs-là. Cela dit, tu peux aussi exécuter depuis un poste d'administration des scripts PowerShell qui vont "attaquer" des serveurs distants (notamment grâce à WMI, mais pas seulement). De nombreux administrateurs système le font pour ne pas avoir à installer PowerShell sur l'ensemble de leur parc. Mais dans ton cas, parcourir un fichier de 800000 lignes sur plusieurs serveurs à travers un réseau n'est sans doute pas la meilleure solution. Le script de Gilles que tu as adapté devrait donc très bien te convenir.
Salut Jacques J'ai en effet essaye d'utiliser le script de Gilles adapté. Malgré des serveurs Quadri-proceseurs je pleure!!! Exemple un fichier fait plus de 195Mo lorsque je lance le script tout part dans le rouge pendant presque une minute, je dois te dire que c'est pas le pied pour des serveurs hypersensible. Du coup je crois que je vais en rester au zip du fichier et au transfert complet (4.5Mo apres compression) Laurent
Jacques Barathon [MS] wrote:
Oui, il faut installer le Framework .NET 2.0 s'il ne l'est pas déjà,
et PowerShell lui-même. De toute façon, PowerShell n'est pas supporté
sur Windows 2000, donc raté pour une exécution en local sur ces
serveurs-là.
Cela dit, tu peux aussi exécuter depuis un poste d'administration des
scripts PowerShell qui vont "attaquer" des serveurs distants
(notamment grâce à WMI, mais pas seulement). De nombreux
administrateurs système le font pour ne pas avoir à installer
PowerShell sur l'ensemble de leur parc. Mais dans ton cas, parcourir
un fichier de 800000 lignes sur plusieurs serveurs à travers un
réseau n'est sans doute pas la meilleure solution. Le script de
Gilles que tu as adapté devrait donc très bien te convenir.
Salut Jacques
J'ai en effet essaye d'utiliser le script de Gilles adapté. Malgré des
serveurs Quadri-proceseurs je pleure!!!
Exemple un fichier fait plus de 195Mo lorsque je lance le script tout part
dans le rouge pendant presque une minute, je dois te dire que c'est pas le
pied pour des serveurs hypersensible. Du coup je crois que je vais en rester
au zip du fichier et au transfert complet (4.5Mo apres compression)
Laurent
Oui, il faut installer le Framework .NET 2.0 s'il ne l'est pas déjà, et PowerShell lui-même. De toute façon, PowerShell n'est pas supporté sur Windows 2000, donc raté pour une exécution en local sur ces serveurs-là. Cela dit, tu peux aussi exécuter depuis un poste d'administration des scripts PowerShell qui vont "attaquer" des serveurs distants (notamment grâce à WMI, mais pas seulement). De nombreux administrateurs système le font pour ne pas avoir à installer PowerShell sur l'ensemble de leur parc. Mais dans ton cas, parcourir un fichier de 800000 lignes sur plusieurs serveurs à travers un réseau n'est sans doute pas la meilleure solution. Le script de Gilles que tu as adapté devrait donc très bien te convenir.
Salut Jacques J'ai en effet essaye d'utiliser le script de Gilles adapté. Malgré des serveurs Quadri-proceseurs je pleure!!! Exemple un fichier fait plus de 195Mo lorsque je lance le script tout part dans le rouge pendant presque une minute, je dois te dire que c'est pas le pied pour des serveurs hypersensible. Du coup je crois que je vais en rester au zip du fichier et au transfert complet (4.5Mo apres compression) Laurent
technicland
technicland wrote:
Salut Jacques J'ai en effet essaye d'utiliser le script de Gilles adapté. Malgré des serveurs Quadri-proceseurs je pleure!!! Exemple un fichier fait plus de 195Mo lorsque je lance le script tout part dans le rouge pendant presque une minute, je dois te dire que c'est pas le pied pour des serveurs hypersensible. Du coup je crois que je vais en rester au zip du fichier et au transfert complet (4.5Mo apres compression) Laurent
Lut pour info j'ai finalement utilisé tail.exe (legé, efficace et instantanée et zero ressource) Laurent
technicland wrote:
Salut Jacques
J'ai en effet essaye d'utiliser le script de Gilles adapté. Malgré des
serveurs Quadri-proceseurs je pleure!!!
Exemple un fichier fait plus de 195Mo lorsque je lance le script tout
part dans le rouge pendant presque une minute, je dois te dire que
c'est pas le pied pour des serveurs hypersensible. Du coup je crois
que je vais en rester au zip du fichier et au transfert complet
(4.5Mo apres compression) Laurent
Lut
pour info j'ai finalement utilisé tail.exe (legé, efficace et instantanée et
zero ressource)
Laurent
Salut Jacques J'ai en effet essaye d'utiliser le script de Gilles adapté. Malgré des serveurs Quadri-proceseurs je pleure!!! Exemple un fichier fait plus de 195Mo lorsque je lance le script tout part dans le rouge pendant presque une minute, je dois te dire que c'est pas le pied pour des serveurs hypersensible. Du coup je crois que je vais en rester au zip du fichier et au transfert complet (4.5Mo apres compression) Laurent
Lut pour info j'ai finalement utilisé tail.exe (legé, efficace et instantanée et zero ressource) Laurent
