Lecture fichier TXT caractère parasite ° →

Lecture fichier TXT caractère parasite ° → - VB/VBA/VBS - Programmation

Marsh Posté le 18-02-2017 à 16:53:56    

bonjour
j'ai fais un macro qui permet de lire le contenu d'un fichier texte et qui en extrait certaines infos
cela fonctionne bien, la macro me convient parfaitement
en moins de 15s je lit des fichiers de 1 000 000 lignes et le résultat est 10 fois moins lourd
bref parfait, enfin presque !
 
 
certains fichiers textes contiennent un caractère parasite
il ressemble a cela  →
il correspond à degré, ou °
il provient d'extracts que j'ai fait via SAP=>TXT
 
le problème que j'ai,  c'est que la macro considère ce caractère comme ...fin de l'histoire
 
jugez par vous même
 

Code :
  1. Private Sub CommandButton1_Click()
  2. Dim inputdata As String
  3. Dim separateur As String
  4. Dim n As Single
  5. Open ActiveDocument.Path & "testbug.txt" For Input As #1
  6. Do While Not EOF(1)
  7.     Line Input #1, inputdata
  8. MsgBox inputdata
  9. Loop
  10. Close #1
  11. 'contenu du fichier texte  testbug.txt
  12. '|00|000|SAPGEC      |OF|DECORATION EXT-OA1                      |18.06.2003|      |
  13. '|00|000|SAPGEC      |OF|DECORATION EXT-OA2                      |26.12.2000|      |
  14. '|00|000|SAPGEC      |OF|DECORATION EXT-OA3                      |18.06.2003|      |
  15. '|00|000|SAPGEC      |VL|DECORATION EXT-OA4                      |26.12.2000|      |
  16. '|00|000|SAPGEC      |OF|DECORATION EXT-OA5                      |18.06.2003|      |
  17. '|00|000|SAPGEC      |OF|ANGLE BRAQUAGE 90                      |18.06.2003|      |         edit, normalement il y a → derrière 90
  18. '|00|000|SAPGEC      |OF|ANGLE BRAQUAGE 90                      |26.12.2000|      |
  19. 'etc....
  20. End Sub


logiquement avec ce code les 7 ligne devraient être lu
dans la réalité, avec ce caractère, la dernière et les suivante seront ignorées
car après 90→  la macro sort


Message édité par daniel-12 le 18-02-2017 à 17:17:03
Reply

Marsh Posté le 18-02-2017 à 16:53:56   

Reply

Marsh Posté le 18-02-2017 à 17:00:09    

ben voila !
sur TXT il apparait
en VBA, il reste visible
en passant sur le forum, il disparait  :o  
 
le voila quand même :D  
http://nsa38.casimages.com/img/2017/02/18/mini_170218051721670711.jpg
 
 
question :
comme faire pour que ce caractère spécial ne me fasse pas sortir de la macro ?
 
si vous lancez le code fourni, vous verrez (si le caractère est présent) que des qu'on arrive a ce caractère, la boucle se termine sans lire les ligne desous


Message édité par daniel-12 le 18-02-2017 à 17:00:51
Reply

Marsh Posté le 19-02-2017 à 06:30:13    

Salut, voir http://silkyroad.developpez.com/VB [...] aracteres/ avec Clean qui supprime les caractères non imprimables ?


---------------
Myanmar 90/91 : http://gadaud.gerard.free.fr/publi [...] index.html
Reply

Marsh Posté le 19-02-2017 à 11:17:08    

je suis allé voir
mais cela semble fonctionner pour excel
 
Cell.Value = Application.WorksheetFunction.Clean(Cell.Value)
 
je ne travaille que avec du TXT
 
j'ai bien essayé avec la fonction REPLACE, mais je n'y arrive pas
j'ai l'impression que cette petite flêche est considéré comme la fin du fichier

Reply

Marsh Posté le 19-02-2017 à 12:22:44    

je viens de tester une autre solution, avec du VBS
http://wiki.dane.ac-versailles.fr/ [...] hier_texte
 
j'ai donc remplacé les caractères accentués su lien par  
-une fleche
-un °
 
j'ai enregistré le VBS, et le l'ai lancé
et après verif du VBS , vola ce que je trouve
 
cette satanée flêche s'est transformée en ?
 
    accents = "?"
    pas_accents = "°"
 
 

Reply

