Office: (Office 2007) CSV-Schnittstelle

Hallo zusammen,

ich muss für unsere Software eine CSV-Schnittstelle programmieren. Es gibt auch eine Schnittstellenbeschreibung dazu. Ich habe aber keinen Dunst wo ich anfangen soll.
Leider ist diese Beschreibung zu groß um hier anzuhängen.

Hat vielleicht einer von euch einen Tipp wo/wie ich mich über das programmieren von CSV-Schnittstellen schlau machen könnte.
Oder könnt ihr mir sonstwie behilflich sein?

:)

 

Hi,

wenn du eine (ggf. Hilfs-)Tabelle hast, die die Struktur der CSV hat, dann brauchst du eigentlich nur exportieren.

Wenn die CSV "montiert" werden muss, wirst du ein bisschen VBA brauchen:

• Die eigentlichen Dateioperationen sind Open, Write und Close. Write ist dabei der eigentliche Schreibbefehl.
• Write braucht natürlich Stoff, der geschrieben werden soll. Den wirst du vermutlich aufbereiten müssen. Das kann z.B. über Recordsets gehen, mit denen du die Daten auslesen und als Textvariable weiterverwenden kannst.

 

anbei mal ein kleines Beispiel, wie ich in einer meiner Anwendungen eine Export-Datei erzeuge:

Code:

 

Die Schnittstellenbeschreibung ist eine 28-seitige PDF. Und ich habe einfach keine Ahnung wo ich da anfangen soll. Da gibt es auch haufenweise sonstige Dateien.

Wenn ihr mir wirklich helfen würdet findet ihr den Download der Beschreibung hier. Unter anbindung betrieblicher Software. Die 2. Datei.

 

sorry...
a) folge ich sicherlich nicht Links die ich nicht kenne.
b) bin ich nicht bereit ein 28-seitiges PDF zu lesen, wenn du es schon nicht verstehst.
c) sind dir hier Vorschläge unterbreitet worden, wie so eine Datei entstehen kann.

Ich kann hier auch von keinem erwarten, sich in das Datenmodell unsereres CMS einzudenken.

 

Siehe CSV - Trallallalla
That´s all. Eine CSV-Datei ist eine Textdatei. Üblicherweise werden Datensätze als Zeile dargestellt, die Feldwerte darin werden durch Semikolon (oder etwas anderes) getrennt. Das Ganze ist dann idealerweise eine Texttabelle, was man feststellt, wenn man z.B. die Datei in Access verknüpft. Eine solche Tabelle kann man einfachst importieren und exportieren, sie ist daher einer der Standards für Datenaustausch.

Export ist simpel: Tabelle oder Abfrage exportieren. Dazu gibt es Standardverfahren (z.B. TransferText).
Import ist genau so simpel, nur umgedreht. Etwas mehr Arbeit ergibt sich, wenn die Texttabelle nicht genau der Zieltabelle entspricht, wenn also zusammengestellte Daten aufbereitet und zerlegt werden müssen, um die Daten in eigene Tabellen überführen zu können.

Etwas Vordenken und Aufbereiten des Problems wäre Dir schon zuzumuten (schon weil es Dein Job ist?). Bis jetzt gibt es noch nicht mal die Präzisierung Import/Export/beides.

Im einfachsten Fall würde ich dafür sorgen, dass Tabellen im Quellsystem und im Zielsystem die gleiche Struktur inkl. der Beziehungen haben. Dann könnte man tabellenweise ex-/importieren und müsste sich nur Gedanken uber die Reihenfolge machen.
28 Seiten Beschreibung deuten aber darauf hin, dass man Einfachheit nicht als Priorität sieht.

 

... genau das ist mein Problem.
Ich habe jetzt mal 2 Seiten aus der PDF genommen und die beigefügt. Vielleicht sagt euch das dann schon mal mehr. Mir sagt das so alles ziemlich wenig...

Auf der Seite 2 Punkt 2.5 ist die Zusammenfassung.

 

Wenn ich diese Seite lese und nach "BMU-XML Format" googele und die Treffer oberflächlich betrachte, habe ich den Eindruck, dass CSV ein alter Hut ist und eben ein neues XML-Format, gefördert durch das BMU (Umweltministerium) in den Vordergrund geschoben wird.

Das "bisherige IKS" ist sichtbar das CSV, was oben schon beschrieben wurde.

 

