Office - Word, Excel und Co. 9.744 Themen, 41.408 Beiträge

Olaf19 „Ressourcenverbrauch in Excel und OOcalc optimieren“

01.04.2015, 21:44 Optionen

Sind Tabellenkalkulationen generell nicht für solche Datenmassen konstruiert,

So könnte man es ganz gut zusammenfassen.

16 GB Arbeitsspeicher sind ja nun wirklich nicht wenig

Die bringen Dir hier überhaupt nichts, so lange Du nicht die immer noch exotische 64Bit Version von MSO einsetzt. In der win32-Version dürfte bei 2GB Ende sein.

Ich weiß ja nicht was Du da genau machst, aber warum nimmst Du keine Datenbank?

Borlander „So könnte man es ganz gut zusammenfassen. Die bringen Dir hier ...“

01.04.2015, 22:06 Optionen

Ich weiß ja nicht was Du da genau machst, aber warum nimmst Du keine Datenbank?

Gibt es da eine empfehlenswerte kostenlose Alternative, die möglichst nicht so einarbeitungs-intensiv ist und gut mit Formeln umgehen kann? Benötigt wird eigentlich nur eine Rest- bzw. Modulo-Funktion und eine UND-Verknüpfung. Das war's im Grunde schon.

Danke in jedem Fall für deine Hilfe. Mit mangelndem Arbeitsspeicher konnte es eh nichts zu tun haben, denn selbst wenn die Datei -zig MB groß wird, ist das ja immer noch erst ein Bruchteil des verfügbaren RAM. Selbst 4 GB dürften keine Hürde sein.

CU
Olaf

Fetzo1

Olaf19 „Gibt es da eine empfehlenswerte kostenlose Alternative, die ...“

01.04.2015, 22:18 Optionen

Hi,

was genau machst Du mit dieser Riesentabelle? Welchen Zweck erfüllt die? Druckst Du die Abends aus und hängst die an die Bürowand?

Es gibt auch Nachschlagewerke, wo für jedes Bruttogehalt die dazugehörige Lohnsteuer ausgewiesen wird ... genausogut kann man das aber auch per Formel ausrechnen. Deshalb die Frage nach der Notwendigkeit bzw. Sinhaftigkeit ...

PS. Ich würde in der Office-Familie bei MS Access bleiben - aber ich bin nur routinierter Endanwender und kein Datenbankexperte.

Gruß Fetzo

Fetzo1 „Hi, was genau machst Du mit dieser Riesentabelle? Welchen Zweck ...“

01.04.2015, 22:30 Optionen

Na gut, dann lasse ich einmal die Katze aus dem Sack: Ich bastele gerade an einer Primzahlensammlung ;-) Habe ich vor ca. 10 Jahren das erste Mal versucht, bin schlussendlich aber immer daran gescheitert, dass die Tabellenkalkulation sich aufgehängt hat, wenn es interessant wurde. Hatte anfangs gedacht, das hinge mit der Leistungsfähigkeit von Hard- und Software zusammen.

Das Ganze ist also eine reine Spielerei von mir, dient also hauptsächlich der Befriedigung meiner Neugier. Dafür würde ich mir also nicht Microsoft Access kaufen.

CU
Olaf

Olaf19 „Na gut, dann lasse ich einmal die Katze aus dem Sack: Ich bastele ...“

01.04.2015, 22:49 Optionen

Um in größeren Stil Primzahlen zu berechnen wären weder eine Tabellenkalkulation noch eine Datenbank das passende Werkzeug.

Borlander „Um in größeren Stil Primzahlen zu berechnen wären weder eine ...“

01.04.2015, 23:08 Optionen

Damals am Atari hatte ich ein Basic-Programm dafür geschrieben... das hat aber erheblich magerere Ergebnisse geliefert als die heutigen Tabellenkalkulationen. Und natürlich in einem vielfachen der Zeit.

Ja, das Thema hat bei mir – sagen wir – eine gewisse Tradition ;-)

THX
Olaf

https://de.wikibooks.org/wiki/Primzahlen:_Programmbeispiele

Olaf19 „Damals am Atari hatte ich ein Basic-Programm dafür geschrieben... ...“

01.04.2015, 23:35 Optionen

Du könntest natürlich Excel mit VBA bemühen. Zu Codebeispielen siehe z.B.:

Borlander „Du könntest natürlich Excel mit VBA bemühen. Zu Codebeispielen ...“

01.04.2015, 23:54 Optionen

Was es nicht alles gibt... der VBA-Code kommt schon dem recht nahe, was ich mir damals am Atari zurechtgebrutzelt habe. Gar nicht infrage kämen für mich dagegen Verfahren wie Sieb des Erathostenes. Frag mich nicht warum, ich mag den Ansatz irgendwie nicht.

Mir wäre eine Tabelle an und für sich schon am liebsten gewesen. Prinzipiell funktioniert es ja auch, nur sind Excel & Co. manchmal etwas unberechenbar – eben waren die "Ressourcen" noch da, schon aber überschreitet man das Maß des Erlaubten und denkt, verdammt, hättest du eben kurz auf das Diskettensymbol gedrückt...