Marsh Posté le 19-02-2017 à 16:33:09    

 
            Bonjour,
 
            rien qu'avec un éditeur en hexadécimal pour voir le code du caractère
            ou encore en VB / VBA / VBS avec la fonction ASC pour lire son code
            bref, ce n'est vraiment pas compliqué de l'effacer via la fonction Replace …
 
            Et comme ce n'est pas un caractère parasite mais faisant bel et bien partie de la source,
            ce serait tellement plus judicieux d'intervenir côté SAP afin de produire une extraction propre !
 

Reply

Marsh Posté le 19-02-2017 à 16:38:02    

 
            Et si c'est juste une question d'encodage de caractères, donc encore une fois ce n'est pas un caractère parasite,
            utiliser par exemple ADODB.Stream (cf documentation sur MSDN) pour effectuer la lecture du fichier texte
            en spécifiant le bon encodage source.   Qui plus est cet objet est bien plus rapide en lecture / écriture de fichier !
 

Reply

Marsh Posté le 20-02-2017 à 22:16:17    

bonsoir
je sais bien qu'il serait judicieux de ne pas avoir ce caractère quand le fais l'extract sous SAP, mais je n'ai pas trouvé de solution via SAP
 
pour info, notepad++ affiche SUB  à la place de ce caractère
il semblerai aussi qu'il soit reconnu comme chr(26)
 
aujourd'hui la solution la plus simple que j'ai trouvé fonctionne
j'edite avec notepad le fichier TXT
je cherche ce caractère, puis le remplace
 
 
ADODB.Stream, je ne connais pas, je ne vais pas me lancer la dessus
je suis quand confiant qu'il y a un moyen de dire a VBA de supprimer, convertir, ou ignorer ce caractère
 
 
 
 

Reply

Marsh Posté le 21-02-2017 à 00:21:45    

Citation :

aujourd'hui la solution la plus simple que j'ai trouvé fonctionne
j'edite avec notepad le fichier TXT
je cherche ce caractère, puis le remplace


Si c'est ça la méthode retenu ça peut s'automatiser. L'outil Linux "sed" existe aussi pour Windows, c'est un petit exécutable de 50kB qu'on peut appeller depuis un batch avec les arguments qui vont bien: https://en.wikipedia.org/wiki/Sed#Substitution_command

 

edit: En supposant qu'il existe une commande system() ou autre en VBA on peut automatiser encore plus. Bien sûr c'est pas propre, mais si ça fait l'affaire...


Message édité par rat de combat le 21-02-2017 à 00:23:23
Reply

Marsh Posté le 21-02-2017 à 00:34:14    

 
            Ce caractère existe-t-il bien côté SAP ou pas ?   Dans le sens y-a-t-il bien un caractère après 90 ?
 
            Aucun souci en VBA pour supprimer un caractère via la fonction  Replace  par exemple.
            Si le fichier était accessible, je pourrais facilement me faire une idée …
             
            ADODB.Stream étant bien plus rapide, facile en prendre en main, suffit de lire sa doc sur MSDN.
 

Reply

Marsh Posté le 21-02-2017 à 00:34:14   

Reply

Marsh Posté le 21-02-2017 à 09:04:37    

attention
je ne suis pas un administrateur sous SAP, juste un simple utilisateur
le caractère y est, je pense, je confirme ce soir
 
l'extract je le fais manuellement (en maintenant en vbscript) puis j'enregistre la liste obtenu
 
ce soir je vous posterai un apercu du fichier

Reply

Marsh Posté le 21-02-2017 à 20:55:15    

j'ai mis un apercu du fichier dans le ZIP
Fichier : http://www.partage-fichiers.com/upload/wy7hwgnq
 
Utilisateur : p75cgpj3
Mot de passe : kvp1c1c6

Reply

Marsh Posté le 22-02-2017 à 00:09:47    

 
            Comme d'hab' encore une exportation de SAP un peu pourrie, au prix du logiciel et du gars chargé de son exploitation !
            Un problème de paramétrage certainement à revoir car si c'est bien le caractère du degré ° présent dans la base
            c'est franchement anormal de générer à la place le caractère standard de fin de fichier ‼
 
            Voici une démonstration réalisant une lecture ligne à ligne en utilisant l'objet Stream plus rapide,
            le caractère étant corrigé au passage, l'affichage est effectué dans la fenêtre Exécution du VBE :
 

