raiderx
Goto Top

Text suchen und ersetzen (mal wieder)

Teile aus Textzeilen aus einer Datei raussuchen und durch anderen Text ersetzen

Hallo zusammen...

ich habe eine Schnittstellendatei, die verschiedene Datensätze einmal im Monat von einem Programm zum nächsten weiterreicht.
Hier zwei Beispielzeilen:
---snip
00820123412182xxxxxx xxxxxx xxxxxx 15 a xxxxxxxxxxxx 2009100120092 33,341xxxxxx, 1/2009 J100900xxxxxxxxxx03001
00841000002002 2009100120092 35,001xxxxx, 1/2009 N 001

Zeilen die wie folgt anfangen, müssten geändert werden:
84100000200 in 84100000219
84100000214 in 84100000220
84100000218 in 84100000221


Das vorherige Backup der Datei bekomm ich hin:
copy y:\Cipsol.txt y:\Cipsol_Backup.txt /Y
(nice to have: Wie fange ich einen nicht funktionierenden Kopiervorgang ab?)

Den Rest müsste ich mit findstr machen, aber da bekomm ich die Syntax nicht hin. In der Kommandozeile bekomm ich mit "findstr /b /L 0084100000200 y:\Cipsol.txt" zumindest die fraglichen Zeilen angezeigt, aber dann hörts auf.

Umgebung: Win XP/2000, Domänenumgebung, Admin-Rechte

Im Moment ratlose Grüße,
RX

Content-ID: 111033

Url: https://administrator.de/contentid/111033

Ausgedruckt am: 22.11.2024 um 15:11 Uhr

miniversum
miniversum 10.03.2009 um 21:20:42 Uhr
Goto Top
Wenn keine Sonderzeichen ()&<>% enthalten sind gehts so (ungetestet):
@echo off
if exist outDatei.txt del outDatei.txt
FOR /F "delims=" %%i in (inDatei.txt) do call:verarbeite "%%i"  
goto:eof

:verarbeite
set "line=%~1"  
if "%line:~0,11%" equ "84100000200" (  
>> outDatei.txt echo 84100000219%line:~11%
) else (
if "%line:~0,11%" equ "84100000214" (  
>> outDatei.txt echo 84100000220%line:~11%
) else (
if "%line:~0,11%" equ "84100000218" (  
>> outDatei.txt echo 84100000221%line:~11%
) else (
>> outDatei.txt echo %line%
)
)
)
Biber
Biber 10.03.2009 um 21:28:21 Uhr
Goto Top
Moin RaiderX,

ich poste da jetzt keine Lösung, bitte Dich aber, diesen Kommentar dennoch wohlwollend weiterzulesen.

Ich halte diesen automatisierten Prozess, den Du jetzt etablieren willst für handwerklich umsetzbar, aber für grundlegend falsch und gefährlich.

Begründung
Wir haben hier zwar pro Monat gefühlte 100 ähnlich klingende "Suchen- und Ersetzen in Textdateien"-Anforderungen, aber
  • es geht meist um Konvertierungen/Umformatierungen - die Reihenfolge in der Quelldatei ist anders als in der Zieldatei oder aus *.txt mach .csv
  • oder Filterungen/Selektionen - z.B. alle Dubletten wegfiltern oder nur die einer "1" im siebten Feld
  • oder um Gruppenverarbeitung - mach mir aus untrschiedlichen Kopf+Detaildatensätzen jeweils gleichförmige Sätze

-> ..... alles Suchen- und Ersetzen-Operationen, an denen am Layout der Quelldatei viel, aber am Inhalt, der gelieferten Information der Quelldaten eigentlich nichts geändert wird.

Okay, manchmal kommen Anforderungen wie "wenn in der Quelldatei ein Feld leer ist, soll in der Zieldatei dafür "NULL" stehen oder so - aber auch das ist eher nur Layoutfrage.

Was man/frau niemalsnienich tun sollte ist aber, sich mit einem automatisierten Prozess in eine dauerhaft bestehende Schnittstelle hängen und dort das, was die Quelle als ID "X" liefert dem Ziel als "ID "U" unterjubeln.

Wenn es eine einmalige Aktion wäre - ich müsste alle bisherigen Artikelnummern 0815 in 4711 umändern, weil wir halt den Nummernkreis neu geordnet haben - dann okay.