Ich schaue mir deinen Link zu Wikibooks über Ostern aber noch einmal in Ruhe an.

THX
Olaf

Olaf19 „Was es nicht alles gibt... der VBA-Code kommt schon dem recht ...“

02.04.2015, 00:23 Optionen

Gar nicht infrage kämen für mich dagegen Verfahren wie Sieb des Erathostenes. Frag mich nicht warum, ich mag den Ansatz irgendwie nicht.

Wieso? Am Ende machst Du doch das gleiche:

Du beginnst mit einer Liste von zu prüfenden Zahlen
Du wählst die erste / eine Primzahl als zu prüfenden Teiler und erstellst für diesen eine neue Spalte
Du prüfst nun alle Zahlen aus 1 auf Teilbarkeit des neuen Wertes in 2 (bzw. gesamt betrachtet allen) - das entspricht dem Streichen der Nicht-Prim-Zahlen beim Sieb-Verfahren
Fortsetzung mit Schritt 2

Bei Deiner Umsetzung nimmst Du nun aber wahrscheinlich deutlich mehr Vergleichsoperationen vor.

Grußbor

Borlander „Wieso? Am Ende machst Du doch das gleiche: Du beginnst mit einer ...“

02.04.2015, 00:28 Optionen

War das bei Erathostenes nicht genau das umgekehrte Verfahren, also: man ermittelt die kleinste Primzahl und löscht anschließend all deren ganzzahlige Vielfache aus dem Zahlensystem heraus, so dass ganz am Schluss nur noch die Primzahlen übrigbleiben?

Das funktioniert natürlich nur, wenn man "das Zahlensystem" auf einen endlichen Rahmen begrenzt. Hat man den ausgeschöpft, d.h. kommen später neue, höhere Zahlen dazu, kann man wieder von vorn anfangen mit der Ausschließerei.

Ich glaube, ich muss da noch eine Nacht drüber schlafen...

CU
Olaf

Olaf19 „War das bei Erathostenes nicht genau das umgekehrte Verfahren, ...“

02.04.2015, 10:09 Optionen

Das funktioniert natürlich nur, wenn man "das Zahlensystem" auf einen endlichen Rahmen begrenzt.

Mit Excel bist Du doch sowieso auf einen endlichen Rahmen beschränkt. Bei 15 Stellen ist doch Schluss mit den natürlichen Zahlen.

Wie umgehst Du diese Grenze?

Gruß, mawe2

mawe2 „Mit Excel bist Du doch sowieso auf einen endlichen Rahmen ...“

02.04.2015, 20:31 Optionen

Bei 15 Stellen ist doch Schluss mit den natürlichen Zahlen. Wie umgehst Du diese Grenze?

Gar nicht – weil ich diese Grenze nie erreicht habe und nie erreichen werde ;-) Ich wäre schon froh, wenn ich in die Millionen vorstoßen würde... und selbst da sind die Rechenzeiten schon horrende lang.

CU
Olaf

Olaf19 „Gibt es da eine empfehlenswerte kostenlose Alternative, die ...“

01.04.2015, 22:35 Optionen

Gibt es da eine empfehlenswerte kostenlose Alternative, die möglichst nicht so einarbeitungs-intensiv ist und gut mit Formeln umgehen kann?

Also ein bisschen wirst Du Dich bei der Arbeit mit Datenbanken schon umgewöhnen müssen. Normalerweise wird man in der Datenbank nur die wirklich relevanten Daten zu hinterlegen wird die von denen abhängigen Werte in nur bei Ausgabe zu berechnen.

Mehrere hundert Spalten hört sich auch eher böse nach einer Struktur an die man nicht 1:1 aus einer Tabellenkalkulation in eine Datenbanktabelle übernehmen sollte.

https://support.microsoft.com/de-de/kb/2655178/de

Borlander „Also ein bisschen wirst Du Dich bei der Arbeit mit Datenbanken ...“

01.04.2015, 22:48 Optionen

Mehrere hundert Spalten hört sich auch eher böse nach einer Struktur an die man nicht 1:1 aus einer Tabellenkalkulation in eine Datenbanktabelle übernehmen sollte.

Okay, etwas genauer: in Spalte A stehen die Zahlen, die daraufhin geprüft werden sollen, ob sie Primzahlen sind. In Zeile 1 stehen die "potenziellen Teiler" der Zahlen in Spalte A.

Je größer die Zahlen in Spalte A werden, desto mehr Zahlen benötige ich für die Prüfung – und somit wird Zeile 1 zunehmend breiter.

Ich denke einfach, dass eine Tabellenkalkulation eine Zweckentfremdung derselben bedeutet, und möglicherweise gilt das gleiche auch für ein Datenbankprogramm.

CU
Olaf

gelöscht_265507

Olaf19 „Ressourcenverbrauch in Excel und OOcalc optimieren“

02.04.2015, 03:47 Optionen

Hier schon gelesen?

gelöscht_265507 „Hier schon gelesen? ...“

02.04.2015, 20:34 Optionen

Ehrlich gesagt: nein ;-) Allerdings sagt mir die Supportseite von Microsoft genau das, was ich bereits erwartet bzw. ausprobiert hatte.

