Mit Calc ist es nicht möglich Daten mit mehr als 1024 Spalten einzulesen (csv oder xlsx). Eine Aufteilung auf mehrere Blätter ist leider nicht möglich. Gibt es eine Lösung dafür?
Quoting @o.vil: “Eine Aufteilung auf mehrere Blätter ist leider nicht möglich.”
“Nicht möglich” ist selten. Was ist hier der Grund?
Wenn’s stimmt, ist das der Killer.
Ist leider so. Einerseits, weil die Datensets sowieso schon auf mehrere Sheets aufgeteilt sind (alle so um die 2000+ Spalten), zweitens, weil die Bearbeitung die Daten jeweils auf einem Blatt erfordert (filtern, prüfen, selektieren, sortieren usw.)
Sehr strange pour me. Was alles kann so ein Datensatz enthalten?
Naja, man muss nicht alles wissen (sagt mein Enkel).
Quoting @o.vil: “Gibt es eine Lösung dafür?”
Soweit ich sehe nur mit etwas Programmierung. Alle Programmierssprachen (-systeme), in die ich etwas Einblick habe, erlauben es, Textdateien, worunter auch alle Varianten von csv fallen, zeilenweise zu lesen und aufzubereiten. Man kann dann die Aufteilung auf mehrere Sheets vorbereiten, indem man für je maximal 1024 Spalten gesplittete Csv-Dateien erzeugt, und diese nacheinander einliest. Man kann ein anderes derartiges Programm auch mit einem Script bei geöffnetem Calc-Zieldokument aufrufen, und sich die gelesenen Zeilen in passenden Happen zum Einfügen in die Sheets überreichen lassen. Wenn Effizienz (Schnelligkeit) nicht so wichtig ist, kann man das sogar mit einem reinen LibO-Basic-Script machen.
Falls die einzelnen Dateneinheiten so klein sind, dass eine ganze Csv-Zeile immer höchstens 65535 Zeichen enthält, kann man die Csv-Datei auch ohne Feldtrenner in eine einzige Spalte importieren, und nachträglich splitten…
Diese heterogene Ideensammlung zeigt schon auf den Gedanken, der jetzt kommt:
Auf alle Fälle sollte man überlegen, ob Rechenblätter das geeignete Mittel sind, mit so großen (breiten) Datentabellen umzugehen. Im Regelfall wird das zu verneinen sein. Migration in eine Datenbank könnte sich auch in deinem Fall empfehlen.
Die “exotischste” Lösung: Feature Request an https://bugs.documentfoundation.org, und dann viel Geduld.
Bezüglich xlsx: MS war sich nie einig, wieviele Spalten ein Rechenblatt zulassen sollte, und wieviele Zeichen in eine Zelle passen müssen. Ich mag mich damit auch nicht herumschlagen. Wenn’s um Daten geht, ist Austausch über Csv wohl eh’ besser. Man kommt gar nicht erst in Versuchung die meistens blöden Formate zu übernehmen.
===Edit1 2018-12-28 13:15 CET===
Wenn es um eine Portierung von Excel nach Calc geht, und derzeit noch mit der Excel-Version gearbeitet werden kann, böte sich doch eine Umarbeitung in Excel auf schmalere (nach Spaltenzahl) Rechenblätter an.
===End Edit1===
Danke Lupp für die schnelle Antwort. Leider besteht nicht die Möglichkeit die Tabellen aufzuteilen und mehr als 1024 Datenspalten sind für die Verarbeitung von wissenschaftlichen Daten jetzt auch nicht mehr sooo viel.
Eine Migration zu einer DB geht aus verarbeitungstechnischen Gründen nicht, da hinter den derzeitigen Excel-Files aufwändige VBA Routinen zur Weiterverarbeitung zwischengeschalten sind (was nach Calc zu portieren aber kein Problem wäre) und das erforderliche sonstige Handling der Daten mit einer DB so rund den Faktor 5 bis 8 mehr Zeit erfordern würde.
Im Detail ging es darum von Excel nach Calc zu migrieren, u.a. auch darum, um unter Linux arbeiten zu können.
Habe gerade einen Eintrag in https://bugs.documentfoundation.org/show_bug.cgi?id=50916 gefunden, offensichtlich ist das Thema “mehr Spalten” schon seit 2012 (!!!, xl macht 16000+ Spalten seit 2007) gewünscht. Ob da ein Feature Request Sinn macht?
Sowohl “mehr Spalten”, als auch “mehr Rechenblätter” ist ein altes Thema, und zum zweiten gab es auch schon jemanden, der angekündigt hatte, den Container zu erweitern. Ist wohl nix geworden.
Ich kann zwar Gründe verstehen, DB-Lösungen auch skeptisch zu sehen, und von meinen Erfahrungen als “gezwungener Front-End-Anwender” her mag ich sie auch nicht, aber Spreadsheets leiden halt immer unter starren (fix-coded) Limitierungen. So was gibt es prinzipiell natürlich auch bei DB, aber halt jenseits des Ozeans…
Was den reinen Datenimport mit Splitting auf mehrere Rechenblätter betrifft, bekäme ich das vielleicht mit bescheidenem Zeitaufwand hin. Falls auch Formeln importiert werden müssen… Naja, das wird dir klar sein, wo da die Probleme liegen. Und VBA-Routinen zu “transmutieren” lohnt m.E. in der Regel den Versuch nicht.
À propos: Welche Wissenschaft?
Markt- und Sozialwissenschaften 
Und da gibt es kein besseres Werkzeug als Excel XY?
Muss ich glatt eine Marktrecherche machen
Klar, für die Berechnungen und Analysen selbst verwende ich R und zum Teil Orange. Aber für das Datenhandling davor ist eine Tabelle einfach um ein Vielfaches praktischer.
Sind die Zeilen dann (in Abschnitten) so was wie 1:n Relationen?
Ne, die Zeilen sind cases (Fälle), jeder unique.
Ein recht beliebtes Problem, ist aber eher bei Schülern/Studenten angesagt. Mein Vorschlag ist etwas skuril und erfordert ein wenig Aufwand: alle Daten zunächst in einem Datenblatt zeilenweise einlesen und im Anschluß mit mtrans() in die Spalten des relevanten Datenblatts übertragen.
Kann man machen, muss man aber nicht!
Guten Rutsch an die arbeitenden Mitleser.
Danke für den Tipp, geht aber leider nicht, weil auch dafür zu viele Zeilen 
Sprich die Datenmatrix ist größer als 1024x1024
uih, das war aus dem ersten Postring nicht so deutlich zu entnehmen gewesen.
Was ist aber nicht verstehe, ist, wenn R ein statistisches Analyse- und Berechnungpaket ist, muss es ja irgendwoher die Daten dafür bekommen. Werden die Daten denn nicht auch in R gespeichert? Wenn ja, sollte doch ein Import in R auch möglich sein? (Ich kenne die Sprache R nicht, daher sei dies eine Annahme!)
Ich habe gerade ein Buchbeispiel gefunden, vielleicht schon bekannt?
[Buchbeispiele]
Da gibt es Hinweise zu Matrizen, Arrays und Listen.
(Befehl: read.csv(“filename”,header=TRUE: liegt eine ausreichende Datenbreite hier vor oder ist auch hier bei 1024 das Ende der Übertragung gegeben?))