Code :
  1. Sub Demo()
  2.               TXT$ = ActiveDocument.Path & "\bug.txt"
  3.        If Dir(TXT) = "" Then Beep: Exit Sub
  4.                 C$ = Chr$(26)
  5.    With CreateObject("ADODB.Stream" )
  6.                 .Charset = "windows-1252"
  7.                 .Open
  8.                 .LoadFromFile TXT
  9.        Do Until .EOS
  10.            Debug.Print Replace$(.ReadText(-2), C, "°" )
  11.        Loop
  12.                 .Close
  13.    End With
  14. End Sub


            Comme documenté sur MSDN cet objet peut aussi effectuer une lecture complète du fichier en mémoire en une passe
            permettant d'extraire le nécessaire via la fonction VBA  Split  …
 

Reply

Marsh Posté le 22-02-2017 à 23:57:56    

ok,  
merci pour ce morceau de code
je vais essayer de l'adapter à mes besoins
 
pour ce qui est de l'extract avec des caractère farfelus, il faut savoir que ces données ont été mainte en mainte fois copiées, déplacées
certaines datent de 30ans, d'autre de 30j
les avoir toutes sur le même extract avec seulement ce soucis, je m'en accommoderai

Reply

Marsh Posté le 23-02-2017 à 11:35:18    

 
            Peu importe, le paramétrage d'extraction doit être corrigé si ce n'est la base elle-même …
 

Reply

Marsh Posté le 01-03-2017 à 10:30:53    

Hello,
Ce n'est pas forcément que ta flèche (ou n'importe quel autre caractère étendu) est interprété comme un EOF.
Renvoyer EOF est aussi la façon que certaines API de lecture de fichiers mal branlées ont de te dire "erreur de lecture".

 

Je vais peut être dire une grosse bêtise parce que je ne fais pas de macro, mais plutôt qu'utiliser "Open" tu ne pourrais pas utiliser un Scripting.FileSystemObject et lui spécifier l'encoding ?
Ca permettrait de mieux gérer les caractères spéciaux. Avec un peu de chance il sera lu "tel quel" plutôt que fermer le flux, à défaut d'être lu comme un °.

 

edit : un truc comme ça si tu y as accès : http://stackoverflow.com/a/10997824/461444

Message cité 1 fois
Message édité par TotalRecall le 01-03-2017 à 10:31:37

---------------
Topic .Net - C# @ Prog
Reply

Marsh Posté le 01-03-2017 à 11:19:25    

 
            Stream étant plus rapide que FSO et vu le nombre de lignes …
 

Reply

Marsh Posté le 01-03-2017 à 11:32:23    

A tester. Un truc un peu plus lent c'est mieux qu'un autre plus rapide qui plante...


---------------
Topic .Net - C# @ Prog
Reply

Marsh Posté le 01-03-2017 à 14:48:31    

 
            L'utilisant depuis des années il ne plante pas - sinon je n'aurais pas proposé le code plus haut ! - et il a plus de possibilités que FSO …
 

Reply

Marsh Posté le 01-03-2017 à 14:55:19    

Il ne plante pas mais il renvoie un EOF pour un caractère qui n'est pas un EOF [:orly2]


---------------
Topic .Net - C# @ Prog
Reply

Marsh Posté le 01-03-2017 à 14:57:50    

Pour info : https://en.wikipedia.org/wiki/Substitute_character
Ca parle même du VB...


---------------
Topic .Net - C# @ Prog
Reply

Marsh Posté le 01-03-2017 à 21:28:39    

Ne vous inquietez pas cela m'ira
 
cela semble fonctionner, il me faut juste l'adapter pour mon programme
Pour le moment, je fait à la méthode ....débutant
j'ouvre avec notepad, je cherche la satanée flêche, puis la remplace dans le document complet
Mais je suis au courant du problème et je connais une solution rapide
 
mais si je dois laisser quelqu'un d'autre utiliser le programme, il me faudra le fiabiliser, et je sais maintenant comment  
 

Reply

Marsh Posté le 01-03-2017 à 21:32:01    

Total recall, je l'avais vu cette page wiki
et j'avais bien identifié le problème et traduit comme cela sur mon premier post
"le problème que j'ai,  c'est que la macro considère ce caractère comme ...fin de l'histoire"
 
mon soucis était de le contourner  
 
