Excel, immer wieder Excel

Was sind denn Deine schlechten Eindrücke? Für mich ist es ein schlichtes, schlankes Office das funktioniert.
Ich habe auch ein Win11 Book mit Office 365, aber MS Office ist nicht meins. Damit werde ich nicht warm. Vor allem die Ribbons treiben mich in den Wahnsinn. *Ich* bin mit Libre Office schneller, habe kein Lizenz Theater…

daher nutzte ich Office 2019 ....... und natürlich auch Excel und das schon seit den Anfängen von Excel....
Für mein Nutzen nach wie vor ein tolles Programm mit tollen Funktionen. Vielleicht weil ich nicht der Hardcorer damit bin...
Aber im Job unter Windows und privat mit dem Mac und bin happy damit....
Ich kaufe mir nie die aktuellste Version ...
 
  • Gefällt mir
Reaktionen: wegus
Was sind denn Deine schlechten Eindrücke? Für mich ist es ein schlichtes, schlankes Office das funktioniert.

Es ist träge, fett, hat eine inkohärente Oberfläche, die sich unvollständig anfühlt, stürzt zu oft ab und hat öfter mal größere Probleme beim Im- und Export von Fremdformaten.

Ich setze daher seit Jahren auf SoftMaker Office - ein schlichtes, schlankes Office das funktioniert. (Nein, sie bezahlen mich nicht dafür.)
Kostet halt ein paar Euro, spart dafür Sodbrennen.
 
  • Gefällt mir
Reaktionen: Klausern, dg2rbf und wegus
Ich setze daher seit Jahren auf SoftMaker Office - ein schlichtes, schlankes Office das funktioniert.
Das ist sehr gut und alles andere als schlicht. Ausserdem hat Softmaker einen guten, regen Support und eine sehr aktive Community.
Zum Testen gibt es eine kostenlose Version, die ggf. vollkommen ausreicht.
 
  • Gefällt mir
Reaktionen: warnochfrei
So bleibt eine Tabelle eben auf Deutsch oder auf Englisch.
Dann verwende benutzerdefinierte Zellformatierungen für Datums- und Zahlenschreibungen.

egal wie die Landeseinstellungen von macOS sind. Und so sollte es auch sein.
Ich halte es für ein Komfortmerkmal, wenn sich der jeweils lokale Anwender gerade nicht um ihm/ihr möglicherweise unbekannte landesspezifische fremde Datums- oder Zahlenschreibungskonventionen kümmern muss, weil er/sie darauf vertrauen kann, dass bei den Standardformaten die jeweils lokale Norm präsentiert wird – bei ihm in DE, wie bei ihr in US – in dergleichen Arbeitsmappe.

Es kann nicht richtig mit CSV-Dateien umgehen
Wie Excel mit CSV- (letztlich also Text-)Daten umgeht, wird m.W. im Daten-Import-Dialog festgelegt.

Folgerichtig ist: Weil es ein Textformat ist, kann Excel einen Dezimalpunkt im Text nicht als Dezimaltrenner erkennen; über Zeicheneigenschaften steht ja im Textdokument nichts drin. Zum Weiterrechnen müssen diese dann hierzulande, Suchen/Ersetzen, wieder durch Kommata ersetzt werden. Vorher müssen dann zuerst etwaige Tausenderkommata durch Nichts ersetzt werden.
 
  • Gefällt mir
Reaktionen: DoroS
Dann verwende benutzerdefinierte Zellformatierungen für Datums- und Zahlenschreibungen.
Oh je, und genau deshalb ist Excel die Hölle. Wieso soll ich diese Arbeit machen, wenn man es mit Spracheinstellungen einfach möglich wäre, dies zu tun. Numbers kann es, Google Sheets kann es.