Zu dem Tipp: "Wählen Sie weniger Daten aus oder schließen Sie andere Anwendungen" – letzteres habe ich schon ausprobiert, ersteres im Grunde auch, d.h. versucht, bestimmte Operationen, insbesondere das großflächige Kopieren von Formeln mehr in kleinere Häppchen aufzuteilen.

Nein, ich denke, das ist für Excel einfach zu viel.

CU
Olaf

Olaf19 „Ressourcenverbrauch in Excel und OOcalc optimieren“

02.04.2015, 11:34 Optionen

Sind Tabellenkalkulationen generell nicht für solche Datenmassen konstruiert,

Genau das. Deine Angaben zur Zeilen-/Spaltenzahl lassen mich vermuten dass du, wie viele andere, eine aufgabe mit der Tabellenkalkulation erledigst, die eigentlich eine Aufgabe für eine Datenbank (z.B. Access) wäre.

Behelfen kannst du dir, in dem du für die mappe das automatische Neuberechnen abschaltest und manuell neu berechnen lässt, wenn erforderlich (ALT+F9 IIRC)

neanderix „Genau das. Deine Angaben zur Zeilen-/Spaltenzahl lassen mich ...“

02.04.2015, 12:04 Optionen

Sind Tabellenkalkulationen generell nicht für solche Datenmassen konstruiert,

Genau das.

Dann fragt man sich aber, wieso z.B. die Zeilenzahl bei xlsx > 1 Mio beträgt, während es bei xls noch 65536 waren? Wieso hat man die Dimensionen der Datenblätter damals (2007) so großzügig erweitert, wenn man dieses Potenzial dann letztendlich überhaupt nicht nutzen kann?

Ob Olafs Problem wirklich ein echtes Datenbankproblem ist, möchte ich zumindest anzweifeln.

Bei Datenbanken kommt es auf die Beziehungen zwischen den Tabellen an, Inhalte werden über Schlüsselfelder abgebildet und referenzielle Integrität sorgt für eine Stabilität in den logischen Verbindungen.

Was davon ist bei Olafs Problem nötig?

Gruß, mawe2

mawe2 „Dann fragt man sich aber, wieso z.B. die Zeilenzahl bei xlsx 1 ...“

02.04.2015, 12:20 Optionen

Dann fragt man sich aber, wieso z.B. die Zeilenzahl bei xlsx > 1 Mio beträgt, während es bei xls noch 65536 waren? Wieso hat man die Dimensionen der Datenblätter damals (2007) so großzügig erweitert, wenn man dieses Potenzial dann letztendlich überhaupt nicht nutzen kann?

Um die "Jammerer" zufrieden zu stellen, die unbedingt DB-Aufgaben mit einer Tabellenkalkulation "lösen" wollen.

Manche leute sind halt lern- und beratungsresistent und benehmen sich wie Dreijährige ("ich will aber...!" <aufstampf>).

Olafs Problem hier ist kein DB-Problem; ich kannte es aber nicht, als ich mein Post verfasste.

Sein Problem ist am Besten mit einer Individualsoftware lösbar - also hinsetzen & selber programmieren ;)

Ob Mathematiksoftware ihn dabei unterstützen kann weiss ich nicht, halte ich aber für eher fraglich.

Volker

neanderix „Um die Jammerer zufrieden zu stellen, die unbedingt DB-Aufgaben ...“

02.04.2015, 12:45 Optionen

Sein Problem ist am Besten mit einer Individualsoftware lösbar - also hinsetzen & selber programmieren ;)

Was man nätürlich (auch) sowohl in Excel als auch in Access (mit VBA) machen könnte. :-)

Um die "Jammerer" zufrieden zu stellen, die unbedingt DB-Aufgaben mit einer Tabellenkalkulation "lösen" wollen.

Diese Begründung überzeugt mich nicht. Man muss kein Datenformat entwickeln, das grundsätzlich mehr verspricht als es hält. Irgendwelche Chancen, die 1 Mio Zeilen sinnvoll zu nutzen müsste es doch geben, oder?

Gruß, mawe2

mawe2 „Was man nätürlich auch sowohl in Excel als auch in Access mit ...“

02.04.2015, 13:53 Optionen

Kannst du mit VBA machen, sicher. Ob du allerdings damit glücklich wirst, ist eine andere Frage ;)

Ich sehe allenfalls im Bereich statistischer oder nat.-wiss. Auswertungen eine Anwendung für die erhöhte Kapazität. Wobei man hier allerdings eher auf Spezialpakete zurückgreifen würde, auch weil Excel manchmal ungenau/falsch rechnet.

mawe2 „Was man nätürlich auch sowohl in Excel als auch in Access mit ...“

02.04.2015, 14:19 Optionen

Irgendwelche Chancen, die 1 Mio Zeilen sinnvoll zu nutzen müsste es doch geben, oder?

Mit festen Werten funktioniert das ganze wohl auch. Bei Olaf bestehen nun aber sehr umfangreiche Abhängigkeiten zwischen den Zellen.

Man muss kein Datenformat entwickeln, das grundsätzlich mehr verspricht als es hält.

