Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 870DA200D48 for ; Wed, 29 Nov 2017 08:36:18 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 85991160C04; Wed, 29 Nov 2017 07:36:18 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id A4AB5160BF6 for ; Wed, 29 Nov 2017 08:36:17 +0100 (CET) Received: (qmail 47017 invoked by uid 500); 29 Nov 2017 07:36:16 -0000 Mailing-List: contact users-de-help@openoffice.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users-de@openoffice.apache.org Delivered-To: mailing list users-de@openoffice.apache.org Received: (qmail 47005 invoked by uid 99); 29 Nov 2017 07:36:16 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Nov 2017 07:36:16 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 651D41A0E71 for ; Wed, 29 Nov 2017 07:36:15 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=6.31 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id ARmzyHG1KcXr for ; Wed, 29 Nov 2017 07:36:13 +0000 (UTC) Received: from mx009.vodafonemail.xion.oxcs.net (mx009.vodafonemail.xion.oxcs.net [153.92.174.39]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id E22B55F4AD for ; Wed, 29 Nov 2017 07:36:12 +0000 (UTC) Received: from vsmx002.vodafonemail.xion.oxcs.net (unknown [192.168.75.192]) by mta-6-out.mta.xion.oxcs.net (Postfix) with ESMTP id D2D84D9C85C for ; Wed, 29 Nov 2017 07:36:11 +0000 (UTC) Received: from hamster.jawo.myfqdn.de (unknown [83.171.159.30]) by mta-6-out.mta.xion.oxcs.net (Postfix) with ESMTPA id 9D306199C62 for ; Wed, 29 Nov 2017 07:36:09 +0000 (UTC) Received: from hamster [127.0.0.1] by hamster.jawo.myfqdn.de (192.168.178.27) (userid 1) with Hamster-NewsToMail-Gate (Classic Hamster Version 2.1 Build 2.1.0.1537) ; Wed, 29 Nov 2017 08:35:44 +0100 Message-ID: Subject: =?UTF-8?Q?Re:_Frage_zur_maximalen_Gr=c3=b6=c3=9fe_von_odf-Dateien?= X-Newsgroups: hamster.mailinglist.openoffice References: <001501d36875$29b0a0a0$7d11e1e0$@de> <35E38B5C772943B4BE1A13E5FADE9CBF@Esprimo7935> <59E930220BFD4587B55F711071C6A0D9@Esprimo7935> From: =?UTF-8?Q?Wolfgang_J=c3=a4th?= Date: Wed, 29 Nov 2017 08:35:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <59E930220BFD4587B55F711071C6A0D9@Esprimo7935> Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit To: users-de@openoffice.apache.org X-Gate: Hamster/2.1.0.1537 NewsToMail-Gate X-Antivirus: Avast (VPS 171128-2, 28.11.2017), Outbound message X-Antivirus-Status: Clean X-VADE-STATUS: LEGIT archived-at: Wed, 29 Nov 2017 07:36:18 -0000 Am 28.11.2017 um 23:16 schrieb Jörg Schmidt: >> From: Jörg Schmidt [mailto:joesch@j-m-schmidt.de] >> Sent: Tuesday, November 28, 2017 10:41 PM > >> > U. U. kannst du deine Zugriffe optimieren. dazu musst du >> wissen, dass >> > für *jeden* Zugriff die betreffende Datei geöffnet, der Wert >> > ausgelesen, >> > und die Datei wieder geschlossen wird. >> >> Nein, das geschieht bei file-Verknüpfungen ja gerade nicht. >> (es geschieht hingegen bei DDE-Verknüpfungen) > > Sorry, vielleicht ist das so, ohne Erklärung nicht zu verstehen. Der Hintergrund ist das bei file-Verknüpfungen Kopien der verknüpften Tabellen in der Datei in der verknüpft wird angelegt werden und nur diese Tabellen dann immer komplett hinsichtlich der Ursprungsdatei aktualisiert werden und nicht jede einzelne Verknüpfung die auf diese Tabellen angelegt ist. > > Man kann das auch selbst überprüfen: > > -lege eine neue Datei an und schreibe in A1 und A2 der Tabelle 1 zwei verschiedene Inhaltem, z.B. die Zahlen 1 und 2 > -speichere die Datei als Datei mit Namen quelle.ods > -lege eine zweite Datei an und lege dort in Tabelle 1 Zelle A1 eine file-Verknüpfung zu Tabelle1.A1 in der Datei quelle.ods an > -speichere die zweite Datei unter Namen ziel.ods > > -schliesse nun beide Dateien > > -öffne jetzt die Datei ziel.ods nochmals und bejahe das Aktualisieren von Verknüpfungen > -lösche nun die Datei quelle.ods > -jetzt lege, in der weiterhin geöffneten, Datei ziel.ods in Tabelle1.A2 eine file-Verknüpfung zu Tabelle1.A2 in Datei quelle.ods an _indem Du die nötige Formel *manuell* in die Zelle schreibst_ > > Obwohl quelle.ods ja gelöscht wurde, siehst Du nun trotzdem in Zelle A2 der Datei ziel.ods den richtigen Wert, weil dieser im Hintergrund längst in der Datei ziel.ods vorhanden war. > > Es muss also *bei file-Verknüpfungen* nicht bei jedem einzelnen Verknüpfungswert die zugehörige Quelldatei neu gelesen werden. Hmm; da scheint tatsächlich irgend was zwischengepuffert zu werden. Ob das allerdings auch beim primären Öffnen und Aktualisieren einer Datei so der Fall ist, kann ich allerdings nicht sagen (ist jedoch zu vermuten). früher war das jedenfalls definitiv so wie von mir beschreiben. Dennoch scheint mir das nicht ganz koscher zu sein, und definitiv ist die Datei offen. Versuch mal folgendes Szenario: - Datei 'Quelle.ods' und 'Ziel.ods' (für jeden Versuch!) neu anlegen. - Quelle öffnen, 3 Werte eingeben und Datei speichern (nicht schließen) - Ziel öffnen, auf /einen/ Wert in Quelle verweisen, und beide Dateien schließen. - Ziel öffnen, und Aktualisieren bestätigen - Quelle umbenennen - In Ziel auf weitere Quell-Zelle verweisen (funktioniert) - In Ziel *Summe* bilden über einen Bereich in der Quelle Bei letztem Schritt erhielt ich bei vier Versuchen einmal '#REF', einmal den korrekten Wert (Zufall?), und zweimal völlig aus der Luft gegriffene Werte (z. B. einmal '1315,74' statt den eigentlich korrekten '14'). Übrigens hatte ich meine drei Werte jedes mal in A1:A3 geschrieben (und der Einfachheit halber auch immer die drei gleichen Werte benutzt), und das korrekte Ergebnis kam bei der Summe über A1:A2, das #REF bei A1:A3, und die beiden fehlerhaften einmal bei A1:A5 also inklusive 2 leeren Zellen), und einmal sogar ebenfalls bei A1:A3; obwohl ich in diesem Fall sogar *gleichzeitig* in einer anderen Zelle auf A3 direkt problemlos verweisen konnte. Das Fehlerbild ist zwar eindeutig reproduzierbar, das Ergebnis selbst scheint jedoch völlig unvorhersehbar zu sein. Daher glaube ich da eher an einen Zugriff auf eigentlich schon freigegebenen Speicherplatz aka Bug als an eine reguläre im Speicher gehaltene Speicherkopie der echten Datei. Dennoch scheint dadurch die Aussage, jeder Zugriff auf eine externe Datei würde separat erfolgen, wiederlegt zu sein. Nachtrag: Je länger ich darüber nachdenke, desto besser kann ich mir auch ein Szenario vorstellen, welches auch die vom OP berichteten Probleme erklären könnte: Irgend wann im Lauf der Zeit wurde das Zugriffsverfahren geändert von Einzelzugriffen auf eine gepufferte Datei, aber dabei ein Bug ein gebaut, durch den die Datei im Speicher zu früh (nämlich bevor wirklich alle Zugriffe erfolgten) freigegeben wird. So etwas sollte eigentlich in modernen Betriebssystemen nicht mehr vor kommen dürfen, scheint mir aber abgesehen davon eine mögliche(!) plausible Erklärung zu sein. Wolfgang -- --------------------------------------------------------------------- To unsubscribe, e-mail: users-de-unsubscribe@openoffice.apache.org For additional commands, e-mail: users-de-help@openoffice.apache.org