Ich halte es für ein Komfortmerkmal, wenn sich der jeweils lokale Anwender gerade nicht um ihm/ihr möglicherweise unbekannte landesspezifische fremde Datums- oder Zahlenschreibungskonventionen kümmern muss, weil er/sie darauf vertrauen kann, dass bei den Standardformaten die jeweils lokale Norm präsentiert wird – bei ihm in DE, wie bei ihr in US – in dergleichen Arbeitsmappe.
Im Gegenteil, es führt zu Schwierigkeiten und Unklarheiten. Ein Dokument oder eine Tabelle sollte sich überall gleich verhalten und nicht plötzlich seltsame Dinge tun. Excel kann das nicht gewährleisten.

Wie Excel mit CSV- (letztlich also Text-)Daten umgeht, wird m.W. im Daten-Import-Dialog festgelegt.

Folgerichtig ist: Weil es ein Textformat ist, kann Excel einen Dezimalpunkt im Text nicht als Dezimaltrenner erkennen; über Zeicheneigenschaften steht ja im Textdokument nichts drin. Zum Weiterrechnen müssen diese dann hierzulande, Suchen/Ersetzen, wieder durch Kommata ersetzt werden. Vorher müssen dann zuerst etwaige Tausenderkommata durch Nichts ersetzt werden.
Nichts ist da folgerichtig. Wenn du CSV-Dateien mit Excel öffnest, nimmt es auf macOS noch eine alte Zeichenkodierung aus Mac-OS-Zeiten als Standard an, statt UTF-8. Und man will ja nicht immer importieren, sondern eben auch einfach nur eine solche Datei öffnen. Für Numbers und LibreOffice kein Problem, für Excel ein großes Hindernis.

Das Excel in Unternehmen so weit verbreitet ist, hat jedenfalls nichts mit der technischen Seite zu tun.
 
Ein Dokument oder eine Tabelle sollte sich überall gleich verhalten und nicht plötzlich seltsame Dinge tun.

Eine Tabelle verhält sich in Excel immer gleich: Wenn du an ein Datum "dies ist ein Datum" statt "dies ist eine feste, starre Zeichenkette" dranschreibst, dann zeigt Excel es auch als Datum an. (Dass Excel standardmäßig viel zu viel als Datum missversteht, ist ein Ärgernis, aber planbar.)

Das Excel in Unternehmen so weit verbreitet ist, hat jedenfalls nichts mit der technischen Seite zu tun.

Woran, glaubst du, liegt es?
 
Und man will ja nicht immer importieren, sondern eben auch einfach nur eine solche Datei öffnen.
In einer CSV-Datei kann grundsätzlich Beliebiges drinstehen; jeder Automatismus rennt früher oder später in Unvorhersehbares, das der Ersteller der Textdatei der Zielanwendung bereitet.

Wenn du CSV-Dateien mit Excel öffnest, …
Deshalb: Falsche Vorgehensweise, sowohl unter Windows als auch auf dem Mac.
Nicht Öffnen… sondern Daten > Externe Daten > Textdatei importieren… (Excel2011; neuere Versionen ggf. sinngemäß), um im Importassistenten die Importparameter wählen zu können.
 
  • Gefällt mir
Reaktionen: RD11
Das Excel in Unternehmen so weit verbreitet ist, hat jedenfalls nichts mit der technischen Seite zu tun.
Wenn du das wirklich glaubst weiß man, dass du Excel praktisch gar nicht kennst. Excel ist ein megastarkes, megakomplexes, Tool. Es hat schon seinen Grund warum man u.a. sagt, dass Excel keine Datenbank sei ;)
 
  • Gefällt mir
Reaktionen: Chrissi1967
Eine Tabelle verhält sich in Excel immer gleich: Wenn du an ein Datum "dies ist ein Datum" statt "dies ist eine feste, starre Zeichenkette" dranschreibst, dann zeigt Excel es auch als Datum an. (Dass Excel standardmäßig viel zu viel als Datum missversteht, ist ein Ärgernis, aber planbar.)
Deshalb ja nicht, wenn eine Excel-Tabelle international verteilt wird verhält sie sich eben nicht gleich. Sondern zeigt etwas anderes an. Verlangt andere Eingaben.

