Date: prev next · Thread: first prev next last
2025 Archives by date, by thread · List index


Hallo Werner,

die Schreibweise INDEX:INDEX hatte ich schon mal irgendwann gelesen. Ich hatte es aber wohl wieder vergessen. Sehr gut das du daran erinnert hast. Durch diese Schreibweise konnte ich alle meine INDIREKT() Funktionen umschreiben und mein Tool damit viel schneller machen.
Vielen Dank für deinen Beitrag.

Ich habe selbst auch noch eine Vorgehensweise entdeckt, die nicht zum verschieben der Zellbezüge führt.

Wenn die importierten Daten im Bereich A1:A20 sind, kann man als
Matrix schreiben: {=INDEX(A1:B40;0;1)}
oder mit dem Verweis auf eine Zelle: =INDEX(A1:B1;1;1).

Man verweist also eine Spalte mehr als den Importbereich und schließt dann durch Spalte 1 in INDEX diese zusätzliche Spalte wieder aus. Wird der Verweis auf eine zusätzliche Spalte gemacht, werden die Zellbezüge, im Falle das die Anzahl der Zellen sich verändert, trotzdem nicht verändert.

Jetzt haben wir viele Beispiele von workarounds gefunden. Zu meiner Ursprungsfrage zu kommen: Warum ist ein workaround überhaupt notwendig? Aus meiner Sicht sollte Calc einfach nur die vorhandenen Datenzeilen überschreiben also: Weniger Daten: Die Zellen sollten geleert werden, ohne die Struktur zu verändern. Mehr Daten: Die neuen Daten sollten hinzugefügt oder über bestehende Inhalte geschrieben werden, ohne Formelbezüge zu verschieben.

Gibt es hierzu noch Meinungen aus der Community?

Mit freundlichen Grüßen

Jürgen Kirsten



Am 14.04.2025 um 12:00 schrieb Werner Tietz:
Hallo

Wie wärs mit:

=INDEX(Tabelle1.A:C ; 2 ) : INDEX(Tabelle1.A:C ; 2500 )

Am 13.04.25 um 14:36 schrieb Jürgen Kirsten:
Hallo Alois,

Ich bin auf einen ähnlichen Ansatz gekommen. Ich habe VERSCHIEBUNG() verwendet um eine Referenz außerhalb des Bereiches verwenden zu können, der im Verdacht ist durch zusätzliche und wegfallende Zellen verschoben zu werden.
In deinem Beispiel wäre das dann:
{=VERSCHIEBUNG(A2;1;0;32;3)}
Die geschweiften Klammern verraten schon das dies als Matrixformel verwendet werden muss.

Leider ist VERSCHIEBUNG() genauso wie INDIREKT() eine volatile Funktion. (Hilfetext: INDIREKT ist eine volatile Funktion. D. h. dass Calc die von INDIREKT zurückgegebene Referenz aktualisiert, sobald irgendeine Zelle über Daten ▸ Berechnen ▸ Neu berechnen aktualisiert wird, F9 gedrückt wird oder eine Eingabe erfolgt.) Da meine Daten so zwischen 2500 - 3600 Zeilen enthalten, wollte ich mein Tool etwas schneller machen, und daher auf die volatilen Funktionen möglichst verzichten.

Mit workarounds lässt sich das Problem also umgehen. Die Frage ist: Warum ist ein workaround überhaupt notwendig?

Das es ein Fehlverhalten ist nehme ich gerne zurück. Es ist ein Verhalten, das zumindest erklärungsbedürftig ist. In der Hilfe findet man zur Zeit keinen Hinweis wie das Einfügen genau vor sich geht.

Mir erschließt sich der große Vorteil vom aktuellen Verhalten noch nicht. Man könnte aktuell Daten oder Formeln unterhalb des eingefügten Bereichs schreiben und liefe nicht in Gefahr das diese Überschrieben werden. Aber ehrlich wer würde das denn machen? Ich hätte sogar erwartet das die Zellen überschrieben werden, wenn die CSV Daten mehr Platz brauchen.

Mit freundlichen Grüßen

Jürgen Kirsten



Am 12.04.2025 um 21:11 schrieb Alois Klotz:
Hallo,
ich bin nicht überzeugt, dass das ein Fehler ist.
Calc vermisst hier nach Änderungen in der CSV Zellbezüge und reagiert mit dem Fehler #Bezug!

Der Trick ist, dass man auf die Zellen der verknüpften Datei so zugreift, dass der Zellbezug immer gleich bleibt. Das mache ich mit der Funktion INDIREKT, mit der man einen Zellbezug "zusammenbasteln" kann