Wo willst Du da die Grenze ziehen? In der Vergangenheit wurden die User wohl gelegentlich mal durch 16Bit Zeilen und 8 Bit Spaltenadressierung begrenzt. In den neuen Formaten wurde das nun auf 20Bit für Zeilen und 14 Bit für Spalten erweitert. Angesichts der doch eher "krummen Werte" könnte man nun durchaus vermuten, dass hier eine künstliche Begrenzung erfolgt ist. Außerdem ist davon auszugehen, dass Du mit der win64-Version von MSO deutlich später an Grenzen stößt als mit der win32-Version.

Irgendwelche Chancen, die 1 Mio Zeilen sinnvoll zu nutzen müsste es doch geben, oder?

Es reicht eigentlich schon wenn Du eine einzige Anwendung hast die nur eine Zeile oder eine Spalte mehr benötigt als im alten Format. Das wird dann häufig auch ein Datenexport eines anderen Systems sein, oder ggf. die Einbindung einer DB als Excel-Datenquelle. Wenn Du auf solchen Daten dann eine Pivot-Tabelle erstellen kannst ist das schon ein deutlicher Mehrwert.

Borlander „Mit festen Werten funktioniert das ganze wohl auch. Bei Olaf ...“

02.04.2015, 17:35 Optionen

Wo willst Du da die Grenze ziehen?

An der Stelle, wo es noch zuverlässig funktioniert.

Außerdem ist davon auszugehen, dass Du mit der win64-Version von MSO deutlich später an Grenzen stößt als mit der win32-Version.

Das wäre jetzt eine interessante Frage. Hat jemand dazu praktische, nachvollziehbare Erfahrungen? Das wäre dann mal das erste brauchbare Argument, das für ein 64-Bit-Office spräche.

Es reicht eigentlich schon wenn Du eine einzige Anwendung hast die nur eine Zeile oder eine Spalte mehr benötigt als im alten Format.

Naja: Wegen 1 weiteren Zeile muss man kein Format mit 1 Mio weiterer Zelen einführen...

Obwohl Excel sicher das Programm ist, mit dem ich in den letzten 30 Jahren am meisten gearbeitet habe, hatte ich nie mit solch gigantischen Datenmengen zu tun, die auf normalen PCs Performanceprobleme verursacht hätten. Wenn ich mal Zeit habe, werde ich mal ein paar Praxisexperimente diesbezüglich machen. Bis dahin interessiert mich das Problem zumindest theoretisch trotzdem.

Gruß, mawe2

mawe2 „An der Stelle, wo es noch zuverlässig funktioniert. Das wäre ...“

02.04.2015, 18:13 Optionen

An der Stelle, wo es noch zuverlässig funktioniert.

Die kannst Du allerdings nicht eindeutig definieren. Zumal sich der Ressourcenbedarf auch nicht alleine an einer Tabelle oder Arbeitsmappe abschätzen lässt, weil diese mit anderen verknüpft sein können. Du wirst auch mit dem alten Format schon Grenzen erreichen können…

Das wäre dann mal das erste brauchbare Argument, das für ein 64-Bit-Office spräche.

Microsoft selbst nennt das letztendlich als eines der wichtigstens Argumente für den Einsatz von Office64: https://technet.microsoft.com/de-de/library/ee681792.aspx

(Für die Mehrheit der Nutzer wird weiterhin die win32-Version empfohlen)

Wegen 1 weiteren Zeile muss man kein Format mit 1 Mio weiterer Zelen einführen...

Wenn man schon gezwungen ist begrenzte Werbebereiche in einem Dateiformat zu erweitern, dann macht das das für gewöhnlich in einem Umfang bei dem man davon ausgehen kann, dass auf absehbare Zeit keine erneuten kompatiblitätsbrechenden Anpassungen erforderlich werden. Und sofort der Ressourcenbedarf nicht dagegen spricht wählt man heute auch eine Größenordnung von der man hinreichend sicher davon ausgehen kann, dass sie bei normaler Nutzung nie erreicht wird. Von absoluten Größenordnungen sollte man sich da sowieso lösen: Die haben die Zeilenadressen nun gerade mal um 4Bit (also Faktor 16) erweitert. Hättest Du an dieser Stelle den Einsatz von maximal 17Bit Adressen empfohlen?

Borlander „Die kannst Du allerdings nicht eindeutig definieren. Zumal sich ...“

04.04.2015, 10:50 Optionen

Microsoft selbst nennt das letztendlich als eines der wichtigstens Argumente für den Einsatz von Office64: https://technet.microsoft.com/de-de/library/ee681792.aspx

Schade, dass es kein OpenOffice mit 64 Bit gibt.

Die Macversion von MS Office wird auch in Zukunft nur mit 32 Bit laufen:
http://www.theregister.co.uk/2015/03/06/whats_new_in_office_2016_for_the_mac

CU
Olaf

Olaf19 „Schade, dass es kein OpenOffice mit 64 Bit gibt. Die Macversion ...“

04.04.2015, 11:46 Optionen

Schade, dass es kein OpenOffice mit 64 Bit gibt.

Unter Linux gibt es das. Aber große Datenmangen mit OO zu verarbeiten macht auch eher wenig Spaß. Calc fängt nach meinem Gefühl schon recht früh an zu ruckeln…