Woran, glaubst du, liegt es?
Um Halt and Catch Fire zu zitieren: "Nobody was ever fired for choosing IBM"
 
In einer CSV-Datei kann grundsätzlich Beliebiges drinstehen; jeder Automatismus rennt früher oder später in Unvorhersehbares, das der Ersteller der Textdatei der Zielanwendung bereitet.

Stimmt, deshalb zeigt einem LibreOffice auch ein entsprechendes Dialogfeld und Numbers ist sogar recht gut, dass alles zu erkennen. Nur Excel versagt hier komplett.

Deshalb: Falsche Vorgehensweise, sowohl unter Windows als auch auf dem Mac.
Nicht Öffnen… sondern Daten > Externe Daten > Textdatei importieren… (Excel2011; neuere Versionen ggf. sinngemäß), um im Importassistenten die Importparameter wählen zu können.
lol, ich will eine Datei öffnen, nicht importieren!
 
  • Gefällt mir
Reaktionen: dg2rbf
Wenn du das wirklich glaubst weiß man, dass du Excel praktisch gar nicht kennst. Excel ist ein megastarkes, megakomplexes, Tool. Es hat schon seinen Grund warum man u.a. sagt, dass Excel keine Datenbank sei ;)
Nur ich rede hier von Grundfunktionen also Dinge die ich einfach erwarte, dass sie funktionieren und ich mir keine Sorgen machen muss, dass sie auch funktionieren und hier ist Excel einfach nur extrem nervig und schlecht. Und ich rede ja noch nicht einmal über diese wohl durch Jahrzehnte geerbten Eigenheiten wie z. B. Zelle bearbeiten mit F2.
 
Excel ist ein megastarkes, megakomplexes, Tool. Es hat schon seinen Grund warum man u.a. sagt, dass Excel keine Datenbank sei ;)

Könnte es sein, dass du noch nie eine richtige Datenbank benutzt hast, da du "megastarke, megakomplexe Tools" mit "keine Datenbank" gleichsetzt?

"Nobody was ever fired for choosing IBM"

Das war bis in die frühen 2000er hinein zwar richtig, aber IBM hat in den letzten paar Jahrzehnten einige sehr dumme Entscheidungen getroffen. Anders als Microsoft, scheint mir.
 
  • Gefällt mir
Reaktionen: Batucada und wegus
Eine CSV-Datei ist in erster Linie eine Textdatei, keine Tabelle. ;)
RFC 4180 schreibt in der Einleitung "The comma separated values format (CSV) has been used for exchanging and converting data between various spreadsheet programs for quite some time."

Wenn du danach geht ist ooXML auch nur eine Sammlung von (XML-)Textdateien. Geht ja darum, was in diesen Textdateien drinsteht.

Und wenn Übersicht/QuickLook besser mit CSV umgehen kann als Excel ist es eben schon seltsam.
 
Das war bis in die frühen 2000er hinein zwar richtig, aber IBM hat in den letzten paar Jahrzehnten einige sehr dumme Entscheidungen getroffen. Anders als Microsoft, scheint mir.
Halt and Catch Fire spielte Anfang der 1980er wo dieses Zitat häufiger gefallen ist. Heute sind es halt andere Unternehmen, das Prinzip ist das Gleiche.
 
Nur Excel versagt hier komplett.
Nein, es versagt nicht, es überlässt es den Anwendern, die ja wissen sollten, um was es sich in der zu importierenden Textdatei handelt.

Dass die Anwender die Machart der Textdatei oft genug nicht kennen, und selbst die Verfertiger sie vermutlich oft genug nicht kennen, kann der Anwendung nicht zur Last gelegt werden.

lol, ich will eine Datei öffnen, nicht importieren!
Eine Textdatei (CSV; TXT) wird immer importiert, sie ist schließlich unformatiert:
Eine CSV-Datei ist … keine Tabelle.