Aber wie Du es schreibst, nämlich zwei Systeme, die offensichtlich die (logisch) gleichen Datensätze unter vollkommen unterschiedlichen IDs kennen........
---> steck da keine 5 Minuten Aufwand rein, diese Dateninkonsistenz noch mit einem Suchen/Ersetzen sozusagen unsichtbar zu machen.
Im Gegenteil -
  • hol Dir die Verantwortlichen/Betreiber der beiden Programme ran,
  • leg Deine o.g. Erkenntnisse bzgl der Schlüsselinkompatibilität auf den Tisch
  • und sag "Ich möchte jetzt mal eine Aussage, bis wann diese in Euren beiden Systemen unter unterschiedlichen Schlüsseln bekannten Objekte (oder Artikel oder Vorgangsnummer oder was immer es ist) wieder synchron sind."
  • dann schliesst Du Tür von innen ab, steckst den Schlüssel ein, setzt Dich wieder und fängst an, Zeitung zu lesen.

Mit allem anderen - insbesondere mit der Manipulation der gelieferten Quelldaten vor der Ablieferung beim Empfänger- machst Du Dich zum Täter statt zum Helfer.

Grüße
Biber
IrrerIvan
IrrerIvan 12.07.2010 um 10:33:59 Uhr
Goto Top
Morgen zusammen,

hmm.. ich habe mir natürlich deinen Kommentar durchgelesen.

Ich habe dazu eine Frage.

Ich möchte auch eine Schnittstelle auslesen, dessen Dateiinhalt so aussieht:

B;0;001;;;;LG;30062010;062010;;1;481000;;;;1000;;;G;0;680000;;;100;;K;0;0300;;;;;;1000;481000;


Das Ziel soll dann so aussehen, damit es in ein anderes Programm eingelesen werden kann...


B;0;001;;;;LG;30062010;062010;;1;481000;;;;1000;;;
G;0;680000;;;100;;
K;0;0300;;;;;;1000;481000;

Ist das sinnvoll / möglich? / ratsam?


VG iI
Biber
Biber 12.07.2010 um 11:45:09 Uhr
Goto Top
Moin IrrerIvan,

willkommen im Forum.

Soweit ich deine Beschreibung interpretieren kann, manipulierst du die Daten ja nicht inhaltlich.
Sondern nimmst nur eine Untermenge der (angebotenen) Spalten der Schnittstelle.

Okay, genau so soll es ja auch sein.

Die Problematik oben war ja eine andere.

Da war es so, dass die Schnittstelle Sätze bereitstellt, und alle die nun "Fritz" und "Heinz" heißen sollen durch eben mal als "Klaus" und "Bärbel" weitergereicht werden.

Das ist NICHT schön... denn wenn mal ein Datenschiefstand auftritt
-> und der Absender kann belegen, dass er aber "Fritz" und "Heinz" losgeschickt hat,
-> und der Empfänger kann belegen, dass bei ihm weder "Fritz" noch "Heinz" angekommen sind, dafür aber zwei bei ihm bestehende Datensätze namens "Klaus" und "Bärbel" mit falschen Daten überklatscht würden...

Hey, dann ist die nächste Import/Export-Schnittstelle, die du programmieren darfst an der Nordküste von Feuerland.

Gegen dein "Weglassen von nicht benötigten Feldern" (wie ich es interpretiere) spicht gar nichts.

[ Anmerkung: ich kann aber nur Antworten so treffsicher geben, wie der Input detailliert und vollständig ist.
Du hast 5 Zeilen gefragt und ich 15 geantwortet.--> Muss nicht heißen, dass wir beide jetzt alles berücksichtigt haben]

Grüße
Biber
IrrerIvan
IrrerIvan 12.07.2010 um 12:25:42 Uhr
Goto Top
Danke erst mal für deine unglaublich zügige und auch witzige Antwort.

Also ich möchte eigentlich nix großartig weglassen. Sondern die Datei umformatieren. Und zwar so, daß die Daten halt nicht in einer Zeile stehen, sondern in zwei respektive drei Zeilen. Sonst kann das zweite Programm die Daten nicht einlesen. Es geht speziell um Buchungen über eine Schnittstelle.
Das Vorsystem gibt sie Einzeilig aus während das nachgelagerte System die dreizeilig haben möchte. o.O

gibt wohl noch keine Norm für Schnittstellen.