Borlander „Unter Linux gibt es das. Aber große Datenmangen mit OO zu ...“

04.04.2015, 13:43 Optionen

Calc fängt nach meinem Gefühl schon recht früh an zu ruckeln…

Definitiv deutlich früher als MS Office – und zwar nur das unter Windows!
MS Office Mac 2011 ist ähnlich schnell überfordert wie OOcalc.

CU
Olaf

mawe2 „An der Stelle, wo es noch zuverlässig funktioniert. Das wäre ...“

03.04.2015, 21:17 Optionen

Was heisst "gigantich"? Was mir bei meiner Antwort oben entgangen war.

ich habe bisher mit SAP BW gearbeitet, genauer: einem SAP BW Ecel-PlugIn.

Damit habe ich aus unserem SAP R/3 Daten für meinem Bereich geladen und ausgewertet. Leider konnte man im Parameter-Screen von SAP BW (das ist der Eingangs-Screen, den man b ei einer gewählten Abfrage sieht) nicht für alle Fragestellungen hinreichend genau filtern, weshalb man gerne mal eine Datenmenge bekam, die Excel nicht darstellen konnte.

Ich habe mir immer damit beholfen, die Daten dann in zwei Schritten abzurufen und nach Access zu importieren. Dann die Auswertung in Access vorbereitet und z.B. für ein Pivot nach Excel eingebunden.

Das musste ich übrigens auch nach Einführung von MSO 2010 tun, da die SAP BW VBA-Plugins zwar liefen, aber nicht mit den neuen Grenzen arbeiten wollten -- die bestanden auf den alten ...

neanderix „Was heisst gigantich ? Was mir bei meiner Antwort oben entgangen ...“

04.04.2015, 10:32 Optionen

Kann ich alles bestätigen:

Leider konnte man im Parameter-Screen von SAP BW (das ist der Eingangs-Screen, den man b ei einer gewählten Abfrage sieht) nicht für alle Fragestellungen hinreichend genau filtern, weshalb man gerne mal eine Datenmenge bekam, die Excel nicht darstellen konnte.

Ja, erst bekommt man eine nicht unerhebliche Datenmasse, die man in dem Umfang nicht gebraucht hätte, und dann beschwert sich Excel, dass es zu viele Daten sind.

Abhilfe bietet bei einer Jahresauswertung die Aufteilung in Halbjahre oder Quartale, aber das ist natürlich etwas mühsam. Später kann man die Daten dann wieder zusammenfahren.

Ich muss dazu allerdings sagen, dass ich lediglich BW-Anwender bin, kein Entwickler. Sonst würde ich mir eine abgespeckte Query so stricken, dass sie nicht gewünschte Parameter von vornherein gar nicht erst berücksichtigt.

Das musste ich übrigens auch nach Einführung von MSO 2010 tun, da die SAP BW VBA-Plugins zwar liefen, aber nicht mit den neuen Grenzen arbeiten wollten -- die bestanden auf den alten ...

Jepp. Bei 65536 ist Schluss.

CU
Olaf

mawe2 „Was man nätürlich auch sowohl in Excel als auch in Access mit ...“

02.04.2015, 21:39 Optionen

Diese Begründung überzeugt mich nicht. Man muss kein Datenformat entwickeln, das grundsätzlich mehr verspricht als es hält. Irgendwelche Chancen, die 1 Mio Zeilen sinnvoll zu nutzen müsste es doch geben, oder?

Siehe auch hier: http://www.nickles.de/forum/office-word-excel-und-co/2011/excel-co-mit-1-mio-zeilen-wem-nuetzt-das-eigentlich-538778521.html

CU
Olaf

Olaf19 „Siehe auch hier: ...“

04.04.2015, 13:20 Optionen

Der Thread ist vier Jahre alt. Damals dachte ich wirklich, dass wir heute locker mit dieser großen Zeilenzahl in Excel umgehen können. Offensichtlich ist das aber nicht der Fall.

mawe2 „Der Thread ist vier Jahre alt. Damals dachte ich wirklich, dass ...“

04.04.2015, 13:41 Optionen

Der Thread ist vier Jahre alt.

Genau! Deswegen fand ich es mehr oder weniger spannend, dass diese Frage bis heute quasi unbeantwortet geblieben ist.

Wobei der Erklärungsansatz vom neanderix etwas für sich hat: es ist was für Leute, die Excel wider besseres Wissen als Datenbankersatz zweckentfremden wollen...

CU
Olaf

neanderix „Um die Jammerer zufrieden zu stellen, die unbedingt DB-Aufgaben ...“

02.04.2015, 21:33 Optionen

Manche leute sind halt lern- und beratungsresistent und benehmen sich wie Dreijährige ("ich will aber...!" ).

So wie ich zum Beispiel :-D

Die Sache ist, ich will nun auch kein zu großes Fass wegen meines Primzahlen-Ticks aufmachen. Eine Datenbanksoftware kaufen und lange einarbeiten, das wäre etwas mit Kanonen auf Spatzen geschossen.