Die Tabellenhaftigkeit ist, was du darin hineininterpretierst.
Tabelle ist, was du der Tabellenkalkulationsanwendung sagst, was sie daraus machen soll.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: RD11 und warnochfrei
Könnte es sein, dass du noch nie eine richtige Datenbank benutzt hast, da du "megastarke, megakomplexe Tools" mit "keine Datenbank" gleichsetzt?
Doch, hab ich. Und der Spruch, dass Excel keine Datenbank sei zeigt IMHO wie stark und komplex dieses Tool ist. Man muss natürlich ein wenig darüber nachdenken und mal zwischen den Zeilen lesen.
RFC 4180 schreibt in der Einleitung "The comma separated values format (CSV) has been used for exchanging and converting data between various spreadsheet programs for quite some time."
Das wäre aber recht eng gehalten. Generell hat man CSV "erfunden" um in Textdateien Daten nach einem gewissen System zu speichern. Dass das nur auf Spreadsheet (also Tabellenkalkulations)-Programme begrenzt sein soll wäre mir neu. ;)
Und wenn Übersicht/QuickLook besser mit CSV umgehen kann als Excel ist es eben schon seltsam.
Weil du in Excel ein CSV importieren muss und nicht über den Datei öffnen Dialog die Daten rein holen kannst heißt das doch noch lange nicht, dass Excel schlechter damit umgehen kann.
Die Tabellenhaftigkeit ist, was du darin hineininterpretierst.
Richtig, und deshalb ist eine CSV-Datei keine Tabelle, man kann höchstens eine Tabelle rein interpretieren, in die Daten, die die CSV enthält und meistens stellen die Daten eine CSV-Datei auch eine Tabelle dar aber halt nicht immer und schon gar nicht generell ;)
 
  • Gefällt mir
Reaktionen: Batucada
Einer meiner Professoren, der jedes Seminar mit einer bis zwei Stunden Wissenschaftstheorie begonnen hat, hat es sinngemäß so formuliert:
Etwas wird nur zum Datum in dem Kontext, in dem es gelesen werden soll.

30.432,22.176, oder 30,432;22,176; sind für sich genommen keine Daten.
Was dann? Es sind Zeichenketten. Nicht mehr und nicht weniger. Und nicht mehr, aber auch nicht weniger steht in einer CSV-Datei.
Es ist die Interpretation der Nutzer, die darin für einen bestimmten Zweck Dezimalzahlen oder sonstwas lesen.Ein Tabellenkalkulationsprogramm erfährt daraus nichts über die beabsichtigte Lesung; es kann erstmal nur raten.

Es ist plausibel bis nützlich, dass ein in einem auf amerikanisch eingestellten System arbeitenden Tabellenprogramm standardmäßig im ersten Zeichensatz, und in einem auf kontinentaleuropäisch eingestellten System im zweiten zwei Dezimalzahlen liest.

Wird nun aber die erste Zeichenkette unter kontinentaleuropäischen Einstellungen eingelesen, kann der Standard oder der dahinterstehende Austomatismus nicht zweifelsfrei lesen. Es könnten Tausenderzahlen sein, es könnte éine Dezimalzahl sein, durch Punkte von davor und dahinter stehenden irgendwas bedeutenden Ziffernfolgen getrennt.

Wird wiederum die zweite Zeichenkette unter einem auf amerikanisch eingestellten System eingelesen, liest der Automatismus vielleicht nur zwei Tausenderzahlen.

In beiden Fällen braucht das Tabellenprogramm Hilfe durch die Nutzer. Sie wissen, oder sollten wissen, was das sein soll. Und darum gibt es Importassistenten, die die beabsichtigten Bedeutungen der Zeichen und Zeichenfolgen erfragen.

