SoftMaker.de

Es handelt sich hier um die Standard-Interpretation von CSV-Dateien durch PM OHNE die hervorragende manuelle Korrektur der Feld-Definitionen. Nur dieses Standardverfahren ist jedoch im BM-Befehl pm.Workbooks.Open csvfile etc. verfügbar, daher scheint dies mir wichtig.

Dank des unter Programmierern - ausgerechnet - unglaublichen Unwissens bezüglich des CSV- Prinzips darf man sich über gar Nichts wundern. Berechenbare Zahlen- und Datums-/Zeitwerte werden offensichtlich willkürlich mit verkettbaren String-Werten zusammen entweder von Texterkennungszeichen umrahmt oder auch nicht. Na, wie dem auch sei, PM gibt sich angemessen Mühe die Felder entsprechend dem Inhalt der ersten Datensätze zu interpretieren, was zwar schlichtweg unmöglich ist, aber besser als PM macht es glaube ich Keiner.

Anhand dieses Beispiels möchte ich jedoch auf eine mögliche Inkonsistenz bei PM aufmerksam machen. Es handelt sich um den CSV-download des "Einzelverbindungsnachweises" von T-Mobile. Hier wird ausnahmsweise einmal unterschieden zwischen String und Wert, wenn auch für Endverbraucher in bekannt dämlicher Weise, aber in Wichtigem richtig. PM schaltet hierbei offenbar in einen "Vertrauensmodus" und interpretiert die Felder so, wie Sie gekennzeichnet sind.

WICHTIGER NACHTRAG:
Ich kann beim besten Willen die oben erwähnte Inkonsistenz nicht mehr nachstellen. Ich prüfe Dinge mehrmals ehe ich hier Schreibe, es ist mir unerklärlich und tut mir leid. Die letzte Aussage betreffend "Vertrauensmodus" hat sich infolgedessen nach Prüfung als falsch herausgestellt.

Dennoch sollte von Panosis Beitrag an weiter gelesen werden, denn es gibt im Zusammenhang stehende grundsätzliche Probleme mit dem CSV-Import.

1. Jeder Text wird zwischen Texterkennungszeichen angegeben und so auch von PM interpretiert.
2. Die Rechnungs-, Klassifikations- und die eigene Rufnummer - ausschließlich Zahlen - werden (dämlicherweise) als Zahlenwerte angegeben und so auch von PM interpretiert.
3. Die Mobilfunk-Kartennummer wird (richtigerweise) zwischen Texterkennungszeichen angegeben und so auch von PM interpretiert.
4. Die wichtige Zielrufnummer jedoch, exakt wie die Mobilfunk-Kartennummer ausschließlich aus Zahlen zwischen Texterkennungszeichen bestehend, interpretiert PM seltsamerweise als Zahlenwert, wodurch anfängliche Nullen unter den Tisch fallen und u. U. zwei Nullen als Nachkommastellen auftreten.

Ich kann mir das nicht erklären, daher meine Bitte um Aufklärung.
Eine Beispiel CSV-Datei ist angehängt (anonymisiert). Die Diskrepanz tritt auf zwischen PM-Spalten C und R. Feldtrennzeichen ist ; und Texterkennungszeichen " .

_________________
SMO rev. 670 + Win XP                    Times without money are better than times without Mini - the original

Ehem, ja, wenn ich manuell Überschriftzeilen auf 1 und Texterkennungszeichen auf " setze, dann sind alle " weg, aber die Zellen sind alle einheitlich als "Standard" formatiert, auch fehlen in allen Spalten, in denen in der Datei " stand, die '.
Wenn ich hingegen kein Texterkennungszeichen einstelle, werden alle Spalten mit " übernommen, dann sind in der importierten Datei zwar alle " noch da, aber wenigstens sind die Zahlen mit führenden Nullen intakt.

Kann es sein, dass in der Importfunktion noch ein Würmchen steckt? Dass vielleicht die gewählten Einstellungen keinen oder nicht den richtigen Effekt zeitigen?

Erst habe ich Panosis nicht ganz verstanden weil er andere Ergebnisse erzielte als ich. Jetzt weiß ich warum, siehe Nachtrag im ersten Beitrag, und bin sehr dankbar für seine stringente Denkweise und seinen Anspruch. PM braucht solches noch in Vielem!

Der Datei-Öffnen CSV-Import von PM bietet bekanntlich feldweise manuelles Zuordnen zu Textformat (zum Glück mit vorangestelltem Apostroph) oder einem Zahlenformat. Daher erlaubt sich PM mit dem "Standardformat" (ohne manuelle Zuordnung) eine grobe Pauschalierung OHNE (A) Interpretation der Feldinhalte und (B) Berücksichtigung individuell vorgegebener Texterkennungszeichen. Die Anzahl der Kopfzeilen ist in diesem Fall völlig unmaßgeblich, und der ganze Import sowieso nur mit unangemessener Nacharbeit zu gebrauchen.

(A) Da eine Interpretation der Feldinhalte des ersten Datensatzes fast 100%ig zu versteckten Fehlern in irgend einem Datensatz X führt, ist sie eher unverantwortlich und sicherlich keine Verbesserung gegenüber einer aufgezwungenen manuellen Feld-Formatierung. Diese Methode ist leider in vielen Anwendungen gebräuchlich.