Hauptsächlich interessierte mich, wie die Fehler zu erklären sind – zu wenig CPU-Power, zu wenig RAM oder einfach Zweckentfremdung einer Software, die für diese Aufgabe nicht geeignet ist.

Sein Problem ist am Besten mit einer Individualsoftware lösbar - also hinsetzen & selber programmieren ;)

So wie damals am Atari... nur wie gesagt, da haben die Berechnungen Tage gedauert, um in die Nähe auch nur 1 Million zu kommen...

CU
Olaf

Olaf19 „So wie ich zum Beispiel :-D Die Sache ist, ich will nun auch kein ...“

02.04.2015, 21:42 Optionen

Eine Datenbanksoftware kaufen und lange einarbeiten, das wäre etwas mit Kanonen auf Spatzen geschossen.

Kaufen musst Du da nicht zwingend was: MySQL/MariaDB bekommst Du kostenlos, incl. aller notwendigen Werkzeuge (speziell die Workbench zum komfortablen Verwalten und Anlegen von Tabellen). Wenn Du Dir den Krampf mit einer Desktop-DB antun willst, dann kannst Du Base aus dem LO/OO Paket nehmen. Der Rest wäre dann SQL ;-)

Borlander „Kaufen musst Du da nicht zwingend was: MySQL/MariaDB bekommst Du ...“

02.04.2015, 22:01 Optionen

Wenn Du Dir den Krampf mit einer Desktop-DB antun willst, dann kannst Du Base aus dem LO/OO Paket nehmen.

Funktioniert das mittlerweile...? Meine letzte Info zu dieser OO-Komponente war, dass die noch ziemlich experimentell und buggy gewesen sein soll.

MariaDB habe ich noch nie gehört. Ist aber sicher ein ziemliches "Arbeitszeit-Massengrab" für jemanden, der mit Datenbanken so gut wie keine Erfahrung hat (außer einer Access-Weiterbildung 2002 mit meinem damaligen Chef zusammen *g*).

CU
Olaf

Olaf19 „Funktioniert das mittlerweile...? Meine letzte Info zu dieser ...“

02.04.2015, 22:05 Optionen

Funktioniert das mittlerweile...? Meine letzte Info zu dieser OO-Komponente war, dass die noch ziemlich experimentell und buggy gewesen sein soll.

Naja. Das ist halt sowas wie Access in noch schlechter :-\

MariaDB habe ich noch nie gehört.

MariaDB ist der Oracle-freie Fork von MySQ und langristig ist es recht wahrscheinlich, dass es MySQL im Bereich der freien Software ersetzen wird.

Olaf19 „So wie ich zum Beispiel :-D Die Sache ist, ich will nun auch kein ...“

03.04.2015, 21:22 Optionen

Ein Fass aufmachen musst du gar nicht.

Warum nimmst du nicht einfach eine frei verfügbare Programmiersprache - Java, diverse BASIC-Dialekte etc. (C/C++ will ich jetzt nicht empfehlen).

Das sollte den PC immernoch weniger belasten als deine Excel-Lösung

neanderix „Ein Fass aufmachen musst du gar nicht. Warum nimmst du nicht ...“

04.04.2015, 10:48 Optionen

Warum nimmst du nicht einfach eine frei verfügbare Programmiersprache - Java, diverse BASIC-Dialekte etc. (C/C++ will ich jetzt nicht empfehlen).

Basic käme am ehesten in Frage – ist zwar 25 Jahre her, dass ich mich damit intensiver beschäftigt habe, aber gelernt ist gelernt. Da erinnere ich noch eine ganze Menge.

Allerdings wäre nur eine "schlanke" Basicversion für mich tragbar. Also eine, wo sich ein Editorfenster öffnet und man ganz einfach "coden" kann. Nicht, dass da -zig Fenster und Toolbars aufpoppen, mit denen man erst einmal eine grafische Benutzeroberfläche stricken soll. Habe ich vor etlichen Jahren einmal bei Visual Basic gesehen und fand es ganz furchtbar.

CU
Olaf

Olaf19 „Basic käme am ehesten in Frage ist zwar 25 Jahre her, dass ich ...“

04.04.2015, 11:54 Optionen

Danach wirst du - könnte ich mir vorstellen - eher vergeblich suchen.

Schlimm ist das aber nicht; halte die Oberfläche doch minimalistisch:

ein Eingabefeld, ein oder mehrere Ausgabefelder und einen Start/Stopp Button.

Ist nicht wirklich schwierig zu coden, im Gegenteil.

Sowas hat den Vorteil dass du es parallel zu anderen Anwendungen laufen lassen und bei Bedarf einfach anhalten kannst. Machst du es geschickt, dann setzt der beim nächsten Start sogar da fort, wo er aufgehört hat.

Schau den Realitäten ins auge - auch die Codiung Tools wandeln sich bzw. haben sich gewandelt und den neuen OS-Umgebungen und Möglichkeiten angepasst.

neanderix „Danach wirst du - könnte ich mir vorstellen - eher vergeblich ...“

04.04.2015, 12:01 Optionen

Also in VBA könnte man auch vollständig auf eine UI verzichten und einfach die Ausgabe in Console, oder doch besser gleich in einem Tabellenblatt erfolgen lassen. Dann könnte auf Basis der vorherigen Berechnungen auch leichter fortsetzen.