Den Automatismus, der 90% der CSV-Datei von selbst auch unter widrigen Bedingungen erkennt, dann aber an der Zeichenkodierung (ISO-8859-x oder 1231 oder doch UTF-8 oder noch Anderes) scheitert und Sonderzeichen verwurstet, und man das erst später merkt, hätte man dann besser gleich durch den Importassistenten unterstützt.

ED:Typo
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: RD11
Einer meiner Professoren, der jedes Seminar mit einer bis zwei Stunden Wissenschaftstheorie begonnen hat, hat es sinngemäß so formuliert:
Etwas wird nur zum Datum in dem Kontext, in dem es gelesen werden soll.

30.432,22.176, oder 30,432;22,176; sind für sich genommen keine Daten.
Was dann? Es sind Zeichenketten. Nicht mehr und nicht weniger. Und nicht mehr, aber auch nicht weniger steht in einer CSV-Datei.
Es ist die Interpretation des Nutzers, die darin für einen bestimmten Zweck Dezimalzahlen oder sonstwas liest.Ein Tabellenkalkulationsprogramm erfährt daraus nichts über die beabsichtigte Lesung; es kann erstmal nur raten.

Es ist plausibel bis nützlich, dass ein in einem auf amerikanisch eingestellten System arbeitenden Tabellenprogramm standardmäßig im ersten Zeichensatz, und in einem auf kontinentaleuropäisch eingestellten System im zweiten zwei Dezimalzahlen liest.

Wird nun aber die erste Zeichenkette unter kontinentaleuropäischen Einstellungen eingelesen, kann der Standard oder der dahinterstehende Austomatismus nicht zweifelsfrei lesen. Es könnten Tausenderzahlen sein, es könnte éine Dezimalzahl sein, durch Punkte von davor und dahinter stehenden irgendwas bedeutenden Ziffernfolgen getrennt.

Wird wiederum die zweite Zeichenkette unter einem auf amerikanisch eingestellten System eingelesen, liest der Automatismus vielleicht nur zwei Tausenderzahlen.

In beiden Fällen braucht das Tabellenprogramm Hilfe durch die Nutzer. Sie wissen, oder sollten wissen, was das sein soll. Und darum gibt es Importassistenten, die die beabsichtigten Bedeutungen der Zeichen und Zeichenfolgen erfragen.

Den Automatismus, der 90% der CSV-Datei von selbst auch unter widrigen Bedingungen erkennt, dann aber an der Zeichenkodierung (ISO-8859-x oder 1231 oder doch UTF-8 oder noch Anderes) scheitert und Sonderzeichen verwurstet, und man das erst später merkt, hätte man dann besser gleich durch den Importassistenten unterstützt.
Es gibt ja auch Gründe, wieso ich eine Anwendung wie z. B. Easy CSV Editor benutzen, eben weil auf Excel kein Verlass beim Lesen von CSV-Dateien ist, obwohl es sich die Endung .csv gerne einverleibt. Easy CSV Editor ist in manchen Dinge sogar wesentlich einfacher zu handhaben als Excel, gerade wenn es bloß um tabellarische Daten geht.

Und ja, CSV ist ein Plain-Text-Format für tabellarische Daten und Excel kann damit nur sehr umständlich umgehen.

Es geht außerdem nicht um die Interpretation der Daten der Tabelle, sondern, dass es eine Tabelle ist. Und bei guten Programm kann beim öffnen einer solchen Datei sich eben nicht nur auf die Automatik verlassen, sondern auch mit einer Auswahl wie die Zellen getrennt sind, welche Kodierung verwendet wird, welche Zeilenschaltung verwendet wird. Excel bietet dies nur in der Umständlichen Importfunktion. Welche mir halt kein wirkliches bearbeiten der Datei ermöglicht.

Großes Problem auch bei Pages, Numbers, Keynote, können ooXML-Dateien öffnen aber nicht direkt speichern, bloß "exportieren". Funktioniert natürlich ist aber eben umständlicher.
 
Zurück
Oben Unten