Traag & vastlopen (blokkering - werkt niet)

[Piefke]

Hallo beste community,

Sinds enkele maanden loopt mijn CALC-programma (rekenblad of spreadsheet) onder OpenOffice regelmatig gewoon vast. Het wordt een onhandelbaar geheel, een vat vol frustraties. Ofwel duurt het ontzettend lang om te wijzigen en te saven, ofwel krijg ik na verloop de boodschap 'reageert niet'. Het is een eigen databestand met gegevens over mijn muntverzameling. Niet eens zo groot, slechts 315 kB groot. Omdat het al zo moeilijk liep, heb ik die gegevens al eens gesplitst in 2 verschillen spreasheets. Ook heb ik inmiddels alle hyperlinken verwijderd, uitgezonderd ééntje, die ik absoluut nodig heb en dat is een externe database op het internet, namelijk Numista en die kan wisselen per soort munt. De overige linken waren trouwens en slechts verwijzingen naar afbeeldingen op de eigen harde schijf. Maar niets hielp. Het wordt enkel maar erger en erger.

Eerst had ik zo'n vermoeden dat updates van Windows 10 er voor iets tussen zaten en de verwerking ervan opzettelijk vertraagde, terwijl OpenOffice programma's wel normaal als standaard staat ingesteld. Maar dit is waarschijnlijk wat kort door de bocht gedacht van mij.

En met het schrijven van dit bericht, ik wou zien welke cellen er effectief worden gebruikt en normaal is dat van A1 tot AS1846. Maar als ik die spreasheet nu oproep en Ctrl+END druk, naar het eindpunt van de gebruikte data, lach niet, springt die ineens naar cel AS 1048121, na wat testen en achteraan wat rijen verwijderd te hebben toch nog altijd tot 1048073. Maar is dat niet de reden van vertraging, dat hij met méér dan 1 miljoenen rijen rekening moet houden bij zijn sortering ?

HOE KOMT DAT & wat kan ik eraan doen om dit eenvoudigweg op te lossen ? Ik heb zo de indruk dat er een programmatiefout in het programma zit. Stel je hebt een speasheet van 2000 lijnen. Om een of andere reden, bv. stroomonderbreking, moet je een herstel uitvoeren. Ik heb de indruk dat hij er dan 4000 lijnen van maakt. Bij een volgende maal bij een herstel, staat zijn pointer op 4000 (en niet op 2000) en maakt er dan 8000 van bij het nieuwe herstel. Bij een volgend herstel is dat dan niet 2000 lijnen, maar 16000 lijnen et cetera. En omdat ik de laatste tijd nogal wat vast liep, vaak herstel van bestanden heb moeten uitvoeren (maar waarschijnlijk om verkeerde redenen), lijkt me het aantal rijen expansief te groeien en ja, dan ben je al snel aan dat miljoen aantal lijnen. Noot: er staat géén data in de cellen. Het is dus puur een kwestie van eindpointers, denk ik.

Ik ben nieuw op dit forum, dat wel, maar werk zelf al veel langer met OpenOffice. Wie kent er hiervoor een oplossing? Ik kijkt uit naar jullie reacties,

Met een vriendelijke groet,
Piefke

[RPG]

Je stelt veel vragen waar ik ook niet direct een antwoord heb. Bij het zoeken naar een oplossing denk ik voorlopig aan iets algemeens:
a) Vernieuw het gebruikers profiel.
b) Sla het document op met een ODF extensie.
c) Als andere programma's ook problemen geven dan denk ik ook aan het controleren van de gehele harde schijf.
d) als je macro's gebruikt dan eens kijken of de problemen in de macro's zijn, kijk of je ze kunt uitschakelen.
e) Zorg dat je een kopie hebt.

Formules
Ik denk dat elk speadsheet wel 2000 regels moet kunnen verwerken mits het verstandig is ingericht. Maar het kan best zo zijn als de formules ongelukkig gekozen zijn het bij het groeien van het aantal regels ook trager gaat reageren tot onhandelbaar wordt.