et oui, sur wiki ils disent:
Some programming languages (e.g. Visual Basic) will not read past a "soft" EOF when using the built-in text file reading primitives (INPUT, LINE INPUT etc.), and alternate methods must be adopted, e.g. opening the file in binary mode or using the File System Object to progress beyond it.
 
le soucis c'est que je suis un débutant en tout !
et FSO je n'avais jamais utilisé
 
Merci en tout cas pour votre aide  :jap:


Message édité par daniel-12 le 01-03-2017 à 21:33:40
Reply

Marsh Posté le 02-03-2017 à 01:32:05    

 
            FSO donne exactement le même résultat qu'avec Stream vu le fichier texte source
            comme aurait dû le constater TotalRecall avec un éditeur hexadécimal ‼
 
            Mon idée initiale était de rester en pur VBA avec une lecture en mode binaire
            mais comme tu as indiqué un million de lignes j'ai préféré t'orienter vers Stream au lieu de FSO
            sans compter la finalité non précisée …
 
            Mais si tu préfères rester dans la banalité / généralité en utilisant FSO, aucun souci
            et comme pour Stream sa documentation est consultable sur MSDN et à la portée d'un débutant.
 

Reply

Marsh Posté le 02-03-2017 à 01:41:46    

TotalRecall a écrit :

Il ne plante pas mais il renvoie un EOF pour un caractère qui n'est pas un EOF


             T'as vu jouer cela où ?   :??:    Et sans tester, bravo !   Il n'y a plus qu'à s'incliner devant une telle science infuse ‼   :jap:  
 
             Stream et FSO renvoient exactement le même résultat et  
             ce n'est pourtant pas compliqué à vérifier, premier point à effectuer avant de poster une quelconque assertion …  :sarcastic:
 

Reply

Marsh Posté le 02-03-2017 à 09:26:55    

Marc L a écrit :


             T'as vu jouer cela où ?   :??:    Et sans tester, bravo !   Il n'y a plus qu'à s'incliner devant une telle science infuse ‼   :jap:

 

            Stream et FSO renvoient exactement le même résultat et
             ce n'est pourtant pas compliqué à vérifier, premier point à effectuer avant de poster une quelconque assertion …  :sarcastic:
 


Bonjour,
En plus d'avoir ta barre espace coincée dans chacun de tes posts, si tu as vu dans ce message une quelconque affirmation péremptoire il semble que tu aies aussi des problèmes de lecture.

 