(B) Die Berücksichtigung vorgegebener Texterkennungszeichen, SOFERN SIE DIFFERENZIERT AUFTRETEN, wäre allerdings eine überaus enorme Erleichterung beim Import einer einigermaßen korrekt erstellten CSV-Datei. Dies wäre keine Verbesserung, sondern eine Respektierung es CSV-Prinzips. Wenn dabei Fehler auftreten sollten, wären deren Ursache in der CSV-Datei bzw. deren Ersteller zu suchen und keinesfalls bei PM! PM böte für diesen Fall sogar die manuelle Formatierung. Respekt!


Der CSV-Import über BM und der Objektstruktur von PM bietet dagegen weder an Kopfzeilen festzulegen noch Feldweise zu formatieren. Es kann offenbar nicht auf den Dialog in PM zugegriffen werden und dessen Funktionen genutzt. Ergebnis ist die o.g. "grobe Pauschalierung" die "unangemessene Nacharbeit" erfordert. Ich werde davon Abstand nehmen, denn zusätzlich muss man beim Übertragen in eine vorhandene Datei auch noch die Schriftart, Größe, Ausrichtung und ... und ... und anpassen (Siehe mein voriges Thema http://www.softmaker.com/diskussion/viewtopic.php?f=174&t=13938). Diese Funktion der Objektstruktur bedarf ohne Zweifel etwas Nacharbeit um nutzbar zu werden.

_________________
SMO rev. 670 + Win XP                    Times without money are better than times without Mini - the original

Allermindestens dürfte man verlangen, dass Spalten, die mit dem Text-Erkennungszeichen versehen sind, als Text (also mit dem vorangestellten ' oder mit der entsprechenden Zellen-Formatierung) behandelt werden, entsprechendes wäre auch bei Daten und Uhrzeiten anzunehmen.
Nicht ganz so sinnvoll ist in der Beispieldatei, dass in einer Spalte Datum und Uhrzeit beieinander stehen, besser wäre es allemal, diese Angaben auf zwei Spalten zu verteilen - aber dafür kann PM nichts, dieses Problem liegt beim Ersteller der Datei.

Nur ein kleiner Trost: Excel 2010 schafft den Import auch nicht besser.

Du hast so recht, Panosis, aber - sorry - bitte nicht mit letzterer "entsprechender Zellen-Formatierung"! Dieses hirnrissige Excel-Top-Verbrechen eines "Zahlenformates" Text hat schon derart viele Katastrophen angerichtet weltweit, dass es von PM sofort in Zahlen mit vorangestellten Apostroph umgewandelt werden sollte. Dieses sogenannte "Zahlenformat" funktioniert nur innerhalb einer Firma in der alle Mitarbeiter denselben IQ haben, alles Auswendig lernen müssen und es daher sehr konsequent gleichermaßen Anwenden. Spätestens bei der Kommunikation zwischen Firmen entstehen schon fast volkswirtschaftliche Schäden bei der Suche nach diesen Mistviechern, die z.B. ganze Bilanzen verfälschen können. Text darf NIEMALS in Rechenoperationen einen Wert > 0 haben, auch wenn der Text eine Zahl ist. NIEMALS! Und man erkennt die Kotzellen (ahem) nur wenn man das Zahlenformat jeder verdammten Zelle untersucht... Nee nee nee, das sollte keine Firma mitmachen die Nachhaltigkeit auf ihre Fahnen schreiben will!

Allerdings wählt PM automatisch das richtige Zahlenformat dafür und erzeugt dabei eine Datum/Uhrzeit Zahl. Mit dem kann man rechnen, sortieren, Datenbankabfragen machen usw.. Kein Problem für PM, und dadurch komme ich auch damit gut zurecht.

_________________
SMO rev. 670 + Win XP                    Times without money are better than times without Mini - the original

Dass PM Datum und Uhrzeit in einer Spalte gut verdaut, ist höchst erfreulich. Meine Kritik richtet sich nur gegen die Erzeuger der Ursprungsdatei: Es mag etwas engstirnig klingen, aber bei Tabellen und Datenbanken sollte grundsätzlich immer nur eine Art Information in einer Zelle stehen. Also: Datum in einer Spalte, Uhrzeit in einer Spalte, ebenso Strasse und Hausnummer in zwei verschiedenen Spalten, PLZ und Ort in zwei verschiedenen Spalten usw.
Natürlich weiss ich, dass das oft gerade nicht gemacht wird, und daher ist es ja gut, dass PM trotzdem damit klar kommt.

Wer sich so lange um Kleinigkeiten gekümmert hat wie ich, wird kleinlich, wenn er es nicht schon vorher war. Das ist mir deutlich bewusst.

Da muss ich Dir uneingeschränkt recht geben. Und kleinlich... tja, wer wirklich professionell arbeitet ist in dem Sinne "kleinlich", oder auch gründlich. Es ist einfach angenehmer als Zeit und Geld zu verlieren durch lästiges Suchen oder korrigieren.

_________________
SMO rev. 670 + Win XP                    Times without money are better than times without Mini - the original