Hier ist ein Beispiel in diesem Ordner:
https://www.dropbox.com/scl/fo/pmmwo7vmcqfjlabmesv2j/AIvkolIQdhfU_HktpfKmYFM?rlkey=4uezumieq896v9izg71ryecwg&dl=0
Daten.ods: Damit erzeuge ich die CSV-Datei
Daten.csv: Hier sind die Daten, auf die ich zugreife
Daten-Verknüpfung.ods ist die Datei, die auf die CSV-Daten zugreift und hier kann man auch beliebige Berechnungen durchführen.

Wenn die CSV geändert wird, ändert sich nichts an den Werten

Mit freundlichen Grüßen
Alois Klotz

Jürgen Kirsten schrieb am 12.04.2025 um 01:13:
Hallo zusammen,


ich hoffe, ihr könnt mir
       weiterhelfen. Ich bin auf ein Verhalten in Calc gestoßen, das ich
       als fehlerhaft empfinde – bin mir aber nicht sicher, ob es so
       gewollt ist. Daher wende ich mich an euch als Experten.


Mir ist das Ganze
       aufgefallen, als ich mir ein kleines Auswertetool gebaut habe, das        regelmäßig CSV-Daten aus meinem Home Assistant verarbeitet. (Die
       Herkunft der CSV-Datei ist aber für das Problem nicht
       entscheidend.)Das Problem tritt auf, wenn sich die Anzahl der Zeilen in der        CSV-Datei im Vergleich zum Zeitpunkt der Verknüpfung ändert – was
       bei mir häufig vorkommt. In der Folge "verschieben" sich
       Formelbezüge, was zu Fehlern führt.
So lässt sich das
       Verhalten leicht reproduzieren:


*
Eine neue Tabelle
           in Calc erstellen, in Spalte A z. B. die Zeilen 1–20 mit Daten
           füllen.


*
Diese Tabelle als
           CSV-Datei abspeichern und schließen.


*
Neue leere Datei
           in Calc öffnen (die spätere „Auswertedatei“).


*
In Zelle A1 gehen
           → MenüTabelle →
             Externe Verknüpfungen...→ die zuvor gespeicherte
           CSV-Datei auswählen.


*
Im
           Textimport-Dialog einfach mit OK bestätigen.


*
Nun stehen die
           CSV-Daten in A1:A20.


*
In B1 die Formel=A1schreiben und
           diese bis B40 herunterziehen.


*
Die Datei normal
           im.ods-Format
           abspeichern.


*
Jetzt die
           CSV-Datei erneut öffnen, z. B. 5 Zeilen löschen, speichern und
           schließen.


*
Die Auswertedatei
           erneut öffnen – je nach Einstellung wird man gefragt, ob die
           Verknüpfung aktualisiert werden soll (ansonsten passiert es
           automatisch).
Ergebnis:


*
Nach dem
           Aktualisieren sehen die Zellen B1:B15 korrekt aus.


*
Die Zellen B16–B20
           zeigen nun#BEZUG!.


*
Die Formel in B21
           zeigt nun aufA16stattA21.


*
In B40 steht=A35statt=A40.


Wenn man die CSV-Datei
       anschließend wieder auf z. B. 25 Zeilen verlängert, verschwinden
       die#BEZUG!-Fehler,
       aber die Bezüge sind erneut verschoben – z. B. zeigt B21 jetzt aufA26.


Auch wenn man die
       Formeln in Spalte B in ein separates Arbeitsblatt auslagert und
       dort auf Spalte A referenziert, tritt der Fehler auf.


Es sieht so aus, als
       ob Calc beim Aktualisieren Zellen „nach oben verschiebt“ (wenn
       Daten entfernt wurden) bzw. „nach unten verschiebt“ (wenn neue
       Daten dazukommen) – ähnlich dem manuellen BefehlZellen löschen → nach oben
         verschieben.
Meine Frage:


Handelt es sich
       hierbei um ein gewolltes Verhalten?


Aus meiner Sicht
       sollte Calc einfach nur die vorhandenen Datenzeilen überschreiben
       – also:


*
Weniger Daten:Die Zellen sollten geleert werden, ohne die Struktur zu
           verändern.


*
Mehr Daten:Die
           neuen Daten sollten hinzugefügt oder über bestehende Inhalte
           geschrieben werden, ohne Formelbezüge zu verschieben.


Ich würde mich freuen,
       wenn jemand dieses Verhalten bestätigen oder mir erklären kann, ob        es Vorteile dieser Vorgehensweise gibt, die ich übersehen habe.Unterstützt jemand eventuell meinen Wunsch, das Verhalten beim        Aktualisieren von extern verknüpften CSV-Dateien anpassbarer oder
       stabiler zu gestalten?


Vielen Dank und viele
       Grüße




Jürgen Kirsten









--
Liste abmelden mit E-Mail an: users+unsubscribe@de.libreoffice.org
Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/users/
Datenschutzerklärung: https://www.documentfoundation.org/privacy

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.