xlsxNative - XLSX/XLSM-Dateien ohne Excel einlesen und erzeugen

  • Jetzt klappt es auch mit der Datei.
    Lass aber die Finger vom 4. Worksheet oder bearbeite es vorher - das funktioniert zwar, dauert aber ewig.
    Grund: Alleine dieses Worksheet ist 82 mb groß obwohl im Grunde gar nichts drin steht.

    Ab der 25. Zeile kommt inhaltlich nichts mehr aber die Zellen sind trotzdem in der Datei definiert.
    Wenn man alle Zeilen ab der 26. ordentlich löscht dann ist die ganze Datei auf einmal nur noch 700kb groß.
    Ähnlich ist es beim 2. Sheet mit den vielen überflüssigen Nullen.

    Ein klassisches "Excel-Nutzer"-Problem, wenn Sachen ohne Sinn und Verstand hin und her kopiert wurden...

  • Hallo


    Nachdem ein "lieber" Kollege das Arbeitsblatt um Spalten AQ-BK erweitert hat (!) und dadurch die Verarbeitungszeit exponentiell angestiegen ist, hätte ich den Vorschlag (ob dieser sinnvoll umzusetzen ist kann ich, bei der für mich doch etwas höheren Komplexität der UDF, nicht sagen) die Funktion um eine Spaltengrenze zu erweitern. So in der Art:

    _xlsx_2Array(Const $sFile, Const $sSheetNr = 1, $dRowFrom = 1, $dRowTo = Default, $dColFrom = 1, $dColTo = Default)


    Grüsse

    LG

  • Ja klar könnte ich das mit implementieren.
    Wird aber ne zeitlang dauern.
    Komme wahrscheinlich erst im September wieder dazu.


    Prinzipiell sind mehr Spalten nicht unbedingt ein Problem.
    Es kommt auf das interne Format an. Es gibt die Möglichkeit jede Zeile einzeln mit ihrer Koordinate einzutragen.
    Das ist gut bei dünn besetzten Tabellen - also vielen Lücken zwischen den Zellen.

    Oder die Zellen werden zeilenweise eingetragen egal ob da was drin steht oder nicht.


    Ansonsten schick mir mal die Datei - anhand solcher Beispiele findet man oftmals noch Optimierungsmöglichkeiten.

  • Also: Das Problem ist nicht die Anzahl der Spalten (hätte mich auch gewundert).


    Das Problem ist stattdessen die Anzahl der Zeilen.

    Inhaltlich sind nur 344 Zeilen beschrieben.
    Definiert (z.B. durch Zuweisung einer Formatierung oder ähnlichem) sind hingegen satte 1.046.932 Zeilen.

    Und die stehen alle Zeile für Zeile, Zelle für Zelle in der Datei drin.

    Das hat zur Folge, dass die xml für das Worksheet 108 MB groß ist.
    Und hier streikt dann direkt der XML-Parser.

    Daher bringt es gar nichts wenn ich noch eine Beschränkung für die Zeilen mit aufnehme.


    Die Lösung ist aber entsprechend einfach: Alle Zeilen ab der 345. löschen (entsprechende Datei hier im Anhang).
    Und dem Kollegen auf die Finger klopfen der offensichtlich eiskalt bis zum Ende runtergescrollt hat und aus lauter Blödheit einfach mal sinnfrei Zellen formatiert hat.

  • und aus lauter Blödheit einfach mal sinnfrei

    Aus eigener bitterer Erfahrung weiß ich, dass das weder mit Blödheit und Sinnfreiheit des NUTZERS zu tun hat sondern mit selbiger Seitens der ENTWICKLER.

    Wenn man als Entwickler WEISS, dass etliche Zeilen/Spalten und im obigen Fall mehrere (hundert) Millionen Zellen markiert wurden um daraufhin ohne Warnung an den User eine Aktion zuzulassen, welche die Datei (fast) unbrauchbar macht, dann ist das einfach ein Softwarefehler!

    Und ja, auch ich habe Mitarbeiter, die einfach Warnungen und Fehlermeldungen (ungelesen) wegklicken. In meinen eigenen Programmen schicke ich mir dann Emails mit dem Inhalt, wer wann wo wie was gemacht hat, und kann die dann dem Mitarbeiter/User unter die Nase halten.

    Wenigstens schafft es diese Software beim Schließen auf die "...große Menge an Daten in der Zwischenablage...blablub..." hinzuweisen..... :Face:


    Aber wie lautete schon vor etlichen Jahren nach einem Fingerzeig auf einen offensichtlichen Bug an Microsoft die Antwort eines Entwicklers (damals aus München am Telefon):"Aber Herr G***, selbstverständlich nehmen wir diesen Fehler und ihren Hinweis ernst, aber wir verdienen Milliarden mit diesem Produkt, wieso sollen wir daran großartig was ändern?!"

    Und soll ich euch dazu das passende sagen: RECHT HAT(te) ER!!!!! :ironie: