| |
| |
|
| - Seite 1 - |
|
Bernd
Kaiser | Hallo Frank,
ich habe folgendes Problem: In meinem Datenbestand befinden sich in den Textfeldern (leider) auch Kommas (Kommata???) (z.B. Mausefalle, vergoldet), die ListView als Trennzeichen verwenden möchte. Nun kann man den Anwendern alle möglichen Zeichen (|,#,@) in Textfeldern verbieten, beim Komma ist das eher nicht möglich. Was tun?
Beim SQL-Export werden schon Pipes als Trennzeichen eigesetzt.
Lässt sich das Trennzeichen analog zu Excel oder Access nicht variabel, z.B. als Parameter, gestalten?
Gruß Bernd |
|
| |
| Win98SE, Profan 7.5
--------------------------------------------------
Programmieren ist wie küssen:
Man kann darüber reden, man kann es beschreiben,
aber man weiß erst, was es bedeutet, wenn man es getan hat. | 20.04.2005 ▲ |
|
| |
|
|
| |
| |
| - Seite 1 - |
|
Michael
Wodrich | Ist das CSV-Format nicht sowieso so definiert, daß nur Zahlenfelder für sich stehen aber die Textfelder in Anführungszeichen eingeschlossen werden?
Dann ist ein Komma oder mehrere Kommata (oder Kommas; beides korrekt) im Textfeld doch kein Problem.
Jedes Programm das CSV-konform schreibt, wird bei vorkommendem Trennzeichen im Textfeld diese Daten in Anführungsstriche setzen.
Jedes Programm das CSV-konform liest, wird bei beginnendem Anführungszeichen nach dem abschließendem Anführungszeichen für das Feldende suchen (und damit enthaltene Trennzeichen ignorieren).
Es gibt auch CSV-exportierende Programme, die hier mehrere unterschiedliche Varianten anbieten. Dann wähle immer die Variante, die den Text in Anführungsstriche setzt.
MfG
Michael Wodrich |
|
| |
| Programmieren, das spannendste Detektivspiel der Welt. | 20.04.2005 ▲ |
|
| |
|
|
Bernd
Kaiser | Also, ich habe soweit ich weiss keinen Einfluß auf das Format der CSV-Datei, da diese über SQL aus einer Paradox-Tabelle in Profan erzeugt wird (SQL.DAT). Dort ist das Pipe der Feldtrenner und die Feldinhalte stehen einfach dazwischen. Dann schreibt Profan per SQL wohl keine richtigen CSV-Dateien.
Und wie schon oben gesagt, auf die Anwendung und ihre Art der Datenspeicherung habe ich keinen Einfluss. Bin ich tatsächlich der erste, der dieses Problem mit der SQL.DAT hat? Ungläubig guckt. 
Die SQL.DAT erst mit Profan-Mitteln zu ändern und alle Feldinhalte in zu setzen mag ich auch nicht, das kostet alles nur Zeit. Oder bleibt mir tatsächlich kein anderer Weg?
Gruß Bernd |
|
| |
| Win98SE, Profan 7.5
--------------------------------------------------
Programmieren ist wie küssen:
Man kann darüber reden, man kann es beschreiben,
aber man weiß erst, was es bedeutet, wenn man es getan hat. | 20.04.2005 ▲ |
|
| |
|
|
 | Profan schreibt schon richtige CSVs.
CSV heißt ja nur - das sich auf ein Trennzeichen geeinigt wurde. Hierbei spielt das Trennzeichen selbst keine Rolle.
@Michael: Die Problematik ist auch nicht einfach mit getan - stell Dir einfach vor jemand nutzt im Text - und schon fangen wir wieder von vorne an.
Deshalb sage ich ja - die einzige Möglichkeit CSVs richtig zu Schreiben wäre - das man vor dem Scheiben den CS (Characterseparator) aus dem Text herausfiltert - bzw. ggf. in ein anderes Zeichen konvertiert.
Bei der Anzeige der CSV muß das natürlich wieder rückgängig gemacht werden.
Also doch alles kein Problem - Translate$ ist ja auch nicht langsam.
Salve. |
|
| |
| |
| |
|
|
Michael
Wodrich | Soweit mir bekannt, kann man bei Profan auch mehrere Zeichen als Trennzeichen angeben.
Was hälst Du davon, folgendes anzugeben: ,
(also 3 Zeichen: Anführungszeichen, Komma, Anführungszeichen)
Jetzt fehlt als Nachbearbeitung nur noch das führende Anführungszeichen ganz vorne und das abschließende ganz hinten.
Ich kann es mangels Datenbank nicht testen, versuchs einfach mal...
MfG
Michael Wodrich
PS: Wenn Du das Trennzeichen so nicht definiert bekommst (wegen der Anführungszeichen), dann setze: CHR$(34)+CHR$(44)+CHR$(34) |
|
| |
| Programmieren, das spannendste Detektivspiel der Welt. | 20.04.2005 ▲ |
|
| |
|
|
Frank
Abbing | Hallo,
Michael hat schon recht. Das CSV-Format sieht die Lösung des Problems, indem die Items in Anführungszeichen stehen. Und jedes seriöse Ausgabeprogramm unterstützt dieses Feature. Die Listview.dll kann mit beide Varianten umgehen, in Anführungszeichen oder ohne. Trennzeichen sind standartmässig das Komma oder das Semikolon. Auch mit diesem Zeichen kann die Dll umgehen. Sogar Variable Trennzeichen sind kein Problem.
Die Listview.dll hält sich demzufolge an alle Standarts.
Hast du schon versucht, deine Datei in anderen Tabellenprogrammen zu verwenden? Ich bezweifle, dass das beim Aufbau deiner Datei so funktioniert.
Du wirst also kaum umhinkommen, bei der Generierung deiner Dateien darauf zu achten, das Items in Anführungszeichen gebettet werden. Das Anführungszeichen selber mußt du in den Itemtexten natürlich vermeiden. Benutze statt dem doch das ¨ oder das ». Ich könnte auch eine kleine Funktion dazunehmen, die den Sonderfall innerhalb von Anführungszeichen unter berücksichtigung der Trennzeichen untersucht. |
|
| |
| |
| |
|
|
Bernd
Kaiser | Hallo,
erst mal besten Dank für die vielen Anregungen. Das Problem hat sich fast von selbst gelöst. Durch ein anderes Problem bin ich auf einen Parameter in Profan aufmerksam geworden, mit dem sich die Feldtrenner bei SQL definieren lassen. Somit stehen nun die Felder in eingebunden, getrennt durch Kommas.
Das löst zwar nicht alles, z.B. im Feldinhalt, hilft mir aber erst einmal weiter.
Besten Dank. Gruß Bernd |
|
| |
| Win98SE, Profan 7.5
--------------------------------------------------
Programmieren ist wie küssen:
Man kann darüber reden, man kann es beschreiben,
aber man weiß erst, was es bedeutet, wenn man es getan hat. | 22.04.2005 ▲ |
|
| |
|
|
Frank
Abbing | Nachtrag:
Das hat zwar nichts mit Bernds Problem zu tun, passt aber auch hierhin.
Bislang konnten diverse Zeichenkombinationen das Csv-Format verwirren, besonders beim Einlesen von Quelltexten. Immerhin kann der Text ja auch Anführungszeichen enthalten und diese sind innerhalb einer Csv-Datei eben nicht erlaubt. Ein Beispiel wäre:
x&=Create(Button,%hwnd,Neue Zeile,0,300,62,20)
Deswegen kommen in der nächsten Version der Listview.dll die Funktionen ListviewToRaw() und RawToListview() hinzu. Das darin genutze Format ist dem Csv-Format sehr ähnlich. Nur wird als Spalten-Trennzeichen Chr$(2) benutzt und als Zeilenende-Erkennung Chr$(3) verwendet. Damit können sämtliche Listviewinhalte sicher archiviert werden, weil Bytes 2 und 3 dort nie vorkommen werden.
 |
|
| |
| |
| |
|
|
RGH | Nur eine kleine Anmerkung: Im deutschen Sprachraum ist der Standard beim CSV-Format, daß die Felder durch ein Semikolon getrennt werden, da das Komma ja als Dezimalzeichen bei Zahlenwerten vorkommt. Zumindest hält es z.B. ein deutsches Excel so. Im englischen Sprachraum ist das Komma Standardtrennzeichen und der Dezimaltrenner ein Punkt. Strings sollten natürlich immer in Anführungszeichen stehen, da sowohl das eine als auch das andere Trennzeichen vorkommen kann.
Gruß
Roland |
|
| |
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 20.10.2006 ▲ |
|
| |
|
| |
| |
| - Seite 2 - |
|
|
Frank
Abbing | Genauso handhabt es ja die Listview.dll. Komma oder Semikolon sind als Trenner erlaubt, Anführungszeichen sind ab- oder zuschaltbar.
Wie mein oberes Beispiel zeigt, ist das Csv-Format jedoch schnell überfordert. |
|
| |
| |
| |
|
|
| | [quote:6e95db2616]Wie mein oberes Beispiel zeigt, ist das Csv-Format jedoch schnell überfordert.[/quote:6e95db2616]Wo wir bei den EscapeSequenzen wären... oder zumindest wie in vielen Sprachen. |
|
| |
| |
| |
|
|
RGH | [quote:a6decc9c14=iF][quote:a6decc9c14]Wie mein oberes Beispiel zeigt, ist das Csv-Format jedoch schnell überfordert.[/quote:a6decc9c14]Wo wir bei den EscapeSequenzen wären... oder zumindest wie in vielen Sprachen.[/quote:a6decc9c14]
heißt in XProfan q. |
|
| |
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 20.10.2006 ▲ |
|
| |
|
|
Frank
Abbing | | Ich fürchte nur, damit werden meine generierten Csv-Dateien inkompatibel zu anderen Programmen werden, die Csv-Dateien einlesen können. Und nur aus diesem Grund hatte ich diese Möglichkeit geschaffen. |
|
| |
| |
| |
|
(913)
Deutsch
English
Français
Español
Italia