Auch heute gibt es ansonsten aber noch ausreichend Beispiele für vergleichsweise schalnke Entwicklungsumgebungen. Die sind dann aber eher schlank wenn man damit noch richtig produktiv arbeiten möchte.

http://www.freebasic.net/

Borlander „Also in VBA könnte man auch vollständig auf eine UI verzichten ...“

04.04.2015, 12:10 Optionen

Stympt, das ginge auch.

meine Intention war jedoch, die Notwendigkeit Excel o.ä. verwenden zu müssen, zu vermeiden - ist letzlich "Ballast", der RAM verbraucht.

@Olaf:

schau mal hier:

neanderix „Stympt, das ginge auch. meine Intention war jedoch, die ...“

04.04.2015, 12:14 Optionen

Den Ballast halte ich allerdings für vernachlässigbar, wenn es lediglich darum geht die gefundenen Primazahlen in einer Tabelle wegzuschreiben und ggf. beim erneuem Starm dazu zu nutzen um weitere Primzahlkandidaten zu prüfen.

Borlander „Den Ballast halte ich allerdings für vernachlässigbar, wenn es ...“

04.04.2015, 12:21 Optionen

Ich in da skeptisch; meiner Erfahrung nach ist Excel recht Ressourcenhungrig, zumindest gefühlt ;)

Andererseits ist die lösung bestechend einfach; bei Programmierung "ausserhalb" fällt mir nur ein:

wegschreiben der gefundenen Primzahlen in ein dynamisches Arry und speichern des Arrays als File, wenn der PC heruntergefahren wird. Beim Neustart dann einlesen des Files sofern vorhanden, dann start - von vorne, wenn das File nicht vorhanden ist oder von der letzten gefundenen Primzahl aus.

neanderix „Ich in da skeptisch meiner Erfahrung nach ist Excel recht ...“

04.04.2015, 14:55 Optionen

Also schneller als Olafs bisheriger Ansatz dürfte das mit Sicherheit sein.

Im vergleich zu anderen Lösungen aber sicherlich langsam.

Ich hatte anlässlich dieses Threads nun mal eine sehr einfache Primzahlberechnung in Java umgesetzt. In weniger als einer halben Stunde incl. 3 sehr einfachen Optimierungen habe ich damit bereits eine Lösung bekommen die die erste Million Primzahlen in 2s berechnet und damit eine Excel-Tabelle zeilweise vollständig füllen könnte ;-) Die ersten 100.000 sind nach 0,1s fertig, die ersten 10 Millionen dauernd rund eine Minute. (Mit weiteren einfachen Optimierungen ließ sich das kurzfristig auch auch nicht mehr signifikant beschleunigen)

Sofern man das nun nciht wirklich im großen Stil machen willen braucht man sich um das Speichern erst mal keine Gedanken zu machen…

neanderix „Stympt, das ginge auch. meine Intention war jedoch, die ...“

04.04.2015, 14:07 Optionen

Hi nochmal,

Freebasic kannte ich schon, ist aber leider nur für DOS, Windows und Linux verfügbar, nicht für den Mac. Also wenn überhaupt, müsste ich mir dafür eine Linux-Partition einrichten...

CU
Olaf

Olaf19 „Hi nochmal, Freebasic kannte ich schon, ist aber leider nur für ...“

05.04.2015, 16:38 Optionen

Sorry, wusste ja nicht, dass du mit dem angebissenen Obst hantierst ;)

Da wäre dann noch Java eine Möglichkeit *duck & wech*

neanderix „Sorry, wusste ja nicht, dass du mit dem angebissenen Obst ...“

05.04.2015, 18:02 Optionen

Da wäre dann noch Java eine Möglichkeit *duck & wech*

Java ist doch eigentlich fast immer und überall eine Möglichkeit ;-)

Hatte oben ja schon mal von meinen kurzen Experimenten geschrieben. Hatte das ganze zwischenzeitlich auch noch mal ein bisschen länger laufen lassen: Die ersten 100 Millionen Primzahlen hat man nach rund einer halben Stunde. Für den Haushaltsgebrauch sollte das fürs erste reichen. Bei mehr als 2 Mrd (ohne weitere Optimierungen - Parallelisierung würde sich da nun langsam schon anbieten - würde ich hier eine Rechenzeit von rund 3 Tagen schätzen) wird man dann allerdings schon an die Grenzen der Java-Arrays (mit int-Idizes) stoßen. Wobei mir gerade bewusst wird, dass an mit der 100 Millionsten Primzahl auch schon in den Bereich eines int-Überlaufs kommen könnte :-o

https://edvtraining.wordpress.com/2011/04/14/automatische-berechnungen-abschalten/

neanderix „Genau das. Deine Angaben zur Zeilen-/Spaltenzahl lassen mich ...“

02.04.2015, 20:41 Optionen

Behelfen kannst du dir, in dem du für die mappe das automatische Neuberechnen abschaltest und manuell neu berechnen lässt, wenn erforderlich (ALT+F9 IIRC)

