2 INI Dateien vergleichen

[Sir Rufo]

Abgesehen davon, dass ich die Struktur suboptimal finde und etwas an den Fähigkeiten einer Uni-Datei vorbeiorganisiert ist - und eine echte Datenbank (sei es auch Access) besser wäre - hier ein Lösungsansatz für dein Problem:

Du beschreibst eigentlich genau das Problem. Erst wenn das Element aus Tabelle A mit allen Elementen aus der Tabelle B verglichen wurde, kann man zuverlässig sagen, ob dieses Element in Tabelle B existiert oder eben nicht.

Code:

Für alle Artikel in Tabelle A -> ArtA

  FlagExistiert <- Falsch

  Für alle Artikel in Tabelle B -> ArtB
    Wenn ArtB = ArtA dann FlagExistiert <- Wahr
  Ende Für

  Wenn Nicht FlagExistiert dann
    ArtA in Tabelle B anlegen
  Ende Wenn

Ende Für

[Uwe Raabe]

Da ich ja gestern Abend wohl schon arge Konzentrationsprobleme hatte, nun nochmal von vorn:

Delphi-Quellcode:

TInifile.ValueExists

bringt dir, wie du schon bemerkt hast, in diesem Fall gar nichts, da es lediglich prüft, ob in einem "Datensatz" ein "Feld" Artikelnummer existiert - das tut es aber immer.

Der Sir hat insofern auch Recht, daß die Verwendung einer INI-Datei als Datenbank in hohem Grade suboptimal ist, da sie dafür nicht gedacht ist. So gestaltet sich das Suchen nach Datensätzen mit bestimmten Feldinhalten als äußerst schwierig, wie wir hier alle feststellen können.

Mit der aktuellen Datenstruktur in den INI-Dateien bleibt nur ein verschachtelter Schleifendurchlauf, wie ihn Sir Rufo skizziert hat. Ich würde in der inneren Schleife allerdings noch ein Break einbauen, wenn der Datensatz gefunden wurde.

Um die Datenstruktur zu verbessern, könnte man die Sections nicht mit der Recordnummer versehen, sondern z.B. mit der Artikelnummer, die ja offensichtlich ein eindeutiger Schlüssel ist. So kann man einfach prüfen, ob eine Artikelnummer vorhanden ist:

Delphi-Quellcode:

TInifile.SectionExists

. Beim Löschen oder Umbenennen einer Artikelnummer muss dann allerdings die alte Section gelöscht werden:

Delphi-Quellcode:

TInifile.EraseSection

.

Aus Performancegründen würde sich auch die Verwendung von

Delphi-Quellcode:

TMemInifile

anbieten - vorausgesetzt, die Dateien sind nicht übergroß; aber dann wäre eh eine andere Lösung angebracht. Bei

Delphi-Quellcode:

TMemInifile

das

Delphi-Quellcode:

UpdateFile

nicht vergessen, um Änderungen auf die Platte zu schreiben.

Und ich habe aus diesem Thread auch was gelernt: Wenn jemand mit dem Zaun wedelt, pass auf, daß kein Brett vor deinem Kopf hängen bleibt.

[Dr. Jack]

Ok danke für die Struktur und die sehr ausführlichen Hinweise, das werde ich nun versuchen umzusetzen.
Ich hoffe ihr seht mir die aus eurer Sicht einfachen Fragen nach :-)

[Dr. Jack]

Tausend Dank, ich hab es... Die Flagvariable ist die Lösung.

(OK die INI-Datei ist wirklich suboptimal, aber sie schafft für das kleine Programm
ca. 70 Artikel/ Sekunde zu lesen :-) )

[himitsu]

PS: INI über die WinAPI (da braucht man sich nicht wundern, daß diese veraltet und nur für kleine Daten ist) lädt die Datei nicht beim Create.
Und TIniFile kapselt nur die API.

Für jeden einzelnen Lesezugriff wird jedesmal die ganze Datei neu geladen, der Wert gesucht und alles wieder entladen.
Und noch schlimmer sind Schreibzugriffe, wo ebenfalls bei jedem Zugriff die Datei neu gelesen, der Wert verändert, alles zurückgeschrieben und entladen wird.

[Bjoerk]

Die Vorgehensweise dürfe überhaupt relativ fehleranfällig sein. Was machst du denn z. B bei sowas:

Remotefile
[Section1]
Ident1 = 1234

DB
[Section1]
Ident1 = 5678

Angenommen, 1234 ist in der gesamten DB nicht vorhanden, soll also upgedatet werden, der Eintrag ist in der DB jedoch anderweitig vergeben!?

[Dr. Jack]

@Bjoerk: Bei den "Nummern" handelt es sich um 8 bzw. 13 stellige EAN-Codes. Dass diese doppeltin meiner lokalen DB existieren halte ich für ausgeschlossen, andernfalls wird der Artikel einfach nicht angelegt.
Die Codes werden von der Gesellschaft GS1 verwaltet, diemachen das schon :-)
Ganz im Gegenteil, du hast teilweise, übertrieben formuliert für jeden Quatsch 5 unterschiedliche EAN-Codes.

@himitsu: Ja ich denke, der ganze Spaß sollte mal langsam in eine SQL-DB rein. Ab und zu fliegt mal eine access violation, ich glaube bei 350 Artikeln kein Wunder, oder?

[Jumpy]

Irgendwie hätte es glaub ich auch Sinn gemacht, eine eigene Datenstruktur zu erfinden, wenn man den schon mit einer Textdatei arbeiten möchte. Aber wie auch immer: Eine SQL-DB ist wahrlich der einzig sinnvolle Weg, vor allem, wenn die Datenmenge noch größer wird und wenn man mal fortgeschrittenere Operationen auf der Datenmenge durchführen will.