Alternatives DAteiformat zu INI,XML, CSV ,etc.
-
Hi Shadow,
also: ein Programm das nur 65535 Zeilen darstellt .... nicht wirklich.
Der Erstposter sollte mal Laut geben um was es eigentlich geht. Dann macht es
Sinn sich ein für einen Kunden handhabbares Format zu machen.
-
Scheppertreiber schrieb:
also: ein Programm das nur 65535 Zeilen darstellt .... nicht wirklich.
Wenn der Kunde die Daten weiterverarbeiten soll und mit komplexen XML Strukturen nicht klarkommt (was oft der Fall ist), sind CSV Dateien für den Import in Excel/Access das sinnvollste. Da kannst du jetzt soviel auf Office und Microsoft schimpfen wie du willst, es ändert nichts an der Realität.
Numbers und Calc können das übrigens auch - werden aber vermutlich fast nirgendwo eingesetzt. Man muss dem Kunden dass geben was ihn etwas bringt. Wenn er mit Excel umgehen kann, gib ihm Excel Dateien - wenn nicht, dann gib ihm etwas anderes -> wichtig dass der Kunde etwas bekommt mit dem er etwas anfangen kann.
-
hustbaer schrieb:
Shade Of Mine schrieb:
hustbaer schrieb:
Mal ne blöde Frage: kann Excel denn mit CSV Dateien umgehen die eine "Header" haben? Wenn nicht scheidet das IMO schonmal aus.
Ja, Excel kann mit CSV Datei umgehen und CSV bedeutet übrigens auch nicht zwanghaft mit , getrennt sondern mit einem x beliebigen Zeichen - auch wenn der Name vom , kommt.
Du scheinst nicht aufzupassen. Ich weiss dass Excel CSV Dateien lesen & schreiben kann. Die Frage ist: kann man Excel irgendwie verklickern dass es z.B. die ersten 5 Zeilen in so einer Datei ignorieren soll, weil dort eine HEADER steht?
Wenn der Kunde Excel nutzt, dann könntest du ihm ein Makro (mit Öffnen und Speichern Funktion) schreiben, welches die CSV-Datei einliest, die Zellen füllt und dabei die Header nicht mit anzeigt. Das ganze packst du dann in eine Vorlage und gibst sie an den Kunden weiter.
-
@Chris++:
Soll sein. Wenn man es so löst ist man allerdings überhauptnichtmehr an Formate gebunden die Excel versteht. Somit wäre dann das Argument "CSV is gut weil Excel das versteht" wieder hinfällig.
-
Shade Of Mine schrieb:
Wenn der Kunde die Daten weiterverarbeiten soll und mit komplexen XML Strukturen nicht klarkommt (was oft der Fall ist), sind CSV Dateien für den Import in Excel/Access das sinnvollste.
die neuen excel/access versionen können problemlos XML einlesen und auch wieder speichern. wenn man die strukturen schön flach hält, wie man es mit CSV eh müsste, unterscheidet sich die darstellung sogar kein stück.
-
Shade Of Mine schrieb:
Wenn der Kunde Excel nicht bedienen kann, dann ist Excel nicht die richtige Zielplattform.
Die Frage ist: was kann der Kunde bedienen? Excel ist bei den meisten Leuten noch halbwegs brauchbar. Ein Texteditor dagegen - na ich weiss nicht. Wie macht jemand der Excel nicht verwenden kann aus einer Textdatei etwas dass er weiter verwenden kann?
http://www.biomedcentral.com/content/pdf/1471-2105-5-80.pdf
Ich glaub das zeigt ziemlich deutlich, dass man sich nicht drauf verlassen kann, dass der Kunde darauf aufpasst, dass nichts als Datum interpretiert wird.Wenn Excel dann versuch irgendein Excel binär Format zu exportieren wo du den Typ jedes Datenfeld abspeichern kannst. Alternativ die Makrogeschichte. Da würde ich dann aber dafür sorgen, dass Excel die Daten nicht anders laden kann, denn sonst lädt noch ein Kunde die Daten über den falschen Weg, läuft in die Datumfalle und behauptet felsenfest die Datei richtig geladen zu haben.