Das ist ein interessanter Tipp, auf den ich eigentlich selbst hätte kommen können. Danke, neanderix. Es ist natürlich so: irgendwann muss ich die Formeln berechnen lassen, und dann kracht es wahrscheinlich doch wieder.

https://www.accon-rvs.de/de/tutorials-anleitungen/open-office-calc/item/467-oooformelberechnungausschalten.html

Geht in OpenOffice anscheinend ebenfalls, wenn auch die Anleitung sehr nach Anno Tobak ausschaut.

THX
Olaf

Olaf19 „Das ist ein interessanter Tipp, auf den ich eigentlich selbst ...“

03.04.2015, 21:24 Optionen

Ja. Aber so kracht es nicht jedesmal wenn du eine Änderung am Sheet vornimmst.

mumpel1

Olaf19 „Ressourcenverbrauch in Excel und OOcalc optimieren“

02.04.2015, 18:43 Optionen

Hallo!

Welches Dateiformat nutzt Du? Und welche Officeversion? In den aktuellen Officeversionen könnte das XLSB-Format (Excel Binärarbeitsmappe) helfen (muss aber nicht), dieses Dateiformat wurde "speziell" für umfangreiche Berechnungen entwickelt.

Dieses Problem kommt aber auch schon bei kleinen Datenmengen vor. Meist wenn zuviele Formeln auf einmal kopiert werden, oder Formeln zu umfangreich oder zu lang sind. Excel hat ein ungeheures Gedächtnis. Vielleicht hilft es wenn die Datei mal bereinigt wird (z.B. alle leeren Zeilen und Spalten löschen).

Gruß, René

mumpel1 „Hallo! Welches Dateiformat nutzt Du? Und welche Officeversion? In ...“

02.04.2015, 19:04 Optionen

XLSB-Format (Excel Binärarbeitsmappe) […] wurde "speziell" für umfangreiche Berechnungen entwickelt.

Beim Bearbeiten sollte das Dateiformat eigentlich keinen Unterschied machen. (Ausnahme: Kompatiblitätserhalt zu den alten Office-Formaten), die manifestieren sich erst wenn die Arbeitsmappe gespeichert wird. Dann kommt ggf. auch die Rückfrage wenn ein Informationsverlust droh. Oder übersehe ich da was?

Gruß
Borlander

mumpel1

Borlander „Beim Bearbeiten sollte das Dateiformat eigentlich keinen ...“

03.04.2015, 18:49 Optionen

Ich habe da keine Probleme. Ich habe mich schon vor Jahren von den alten Formaten verabschiedet und nutze nurnoch XLSB.

mumpel1 „Ich habe da keine Probleme. Ich habe mich schon vor Jahren von den ...“

03.04.2015, 19:14 Optionen

Welche Argumente sprechen aus Deiner Sicht für den Einsatz von XLSB als Standardformat?

Ich sehe da spontan eher Nachteile:

Bei XLSB kannst Du nicht sicher sein, dass keine Makros drin sind
Der Austausch mit Nicht-MSO-Anwendungen wird tendenziell erschwert oder gar verhindert

Bei Arbeitsmappen mit "haushaltsüblichem" Umfang erwarte ich zudem auch keinen spürbaren Geschwindigkeitsunterschied.

Gruß
Borlander

mumpel1

Borlander „Welche Argumente sprechen aus Deiner Sicht für den Einsatz von ...“

03.04.2015, 21:35 Optionen

Bei XLSB kannst Du nicht sicher sein, dass keine Makros drin sind

Das kannst Du beim Planmaker-Format auch nicht. Bei denen kann ich Dir Makros reinschmuggeln. Und wenn Du die Datei in Excel öffnest würdest Du das vielleicht für eine Fehlmeldung halten und Makros aktivieren, weil Du vielleicht glaubst dass da keine Makros drinsein können (da nicht vorgesehen).

Der Austausch mit Nicht-MSO-Anwendungen wird tendenziell erschwert oder gar verhindert

.Wenn man darauf wert legt dürfte sogar XLSX nicht immer anwendbar sein, da wäre dann XML besser.

Der Vorteil bei XLSB liegt in der Geschwindigkeit und in der Dateigröße.

mumpel1 „Das kannst Du beim Planmaker-Format auch nicht. Bei denen kann ...“

11.04.2015, 14:17 Optionen

Hallo René,

An dieser Stelle ganz herzlichen Dank für den vorzüglichen Tipp:

Der Vorteil bei XLSB liegt in der Geschwindigkeit und in der Dateigröße.

Inzwischen habe ich es selbst ausprobiert – wenn man sich "rechtzeitig" fürs .xlsb-Format entscheidet, kann man die geschilderten Performance-Probleme zumindest vertagen. Wenn man natürlich munter weiter an der Komplexität seiner Datei strickt, macht Excel später wieder die Grätsche. Aber man erreicht deutlich mehr als mit .xlsx.

Damit das hier nicht im allgemeinen "Thread-Gemurmel" untergeht, habe ich deinem Tipp einen eigenen Thread gewidmet: http://www.nickles.de/forum/office-word-excel-und-co/2015/excel-dateien-durch-xlsb-statt-xls-x-format-schlanker-halten-539116474.html

THX!
Olaf