Ich kann auch sagen welche Systeme betroffen sind. Das eine ist eine I800 IBM und das andere ist Windows (SQL-Server)


Grüße iI
Biber
Biber 12.07.2010 um 12:46:32 Uhr
Goto Top
Moin IrreIvan,

eine Umformatierung von einer auf eine mehrere Zeilen ist auch nicht zwingend eine Datenmanipulation.
Solange du nicht - wie oben beschrieben - aus einzelnen Datensätzen mit "X" Datensätze mit "U" machst (mit wie edlen Hintergedanken auch immer), solange machst du nichts Nicht-reprozierbares.

Ich habe auch Schnittstellen hier, der halt nur in einem verkack propieritären Herstellerformat rausgedrückt werden, das so nicht automatisiert weiterverarbeitet werden kann. --> muss ich auch "umformatieren".
Ich habe auch den Fall, das bei einer Schnittstelle ein "nicht gesetztes Endedatum" als "31.12.9999" exportiert wird. --> muss ich in allen Datensätzen vorher auf auf einen Wert ändern, der beim Empfänger "richtig" interpretiert werden,--> "so, wie es der Absender gemeint hat".

Und das letzte Unterstrichene wäre dann meine ganz persönliche Abgrenzung von "Datenumformatierung vs.Datenmanipulation."
Das kann ich beim Bau einer Schnittstelle vertreten und fachlich begründen.
Das Datenverfälschen von "Heinz" zu "Bärbel" aber nicht.

Grüße
Biber
IrrerIvan
IrrerIvan 12.07.2010 um 13:28:45 Uhr
Goto Top
OK. kapiert. Formatieren OK. Manipulieren NICHT OK!

Jetzt meine finale Frage. Wie müsste denn die Batch-Datei aussehen, damit ich das bewerkstelligen kann?
Also ab einem bestimmten Ausdruck die nächste Zeile beginnen oder so! Weil die Ausgabedatei kann ich schon ein wenig beeinflussen aber halt nicht eine neue Zeile schreiben lassen. Sch.. IBM.

Habe das schon mit Ausdrücken wie \p und so versucht, aber das fruchtet alles nicht. SQL kann ich auch nicht (bzw. zu wenig) face-confused


iI
Biber
Biber 12.07.2010 um 13:51:12 Uhr
Goto Top
Moin Irrerivan,

ich denke, dass ist rein handwerklich auch ohne mehrjähriges Informatik- oder Seifensiederstudium machbar

Dazu haben einige Dutzend Beispiel hier im Forum.

  • Für das Einlesen einer mit Semikolonnen getrennten Zeile mit Werten ist im Batch die FOR /F-Anweisung zuständig.
  • Für das Rausdrücken der ECHO-Befehl.

Hilfe dazu mit FOR /? bzw ECHO /? am CMD-Prompt.

Beispiel - deine Input-Zeile sieht so aus:
B;0;001;;;;LG;30062010;062010;;1;481000;;;;1000;;;G;0;680000;;;100;;K;0;0300;;;;;;1000;481000;

Als proof-of-concept möge reichen:
>set "einezeile=B;0;001;;;;LG;30062010;062010;;1;481000;;;;1000;;;G;0;680000;;;100;;K;0;0300;;;;;;1000;481000;"

(=13:47:11  F:\Tüddlkrams=)
>for /f "tokens=1-22 delims=;" %a in ("%einezeile%") do @(echo %a;%b;%c) & (@echo %g;%i%;%i) & @echo %r;%u;%v;
B;0;001
1;1000%;1000
481000;;;

Versuch dich ranzutasten... wenn es gar nicht allein voran geht, dann mach bitte einen eigenen Beitrag auf.
Der hier riecht schon etwas streng.

Grüße
Biber
IrrerIvan
IrrerIvan 14.07.2010 um 21:38:08 Uhr
Goto Top
Jo, werde ich machen, aber erst Montag. Vorher komme ich wohl nicht dazu!!!

Schönes Wo-Ende und danke...


iI
Biber
Biber 15.07.2010 um 08:08:13 Uhr
Goto Top
Moin,


da hier wohl kein Feedback vom Beitragsersteller RaiderX mehr kommen wird, schliesse ich den Beitrag "ungelöst".

@IrrerIvan
Wir sehen uns ggf. im neuen Thread.

Grüße
Biber