21. marts 2022 - 15:09Der er
36 kommentarer og 2 løsninger
"Svarer ikke" når jeg fortryder ændring i store ark
Når jeg fortryder en handling i omfattende ark med mange data, formler og mange forskellige betingede formateringer, går Excel (2013) i "svarer ikke" tilstand, og jeg er nødt til at lukke med Ctrl Alt Delete for at komme videre. Jeg har forsøgt at reparere Office, og jeg har prøvet at afinstallere og derefter geninstallere Office, men det hjælper ikke.
Problemet plejer som regel at være relateret til, at data sættet er for stort, og der ikke er hukommelses resurser nok, til at kunne genskabe data. Jeg oplever det selv, af og til, og har "lært" gennem tiden, at man skal gemme pr. automatik, noget oftere, eller udvide sit Ramlager, betragteligt.
Måske har du ikke RAM nok. Excel 2013 (32-bit versionen) kan kun udnytte 2 GB virtuel hukommelse, og det er til applikationen, alle add-inns, og så det/de regneark, der er åbne. Og husk, at en ændring, der skal fortrydes er under alle omstændigheder en tung opgave.
"Because Excel loads the worksheet into addressable memory, some worksheets that have a file size of less than 2 GB may still require Excel to use more than 2 GB of addressable memory."
#4 - Omkring din version er 32 bit, kan du se, ved at vælge "Fil", og "Konto" og så trykke på "Om Excel". Og der vil du også kunne se under "Systemoplysninger" din aktuelle maskines hukommelses tilstand, og hvor meget Excel har i brug til sin såkaldte "sidefil".
32 bit programmer ligger inder programmer(x86) - 64 bit under programmer. Er dit styresystem 32 bit - har du ikke 64bit programmer og så kan jeg ikke huske om biblioteket hedder programmer for 32 bit..
Du kunne eventuelt også prøve at fortælle mere om, hvad præcist det betyder, at:
.... omfattende ark med mange data, formler og mange forskellige betingede formateringer, går Excel (2013)
Hvilke formler og funktioner, hvilke betingede formateringer og hvor mange af dem, bruger du "full column" references som A:A i stedet for for eksempel A1:A100, bruger du matrixformler, linker du til andre projektmapper og så videre?
#9 Før jeg går i gang med en sådan beskrivelse, vil jeg spørge, hvad du mener den vil kunne bruges til?
Jeg bruger ikke "full column" references til betinget formatering, men jeg har lige opdaget, at der er sket nogle opdelinger som fx =$AD$42:$AD$45;$AD$49:$AD$52;$AD$40;$AD$47;$AD$54;$AD$27:$AD$38;$AD$84:$AD$94;$AW$98:$AW$103;$AW$91:$AW$96, og dem er der sikkert flere eller mange af, hvor der retteligt burde stå ét område pr. kolonne. Dem vil jeg under alle omstændigheder i første omgang samle. Som det er nu, er det jo ret rodet. Måske sådan en oprydning kunne gøre en forskel i en eller anden grad.
Jeg skal i 12 kolonner (der ikke står samlet) og 365 kontinuerte rækker have samme betingede formatering. Mon der kan siges noget om, hvorvidt det i relation til mit spørgsmål er bedst at lave en individuel betinget formatering for hver kolonne, altså (her vist for blot tre kolonner) fx for S27:S391, V27:V391 og Y27:Y391, eller én samlet betinget formatering for fx S27:S391;V27:V391;Y27:Y391?
#10 Til måske at give et bare et bare nogenlunde kvalificeret svar på, hvad der kan afhjælpe problemet nu da du selv nævner, at du har mange data, formler og mange forskellige betingede formateringer. Jeg garanterer på ingen måde, at jeg har en løsning, men gik ud fra, at du også kunne være interesseret i andet end hardware udvidelse.
Du har fuldstændig ret. Og din opfordring bragte mig på sporet af at kigge på de betingede formateringer. Og det at jeg som nævnt ovenfor "ryddede op" i disse i 35 kolonner/365 rækker ser ud til at have hjulpet, så jeg nu godt kan fortryde, og hvor fortrydelsen bliver effektueret på mindre end 1/2 sekund. Jeg kan faktisk lige nu ikke få arket til at gå i "svarer ikke". Så det ser kraftigt ud til, at det var de mange opdelte betingede formateringer, der blev et for stort arbejde for programmet.
Mht. funktioner bruger jeg udover SUM HVIS (ofte indeholdende andre funktioner) de fleste steder. Derudover MIDDEL.HVIS, MIDDEL, MIN og MAKS, =HVIS(TÆLV(AI27:AI391)=0;"";TÆLV(AI27:AI391)/(IDAG()+1-$P27)*7) =SUMPRODUKT(--(UGEDAG($P$86:$P$389;1)<=5);--($AX$86:$AX$389<=3)) disse to matrix-formler: {=MPRODUKT(MINVERT(AJ5:AK6);AL5:AL6)} og {=MIN(HVIS(AC86:AC391>0;AC86:AC391))}
Jeg ved ikke, nu hvor oprydningen i de betingede formateringer ser ud til at have virket, om du har kommentarer til noget af dette?
Nu ved jeg ikke, hvor mange eksemplarer du har ad de ovennævnte formler, men medmindre du har rigtig mange af hver burde det ikke være et problem. Eneste kommentarer:
Pas på med funktionen IDAG(). Den er det der i Excel lingo hedder Volatil og det betyder, at mange af den slags formler kan være med til at lægge Excel "død". I stedet for matrixformlen {=MIN(HVIS(AC86:AC391>0;AC86:AC391))} kan du overveje at bruge funktionen =MINHVISSER. Har du testet, at der ikke (i ét eller flere ark) findes alt for mange ubrugte rækker eller kolonner? Tryk på F5, Last Cell, OK. Hvis Last Cell for eksempel skulle være i række 1048576 eller en anden række meget langt nede, udenfor det område du i øvrigt bruger i det pågældende ark, så markér alle de ubrugte rækker og slet dem. Gem herefter filen. Tilsvarende fremgangsmåde for kolonner.
Jeg bruger idag() seks steder, hvilket jeg ikke formoder er, hvad du forstår ved mange.
Har brugt din F5 osv. og slettet rækker og kolonner. Alligevel er sidste celle henh. 348 rækker længere nede og 4 kolonner længere til højre end der, hvor der noget som helst inkl. formatering. Men det er jo ikke det kæmpetal, du nævner, så jeg formoder, at der ikke er et problem her.
Kan du hjælpe med at oversætte matrixformlen {=MIN(HVIS(AC86:AC391>0;AC86:AC391))} til en =MIN:HVISSER formel?
I forlængelse af #11: Har du (eller andre) nogen mening om, hvorvidt det hvorvidt det i relation til mit spørgsmål er bedst at lave en individuel betinget formatering for hver kolonne, altså (her vist for blot tre kolonner) fx for S27:S391, V27:V391 og Y27:Y391, eller én samlet betinget formatering i og for alle vedrørte celler for fx S27:S391;V27:V391;Y27:Y391?
Har ikke noget konkret at have det i, men jeg ville umiddelbart foretrække S27:S391;V27:V391;Y27:Y391. Har du mange af den slags områder kan du eventuelt prøve at gå ind i Name Manager, oprette en navngivet formel, kald den for eksempel myRange og i Refers to feltet skriver du alle referencer (som S27:S391;V27:V391;Y27:Y391). Herefter kan du bruge myRange i betinget formatering. Ved ikke med sikkerhed om det hjælper noget, men du kan da prøve.
Det unuancerede svar - fordi sidstnævnte er en matrixformel. Jeg påstår ikke, at det nødvendigvis gør nogen forskel med så lille et område, men jeg har oplevet alt for mange gange, at der bruges matrixformler med for eksempel områder som A:D i formlerne, svarende til A1:D1048576, det vil sige 5,2 millioner celler og med den slags er man næsten sikker på at lægge Excel "død". I øvrigt er matrixformler under udfasning - de er ikke relevante i Microsoft 365.
Jeg prøvede at udskifte matrixformlen med den anden formel, og så bliver resultatet #NAVN? Så der må være en fejl et sted, hvilket jeg ikke kan gennemskue.
SUM.HVISER giver en sum, jeg skal bruge mindsteværdi. MINHVISER - som du oprindeligt skrev - burde da være god nok, for det hedder funktionen, så vidt jeg kan se, på dansk. Og der er ikke noget punktum mellem MIN og HVISER.
Kan fejlen skyldes, at den først virker med Office 365 og ikke med Office 2013?
Det er ret forvirrende, men tilsyneladende hedder den MINHVISER, hvorimod det hedder SUM.HVISER (med punktum før HVISER), men det er selvfølgelig førstnævnte du skal bruge.
Men som sagt giver =MINHVISER(AC86:AC391;AC86:AC391;">0") outputet #NAVN? Og den kan jeg ikke gennemskue. Hvis formlen er rigtig, kan det så tænkes, at den ikke fungerer i Excel 2013 men først i 365? Eller kan der være en uopdaget fejl?
#24 - I relation til #25 - jeg fik ikke læst hele tråden igennem, om hvad der rent faktisk er skrevet om din formel, så en lille rettelse til nævnte formel i #25
Du kan jo bruge din formel: =MIN(HVIS(AC86:AC391>0;AC86:AC391)) uden at det skal være en Matrix formel. Blot som ovenover.
Du har ret. Det kan være ret forvirrende med alle disse versioner af Excel når der hele tiden kommer mange nye funktioner til, som ikke er med i andre versioner og hvor nogle versioner kræver matrixindtastning, andre ikke.
Der er i alle kolonnens celler en formel =R113+U113+X113+AA113 som når når cellerne, der refereres til, ikke er udfyldt, giver nul, og ellers summen af de udfyldte tal.
Det virker. Jeg har et problem med arkets anden matrixformel af samme art, når den oversættes til din model. Det får jeg sandsynligvis først kigget på i morgen.
Den anden matrixformel, jeg bruger, er: {=MIN(HVIS(AX86:AX391>0,000000000001;AX86:AX391))} fordi AX-kolonnen indeholder denne formel: =HVIS(Q101="-";0,00000000000000001;HVIS(OG(U101=0;AF101=0);"-";AD101+AH101+AJ101+AW101)) (arket er indstillet til ikke at vise nul-værdier, men i tilfældet hvor Q101="-", har jeg brug for at få vist et nul, mens den reelle værdi skal være så tæt på nul som muligt) Det gør, at din ikke-matrikxformel reelt (med visning af kun 1 decimal) viser 0,0 grundet det bagved liggende resultat 0,00000000000000001.
Jeg forstår det som at +1 i slutningen af din ikke-matrixformel er "koden" for >0 (forstår ikke hvordan det med +1 fungerer - måske du vil forklare dette), og i og med at jeg skal bruge >0,000000000001, får jeg ikke det resultat jeg ønsker.
Nu er vi måske ude på overdrevet rent praktisk set, idet mit ark jo virker problemfrit med de to matrixformler, og vi har kun dette til behandling med henblik på, hvis matrixformlerne, som du skriver, bliver udfaset og dermed ikke kan bruges mere, så enten kan vi sige "den tid den sorg", eller også kan vi fortsætte, fordi det interesserer os at foregribe denne situation.
#33 - Nu går jeg ud fra, at det er mit indlæg du kommenterer (Skriv reference # til dem du svarer). At der kun returneres 0,0 fra en formel, som leverer et positivt resultat, er vel fordi du ikke har formateret din(e) celle(r) til at vise mere end 1 ciffer som decimal. I formlen jeg viste, kan du jo blot fjerne +1, hvorved du vil få vist værdien 0 (Nul) som er den laveste værdi, hvis en formel returnerer et virkeligt Nul. Hvis dit tal er 0,00000000000000001 er det jo ikke et Nul, men et positivt tal, som du vil kunne se, hvis du laver visningen af decimaler, stor nok.
Omkring det med at bruge matrix formler, kan du jo bruge dem, hvis du mener du vil det. Så er den her problemstilling jo fuldstændig irrelevant. Og så kan jeg ikke se, at jeg skulle have skrevet noget om, at Matrix formler udfases. De lever i bedste velgående, og bruges hvor de er egnede.
#34 Jeg har overset, at der var svar fra andre end XL-Enthusiast, beklager. Det er ham, der i #19 har skrevet: "I øvrigt er matrixformler under udfasning - de er ikke relevante i Microsoft 365." Jeg fik derfor indtryk af, at udskiftningen med ikke-matrixformler kunne være en art fremtidssikring.
Jeg fortsætter med at bruge de to matrixformler i mit ark, da de som sagt ikke genererer problemer.
Ja, der returneres 0,0 grundet decimalformatering, hvilket er meningen, når resultatet er 0,00000000000000001. Fordi jeg gerne i visse situationer vil have vist 0,0, og det sker, når resultatet er 0,00000000000000001 - jeg har generelt fravalgt visning af nulværdier. Resultatet 0,00000000000000001 gør i praksis ingen forskel for andre udregninger, hvori resultatet indgår, så det er en - i teorien ikke perfekt - måde at løse et praktisk problem på: i visse situationer få vist "nulværdi", som arket er indstillet til generelt ikke at vise.
Mht. til at fjerne +1, så vil det afstedkomme, at formlen ikke gør det, den skal; den skal vise mindsteværdi, som er større end men ikke lig med 0.
Tak for alle svar, hvori der er flere brugbare indfaldsvinkler.
Problemet kunne muligvis løses med mere RAM eller ved at skifte til Excel i 64 bit udgaven; det får jeg ikke afprøvet, da jeg som nævnt fik løst problemet ved at "rydde op" i de betingede formateringer. Det ser ud til, at når områdeangivelsen for en given betinget formatering brydes op i mange småstumper, så får Excel problemer med at håndtere de mange fragmenterede områdeangivelser (muligvis med mindre man har 64 bit-Excel og/eller en mere end almindelig stor hukommelse til rådighed). Så løsningen for mig var at samle fragmenterede områdedefinitioner til ét samlet område for hver type betinget formatering.
Tippet med at gemme oftere er selvfølgelig også brugbart, så man hele tiden kan komme tilbage, hvis programmet går ned. Og selv om jeg nu har fået ryddet op, vil jeg helt sikkert prøve at vænne mig til at gemme mere. For hvis jeg fx flytter rækker, bliver Excels områdeangivelser for de betingede formateringer igen fragmenterede - det vil helt sikkert ske. Og det er sin sag, at skulle rydde op i nævnte områdeangivelser, hver gang jeg flytter en række. Den radikale løsning vil i mit tilfælde være hele tiden at sørge for at områderne, som den betingede formatering gælder for, står pænt og sammenhængende.
Ordet udfasning er muligvis ikke velvalgt, men en kendsgerning er det i hvert fald, at matrixindtastning ikke kræves hvis man har Microsoft 365 subscription. I stedet er der kommet noget der hedder Dynamic Arrays. At jeg overhovedet på noget tidspunkt nævnte noget som helst om matrixformler var afledt af dit indledende problem om "svarer ikke" tilstand. Du kan uden problemer fortsætte med de matrixformler du har omtalt - og andre. Det eneste der ændrer sig er, at med Microsoft 365 er der ingen behov for at bruge matrixindtastning.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Ny bruger
Nybegynder
Opret
Preview