Schliesse mich in dem Falle ebs an ... siehst so aus als wenn bei denen das CSV Format nur noch aus Kompatibilitätsgründen erhalten bleibt und die an sich eher den Datenaustausch über XML vorziehen.

Würde mich daher - wenn es nur um die Kommunikation mit dieser speziellen Software geht - gleich auf den Import/Export über XML konzentrieren.

Gruß

Rainer

 

Hallo NoName,

ich finde, Eberhard hat Dir dargestellt, wie einfach Import und Export einer *.csv-Datei sind. Jetzt ist es an Dir, mit der Umsetzung zu beginnen. Du kannst Dazu sicher Hilfestellung hier im Forum erhalten - die Motivation, Dich mit den Details zu beschäftigen, musst Du aber schon selber aufbringen.

Vielleicht fängst Du mal mit der ersten Information an:
Sollst Du Daten importieren oder exportieren?

CU

 

Hallo,
Auszug aus dem PDF:

Da muss gar nichts programmiert werden, weder zum Export noch zum Import. Das ist eine ganz normale TXT (CSV) Datei, erste Zeile Feldnamen, ab Zeile 2 die Inhalte. Jeweils getrennt durch Semikolon, Texte in Anführungszeichen.

Daher kannst Du das ohne irgendwelche Programmierungen in Access direkt machen, das bedarf keiner Schnittstelle.

 

Hallo Zusammen,

vielen Dank für eure Antworten. Ich habe mich jetzt die letzten 2 Tage mal intensiv mit dem ganzen Thema beschäftigt. Und ich denke ich habe jetzt die komplette vorgehensweise verstanden. Aber ich weiß noch nicht genau wie ich das umsetzen kann. Vielleicht könnt ihr mir damit weiterhelfen...
Ich werde die Punkte wo ich die Hilfe benötige sogut wie möglich beschreiben:

Ich muss zu aller erst eine Datei im "BMU-Format" erstellen.
Beispiel:
Code:

Die Angaben "BGSDokument.Layer. ..." sind die vorgegebenen "Felder" der Software. Dort muss dann jeweils der Inhalt meiner Daten eingefügt werden.

Also so:
"BGSDokument.Layer.Daten.ATBListe.Erzeuger.NameUndAdresse.Name.Name1","Inhalt meines Feldes"

Die Angaben "Control. ..." sollen mit VBA ausgefüllt werden.
Also so:
"Control.PZNewLayerRole","Text aus einem VBA Code"

Die jeweilige Datei soll immer in einem bestimmten Datenpfad abgespeichert werden mit einem fortlaufendem Dateiname.

Also so:
2010100000 (DatumFortlaufendeNummer)

Außerdem muss ich ein Dateiende angeben.
Also so:
2010100000.bs

Vielleicht könnte mir einer von euch Helfen wie ich das mache oder mir einen Tip geben wo ich mir das Wissen aneignen kann.

 

UFF

Naja dann wümsch ich viel Spaß - dabei wäre csv doch so schön gewesen *g*

 

Hi,

dieses Format wirst du mit den in #2 genannten Befehlen zusammenmontieren müssen.

Man könnte vielleicht auch erwägen, die Daten Satz für Satz in eine Zieltabelle des Aufbaus Elementname (Text), Wert (Text) zu schreiben und die dann auf einen Rutsch zu exportieren.

So oder so wirst du für jede Zeile eine Mechanik bauen müssen, die die Daten aus einem Recordset abholt und in die Datei/Tabelle schreibt.

 

Etwas irritiert mich die Aussage: Werden Aufgaben total losgelöst vom Wissensstand vergeben?

Mindestens eine Textdatei zu schreiben und einen gewünschten Dateinamen zu vergeben sollte nicht das Problem sein. Eine fortlaufende Nummer sollte man sich merken (in eine Tabelle schreiben), um damit arbeiten zu können.
Siehe auch Beliebigen Text speichern
(Man könnte auch den Zielinhalt in einem String zusammenbauen und im Stück in eine Datei schreiben.)

Tabellenfelder? Formularfelder?

Du müsstest darüber nachdenken:
- Gibt es (in Varianten) feste Reihenfolgen? Dann könnte man diese in einer Tabelle festhalten und verwenden. Oder muss alles live ausgelesen werden? Dann steigt der Aufwand.
- Was passiert bei leeren und Null-Werten?