Verdubbelen van aantal regels
Bij mij crashed het ook wel eens. Ik sta altijd verstelt hoe goed ik kan vertrouwen op het goed opslaan van de gegevens. Ik weet niet of dat een goede strategie is met echte gegevens.

HOE KOMT DAT & wat kan ik eraan doen om dit eenvoudigweg op te lossen ? Ik heb zo de indruk dat er een programmatiefout in het programma zit.

Ik heb toch het idee dat de fout ergens op jouw computer gezocht moet worden en voorlopig niet in Apache Office.

Gebruikers of users profiel
Lees de link voor informatie. Probeer eens het user profiel te vernieuwen. Het is soms een oplossing voor allerlei problemen. Lees wel goed de aanwijzingen delete niet het userprofiel maar geeft het een andere naam nadat je OpenOffice hebt afgesloten incluis de snelstarter die rechts onder op de toolbar staat. En lees de link voor informatie

Romke

[merlijn]

Je spreadsheet is herhaaldelijk gecrasht. Als na het herstel het aantal rijen is verdubbeld, denk ik dat je spreadsheet beschadigd is, (de structuur van het bestand waarmee calc werkt is een rommeltje geworden) en dat calc daarom moeite heeft met het bestand. Ik weet niet hoe ingewikkeld je bestand is, met formules, verwijzingen en macro's, maar misschien kun je proberen een nieuw bestand te maken en de inhoud van het oude, trage bestand te kopiëren naar het nieuwe bestand.

[Piefke]

Beste Romke/RPG,

Bedankt alvast voor je antwoord. Ik weet niet of het aan het gebruikersprofiel ligt. Ik heb je raad opgevolgd en een nieuw profiel aangemaakt of aangepast (User naar UserOLD veranderd), maar ook dat lost niets op. Ook heb ik gekeken naar je diverse opslagmogelijkheden, maar weet dat eenmaal mijn bestand op .ODS staat, dat ik ook Open Office gebruik om het te verder in te vullen en te bewerken. Ik heb zelfs geëxperimenteerd met de extensies van .OTS, .SCX of .STC, je weet maar nooit, maar het probleem blijft bestaan.

Het lijkt me eerder een stack-probleem (een opstapelprobleem van 't geheugen binnen in het programma zelf) dan eerder dat het iets met een gebruiker of een gebruikersprofiel te maken heeft. Ik heb het probleem enkel met het werkblad (calc of spreadsheet) en niet met de tekstverwerker of presentaies of zo. Volgens mij past hij zijn eindpointers niet aan tot waar hij de data moet bewaren en stapelt die maar op, telkens er iets verkeerd loopt.

Ik gebruikt géén macro's, omdat ik er niet mee vertrouwd ben (nog 'steeds' niet). Ook de harde schijf heeft voldoende capaciteit, 85,7 GB gebruikt, 136 GB vrij. Het werkgeheugen kan dus vrij swappen, als 't nodig is en meestal heb ik geen andere programma's draaien als ik met de 'munten' bezig ben. Het intern geheugen is 8GB, waarvan 7,69 vrij.

Als je wilt stuur ik je het bestand eens door en dan kan je zelf beoordelen dat 315 kB niet écht zo'n groot bestand is. Leg me dan even uit hoe ik dat precies moet doen, ik ben nieuw op dit forum als oudere OpenOffce gebruiker. Mocht het toch een programmatorische probleem zijn, laat me dan desnoods weten hoe ik deze mensen moet contacteren. Ik spreek wel 'een mondje' computer Engels maar reikt mijn Engels niet.

Weet je, ik probeer via 'bijlage doorsturen' je het betreffende bestand door te sturen. Je kan dan je eigen kennis er op loslaten en misschien zien wat er precies aan de hand is. Mocht het me niet lukken (kan niet, te groot of wat dan ook), laat me dan gerust weten hoe het wel kan. En troost je, het eet geen brood, dat hoeft niet per sé vanavond, maar ik zoek wél achter een oplossing terdege.

Waarvoor dank

Piefke,

[RPG]

Als een normale gebruiker hebben wij ons geen zorgen te maken over stack en pointers. Onze zorg is een goed gebruik van de geboden mgelijkheden. Een spreadsheet gebruikt de extensie ODS.

De maximale bijlage grootte is 128 KB. Je bestand is te groot. Mogelijk kun je gebruik maken van File sharing and storage made simple
Als je het bestand plaatst bij File sharing and storage made simple dan kan iedereen er naar kijken. Ik ben niet zo'n grootte spreadsheet deskundige.

Romke

[Piefke]

Hoi Romke,

Met alle respect, ik ben ook geen expert in stack and pointers binnen een programmatie, het is evengoed een gevoelsmatig iets of soms Chinees voor mij, toch denk ik die richting uit. Uit vroegere hobby ervaringen had ik ooit eens vernomen, als een programma zichzelf grandioze maten toemeet, dat er ergens een teller van het stack geheugen niet op nul was gesteld en bleef doortellen, mee was opgenomen in de bestandsinformatie. Hoe kan anders een spreadsheet file van 1846 rijen, plots meer dan een miljoen rijen bevatten zonder enige zinnige of zichtbare inhoud in dié cellen ?

Ik heb de file transfer MediaFire geprobeerd en dat staat er op. Hoe krijg ik dat bij jou ? De link van 't bestand is:
http://www.mediafire.com/file/fih709xal ... E+EURO.ods

Heb je er iets aan ? Is dat voldoende of moet ik nog iets doen ? Ik ben niet zo vertrouwd met die externe file tranfers.

Mocht het een toch een programmatiefout van stacks zijn, binnen het programma, weet jij dan bij wie ik terecht kan bij OpenOrg of Open Office om specifiek dit probleem aan te kaarten ? Graag naam en toenaam of site met specifiek item vermelding. Ik spreek ook maar een 'mondje' Engels en zal me wel behelpen.

Raar hé ! Een file met 1864 rijen die plots uitgroeit tot 1.048.121 rijen. Neen, Romke, ik zoek écht naar een oplossing, want het kan niet dat ik enige of de eerste ben. Het is ook trouwens mijn bedoeling om 'anderen' hiermee te helpen.

Ik hoor je wel, tot later
Piefke,

[RPG]

Met het doorgeven van de link kan iedereen het downloaden/ Ik heb het ook al gedownload.

Ik gebruik geen control-END maar control en pijltje naar beneden. Het gaat dan mooi naar het einde van de gegevens.

Er zijn database ranges van de goede afmetingen. Ook zijn er benoemde bereiken. Twee benoemde bereiken hebben de goede maat.
Een bereik is groot. Maar voorzover ik weet maakt het niet als een bereik heel groot is want het niet gebruikte deel wordt ook niet gebruikt in berekeningen.

IHet loopt wel vast wanneer ik beweeg met de cursor. Voorlopig laat ik het hierbij.

Romke

[RPG]

Ik heb er nu wat langer naar gekeken. Ik denk echt dat het een gevolg is van een ontwerp fout.Het lijkt er op dat het programma is begonnen met Excel en dat het later voortgezet is in een versie van OpenOffice.

Of het bovenstaande waar is of niet is misschien ook niet erg belangrijk. Wanneer je van plan bent om OpenOffice blijvend te gebruiken is het belangrijk om ook de ontwerp gedachten van OpenOffice te volgen. Ook is het belangrijk om te beperkingen en de sterke punten van OpenOffice te leren.

Stijlen en opmaak
Ik zou mij gaan verdiepen in het toepassen van stijlen voor de opmaak. Hierbij moet je de directe opmaak verwijderen en voor gewenste stijlen toepassen. Bedenk dat stijlen hiërarchisch zijn.

Database
OpenOffice is veel meer database gericht dan Excel.

Links
Ik weet niet in hoevere de links nog een probleem zijn. Het kan zijn dat het voor mij een probleem was daar de bestanden niet op mijn computer staan.

Dubbele regels
De dubbele regels zijn een gevolg van een instelling
menu --> split venster.

Afbeeldingen
Er zijn vier afbeeldingen te zien in de navigator. Ik denk dat die ook verwijderd moeten worden. Het lukt mij maar 1 te verwijderen

Oplossing
Ik denk niet dat er gelijk een oplossing is voor te schrijven. De oplossing hangt voor een deel af van jouw eigen wensen en wat je wilt met je gegevens. Mijn idee is altijd hou de basis-gegevens zo eenvoudig mogelijk en verfraai het pas voor het eind resultaat. Ik zal zeker nog langer er naar kijken maar deze voorlopige beschrijving zal toch ook helpen. Wanneer je grote veranderingen aanbrengt wel diverse versies bewaren.

Samenvatting
Leer OpenOffice goed te gebruiken. Het is niet het zelfde als Excel.

Romke

[Piefke]

Beste Romke,

Mijn bericht van heden ochtend blijkt de mist in gegaan te zijn. Ik vind het alvast niet meer terug en de tekst is weg.

In 't kort kwam het hier op neer, dat ik het probleem een beetje zelf opgelost heb, door de 'rijen' te kopiëren in een nieuw calc blad. Hierdoor is dat euvel tot cel 1048121 wel opgelost, wat mij betreft, maar niet de fout in het programma uiteraard.

Ik heb ook getest met kolommen te kopiëren en eigenaardig genoeg, als je kolom per kolom kopieert, doet hij het goed. Enkel als je meervoudige kolommen selecteert, loopt het weerom verkeerd en gaat hij terug naar een eindcel 1048121.

Mijn vraag aan u is, hoe contacteer ik het best Open Office zelf om dit euvel met hen te bespreken ? Als ik, als leek, een dergelijk probleem heb, dan zullen allicht ook anderen een soortgelijk probleem kennen. Het is enkel mijn bedoeling om te helpen zodat Open Office dit zou kunnen nakijken en eventueel kan herstellen in een volgende versie of build, tenminste als 't effectief een programmatie bug zou zijn. Door hen dit te melden, help ik dan weerom anderen, hé !

Met dank voor je welwillende medewerking,
Piefke,

[RPG]

In 't kort kwam het hier op neer, dat ik het probleem een beetje zelf opgelost heb, door de 'rijen' te kopiëren in een nieuw calc blad. Hierdoor is dat euvel tot cel 1048121 wel opgelost, wat mij betreft, maar niet de fout in het programma uiteraard.

Dat is een klein probleem en is feitelijk niet belangrijk geweest.

Mijn vraag aan u is, hoe contacteer ik het best Open Office zelf om dit euvel met hen te bespreken ? Als ik, als leek, een dergelijk probleem heb, dan zullen allicht ook anderen een soortgelijk probleem kennen. Het is enkel mijn bedoeling om te helpen zodat Open Office dit zou kunnen nakijken en eventueel kan herstellen in een volgende versie of build, tenminste als 't effectief een programmatie bug zou zijn. Door hen dit te melden, help ik dan weerom anderen, hé !

Het meest voorkomende probleem wat gemeld word en waar dit ook op lijkt is: Mensen hebben van OpenOffice de zelfde verwachting als van Excel en die verwachting is verkeerd. Mijn advies beperk alle opmaak.

Romke

[RPG]

Ik geloof dat ik het nu tot een werkbaar bestand heb terug gebracht.

In het oorspronkelijke bestand heb ik eerst alle opmaak verwijderd die niet tot de standaard behoorde. Ook heb ik de afbeeldingen verwijderd voor zover dit mogelijk was. Het bleek dat het wel beter ging maar nog niet voldoende. Toen heb ik het advies van Merlijn opgevolgd door het bestand naar een nieuw document te kopieren. Dat laatste helpt voldoende zodat het niet meer vast loopt.

Oorzaak
Ik weet niet precies de oorzaak maar het zou kunnen dat er ergens een fout in het bestand gekomen is aangaande de afbeeldingen. Wanneer ik ook maar iets met de afbeeldingen deed dan liep de computer vast.

Na het kopiëren moest ik ergens een link verwijderen. Dit moest via het menu voor links.

Je zou dit ook kunnen proberen met je oorspronkelijk bestand.

Romke

[RPG]

Ik heb nog iets gevonden wat mogelijk een probleem kan zijn. Wanneer ik de rijhoogte van het tabblad munten een gelijke hoogte geef of de standaard hoogte dan lijkt het ook beter te gaan. Ik heb wel de opmaak verwijderd van alle cellen die niet tot de tabel behoren.

Bij sommige acties moest ik de computer wel even rustig laten werken: dus een kwartier laten staan en kijken of de computer weer wilde reageren. Bij andere problemen heb ik de computer soms 2 uur moeten laten werken om het resultaat te zien.

Romke

[Piefke]

Bedankt alvast, Romke

Je opmerking inzake die rijhoogte, die triggert me wel. Soms wil je een lijn tussen voegen, en dan de informatie uit andere kopiëren. Maar als je wat snel bent, durf je wel al eens op de lijnen tussen de cellen belanden. Als je er geen erg in hebt, heeft Calc je rijhoogte al aangepast. Een rijhoogte van 0,47 of 0,48 cm is niet zo meteen op 't oog zichtbaar, maar wel degelijk voor het programma extra mee te sleuren informatie. Ik ga dit nakijken, heb zelf hierin al verschillen bemerkt en ga ze allemaal op 'standaard rijhoogte' zetten. Er is geen enkele reden nodig, dat die rijhoogten zouden verschillen, toch niet in mijn toepassing.

P.S. Ik heb je uitgeklede 'munten02.ods ' bekeken. Dat is prima. Enkel ontbreekt hierin de externe link naar 'Numista', die stond onder die kolom met allemaal 'JA' erin, kolom R van de tabel. Die wil ik wel behouden, gezien ze rechtstreeks naar het betreffende Numista scherm springt, en dit verschilt van soort munt tot soort munt, soms zelfs binnen één op 't oog eenzelfde munt. Maar geen nood. U moet verder niets doen voor die linken, die heb ik nog wel.

Bedankt alvast voor de moeite, ik werk eraan verder en beschik nu over een werkzaam bestand. Ik overweeg zelfs om bepaalde gegevens, die dan toch op Numista terug te vinden zijn (via die link) op een bepaalde wijze in te korten. Ter info: Uiteindelijk had ik het oorspronkelijk probleem (over miljoen lege lijnen) enkel in dit bestand met de Euromunten. Ik gebruik Calc ook voor de overige munten (van de rest van de wereld) en daar zitten nog veel meer lijnen in (van A1 tot AZ4346) en daar zijn geen problemen mee. Dat laatste bestand is zelfs dubbel zo groot (751 kB in ODS en 5733 Kb in XLS). Die XLS-bestanden gebruik ik als veiligheid, een soort back-up zeg maar.

Bedankt,
Paul Herijgers
B-Wilrijk

[RPG]

Al het vorige was om grip te krijgen op het bestand. Maar het lijkt er op dat ik nu eindelijk ook een wat duidelijke methode gevonden heb om het bestand te beheren en tegelijk wel de gewenste opmaak te behouden.

Code: Selecteer alles

Split windows uit schakelen
De regelhoogte instellen op een vaste hoogte 0,7 cm
No borders
Alle opmaak weggehaald buiten de data gebieden in twee stappen.
Het verwijderen van de image. Gebruik maken van de navigator en delete
Tussen door steeds opslaan en ruim de tijd nemen voor elke actie

Ik heb dat alleen maar toegepast op het tabblad munten. Op het laatst kwam ik er achter dat er wel degelijk die image objecten aanwezig waren. Alhoewel er maar een echte afbeelding bestond. Er waren drie lege image objecten. Ik gebruik image vanwege mijn Engels talige LibreOffice.

Ik denk dat boven staande strategie ook op de complete dataverzameling moet werken.

Algemene Opmerkingen
Ik denk dat opslaan met een MSO indeling nooit verstandig is als je wilt werken OpenOffice. Wanneer je het toch moet opslaan in een MSO indeling eerst opslaan in een OpenOffice indeling daarna met een MSO indeling. Bij verder werken door gaan met het bestand wat opgeslagen is in de indeling van OpenOffice. Voor welk programma dan ook geld naar mijn idee altijd opslaan en werken met de indeling die bij het programma hoort.