daniel-12 arrive avec un souci de lecture où la fonction qu'il utilise ne sait pas interpréter un caractère et du coup interrompt complètement la lecture (c'est lui qui le dit) et du coup je lui suggère de tester une méthode alternative qui pourrait être exempte de ce problème. Ca ne me parait pas complètement déconnant comme approche, à défaut de pouvoir éviter la présence de ce caractère (ou d'autres qui produiraient la même anomalie) dans le flux à charger. Peut être effectivement que ça aurait produit la même anomalie, et je n'ai pas fait l'essai, j'ai juste dit que c'était à envisager vu que c'est rapide à faire.


Message édité par TotalRecall le 02-03-2017 à 09:28:33

---------------
Topic .Net - C# @ Prog
Reply

Marsh Posté le 02-03-2017 à 11:13:13    

 
             Péremptoire ?‼   :lol:   Balaie devant ta porte !

TotalRecall a écrit :

mais plutôt qu'utiliser "Open" tu ne pourrais pas utiliser un Scripting.FileSystemObject et lui spécifier l'encoding ?
Ca permettrait de mieux gérer les caractères spéciaux. Avec un peu de chance il sera lu "tel quel" plutôt que fermer le flux, à défaut d'être lu comme un °.


             Ici pas trop mais un peu quand même, la seconde assertion étant fausse, le fichier texte n'ayant même pas été ouvert !
             Car une fois pour toute, le fichier ne contient pas le caractère ° mais bien → !   Et en cas de problème d'encodage
             il y aurait des soucis sur d'autres caractères vu le fichier en exemple, il suffit juste de l'ouvrir !
 
             Au passage si le fichier est encodé en utf-8 par exemple, comment « spécifier l'encoding » à FSO ?
             Eclaire donc ma pauvre p'tite lanterne !
 
 

TotalRecall a écrit :

A tester. Un truc un peu plus lent c'est mieux qu'un autre plus rapide qui plante...


             Là totalement péremptoire car toujours sans tester affirmant Stream plantant alors que cela fonctionne du côté du demandeur et du mien !
             Et si tu tentes de te rattraper en affirmant que tu ne parlais pas de Stream, juste en relisant le fil pourtant,
             il faudrait alors à l'avenir bien préciser ta pensée pour éviter de pouvoir mal interpréter tes dires !
 
 

TotalRecall a écrit :

Il ne plante pas mais il renvoie un EOF pour un caractère qui n'est pas un EOF [:orly2]


             Du péremptoire au plus haut degré !  Un léger mieux car il ne plante plus mais renvoyant un caractère pour un autre,
             là encore on voit que le fichier texte n'a même pas été ouvert !
 
             Pour moi c'est clos, j'attends juste un exemple FSO pour l'encoding, merci …
 
            _______________________________________________________________________________________________________________
 
              Deux choses sont infinies : l’Univers et la bêtise humaine.
              Mais en ce qui concerne l’Univers, je n’en ai pas encore acquis la certitude absolue ! (Albert Einstein)
 

Reply

Marsh Posté le 02-03-2017 à 11:31:34    

Tu le fais exprès ou quoi ? Si tu ouvres un fichier de 1 million de lignes et que ton API, quelle qu'elle soit, s'arrête de lire dès qu'elle rencontre un caractère qui ne lui plait pas, tu ne penses pas qu'on peut considérer ça comme une anomalie et suggérer des méthodes alternatives ?
 
Maintenant moi j'ai fini de te parler, tu peux remballer tes citations recyclées à toutes les sauces et attendre ce que tu veux aussi longtemps que tu voudras.  


---------------
Topic .Net - C# @ Prog
Reply

Marsh Posté le 02-03-2017 à 11:58:51    

 
             Mais de quelle API parles-tu enfin ?‼
 
             C'est bien facile d'affirmer un truc et de se barrer en courant dès que l'on te demande une explication digne de ce nom ‼
 

Reply

Marsh Posté le 02-03-2017 à 20:27:00    

Désolé Marc L, je ne mettrai pas en doutes tes compétences en VBA mais sur ce coup là je te trouve bien arrogant, surtout vu la citation d'Einstein que tu as posté. :o  N'oublie pas que tu parles à un membre ayant 41363 messages sur ce forum et qui a dû aider pleins de gens, pas à un nouveau inscrit qui veut qu'on fasse son boulot et qui devient aggressif parce qu'on lui renvoye le reglèment ou quelque chose comme ça! Si TotalRecall se trompe (j'en sais rien) alors on peut en discuter tranquillement et avec des arguments (notamment un exemple de code).
 
Bon, je me mêle d'histoires qui ne me regardent pas mais sur ce coup là je n'ai pas pu m'en empêcher.

Reply

Marsh Posté le 02-03-2017 à 23:44:42    

 
            Ayant de mon côté déjà posté un exemple de code et pour le reste j'ai été clair, n'ayant rien vu de concret en retour …
 

Reply

Marsh Posté le 09-03-2017 à 14:05:08    

[:bonux]

Reply

Marsh Posté le 05-05-2017 à 22:17:24    

Code :
  1. Sub Demo()
  2.     T = Timer
  3.                    TXT$ = ActiveDocument.Path & "bug.txt"
  4.                  
  5.             If Dir(TXT) = "" Then Beep: Exit Sub
  6.                      C$ = Chr$(26)
  7.                    
  8.        Open ActiveDocument.Path & "resultat.txt" For Output As #1
  9.         With CreateObject("ADODB.Stream";)
  10.                      .Charset = "windows-1252"
  11.                      .Open
  12.                      .LoadFromFile TXT
  13.             Do Until .EOS
  14.            
  15.             SC = Replace$(.ReadText(-2), C, "°";)  'string corrigée, caractère fleche chr26 remplacé par °
  16.          
  17.                 If Mid(SC, 15, 1) = " " Then
  18.                 Print #1, Mid(SC, 6, 9) & "%" & Mid(SC, 55, 40)
  19.              
  20.                 End If
  21.             Loop
  22.                      .Close
  23.         End With
  24.         Close #1
  25.     Debug.Print "Demo1 : "; Format(Timer - T, "0.000s";)
  26.        
  27.     End Sub


Bonsoir
Marc, j'ai utilisé ton code pour enlever le caractère parasite, mais j'ai un soucis
c'est long
 
par exemple, si je traite un fichier de 1 500 000 lignes, je mettais 45s pour le traiter (sous reserve d'avoir edité le caractère avant)
avec le code posté, qui édite le caractère, et traite ensuite le fichier, je mets 290s
 
ou est ce que je peux améliorer le code
les lignes sont faite comme cela
 
|PLA|F00010021                |00|000|SAPGEC      |OF|ENS GEOMETRIES ST2                      |18.06.2003|      |
|PLA|F00010021-H00            |00|000|SAPEXPL     |OF|ENS GEOMETRIES ST2                      |09.06.2003|      |
|PLA|F00010021_001            |00|000|SAPGEC      |OF|ENS GEOMETRIES ST2                      |18.06.2003|      |
|PLA|F00010021_001_H00        |00|000|SAPEXPL     |OF|ENS GEOMETRIES ST2                      |09.06.2003|      |
 
ce que je veux extraire c'est=> F00010021%ENS GEOMETRIES ST2


Message édité par daniel-12 le 05-05-2017 à 22:23:10
Reply

Marsh Posté le 06-05-2017 à 09:31:00    

 
           Bonjour,
 
           voir déjà en utilisant l'objet Stream aussi pour l'écriture du fichier comme dans ton autre discussion …


Message édité par Marc L le 06-05-2017 à 09:31:14
Reply

Marsh Posté le 06-05-2017 à 09:51:43    

 
           Sans pouvoir tester avec un fichier réel, je me demande si
           ce serait plus rapide d'effectuer directement un rechercher / remplacer dans Notepad++ …
 

Reply

Marsh Posté le 06-05-2017 à 09:57:12    

c'est ce que je fait actuellement !
le soucis c'est qu'il me faut penser à le faire

Reply

Marsh Posté le 06-05-2017 à 09:59:10    

 
           Et on aimerait bien voir aussi le code original ne mettant que 45 secondes …

Message cité 1 fois
Message édité par Marc L le 06-05-2017 à 10:00:05
Reply

Marsh Posté le 06-05-2017 à 10:38:42    

 
           Au cas où, sait-on jamais …   (VBA Excel)
 

Code :
  1. Sub Demo2()
  2.        Dim oStr(1) As Object, C$, F, T!, N%, SP$(), S9 As String * 9
  3.        C = ThisWorkbook.Path & "\"
  4.        F = Array(C & "bug.txt", C & "result.txt" )
  5.        If Dir(F(0)) = "" Then Beep: Exit Sub
  6.        T = Timer
  7.        C = Chr$(26)
  8.    For N = 0 To 1
  9.        Set oStr(N) = CreateObject("ADODB.Stream" )
  10.            oStr(N).Charset = "x-ansi"
  11.            oStr(N).Open
  12.    Next
  13.            oStr(0).LoadFromFile F(0)
  14.   Do Until oStr(0).EOS
  15.            SP = Split(oStr(0).ReadText(-2), "|" )
  16.            S9 = SP(2)
  17.            oStr(1).WriteText S9 & "%" & Replace$(SP(7), C, "°" ), 1
  18.   Loop
  19.            oStr(1).SaveToFile F(1), 2
  20.    For N = 0 To 1
  21.            oStr(N).Close
  22.        Set oStr(N) = Nothing
  23.    Next
  24.        Debug.Print "Demo2 : "; Format(Timer - T, "0.000s" )
  25. End Sub


Message édité par Marc L le 06-05-2017 à 11:00:04
Reply

Marsh Posté le 06-05-2017 à 11:33:10    

sur un petit fichier cela marche, pas sur un gros
erreur exécution 9, l'indice n'appartient pas a la sélection
 
et cela garde les 4 lignes, j'ai donc des doublons

Reply

Marsh Posté le 06-05-2017 à 11:44:29    

 
            Oui les doublons sont conservés comme dans ton code et
            c'est tellement plus facile quand le besoin est clairement expliqué !
 
            L'erreur provient du fichier ne correspondant pas à ce que tu as posté et,
            sans indication précise de la ligne du fichier source et de la ligne de code déclenchant cette erreur,
            je ne pourrais deviner, tout au plus ajouter un test dans le code mais allongeant donc l'exécution …
 
            Donc il faut extraire les codes de la deuxième colonne sur neuf caractères,
            écrire dans le fichier résultat si ce n'est pas un doublon tout en remplaçant le caractère parasite,
            what else ?!


Message édité par Marc L le 06-05-2017 à 11:47:03
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed