Home   2026-10-22 19:56:51

←

Excel kan voortaan meerdere waardes aan één cel toekennen

Original article

sluiten

Uitnodiging Tweakers halfjaaronderzoek

Graag nodigen we je uit om deel te nemen aan het Tweakers halfjaaronderzoek. Via deze enquête willen we een beeld krijgen van hoe je Tweakers ervaart en de verschillende onderdelen waardeert. Invullen duurt ongeveer vijf tot tien minuten.

Vul de vragenlijst in

Excel krijgt een functie waar Microsoft al meer dan veertig jaar niets van wil weten: het wordt mogelijk om meerdere waarden aan een cel toe te kennen. Gebruikers kunnen dan meerdere namen of cijfers in één cel zetten door die met komma's te scheiden. Excel behandelt ze als aparte waardes en kan ze dus los van elkaar filteren.

Het is voor het eerst in de ruim veertig jaar waarin het spreadsheetprogramma bestaat dat deze specifieke beperking verdwijnt, schrijft Microsoft. In de praktijk krijgt Excel de mogelijkheid om lijsten, arrays en geneste arrays in een cel te zetten waarvan de waardes apart kunnen worden behandeld.

Op dit moment wordt alles in een Excel-cel behandeld als één waarde. Als gebruikers daar bijvoorbeeld een lijst met namen in zetten, zoals 'Alice, Bob, Carol', dan ziet Excel dat als de string alice bob carol. Als gebruikers bijvoorbeeld kolommen willen sorteren in alfabetische volgorde, geldt die cel dan altijd als een 'A' en komt die bovenaan te staan. Hetzelfde probleem ontstaat als gebruikers filters willen toevoegen of bijvoorbeeld lijsten willen maken.

Excel waardes

Er zijn tientallen functies denkbaar waarbij het problematisch (of op z'n minst irritant) is dat Excel zo naar cellen kijkt. Maar in veel spreadsheets is het juist nuttig om ook de B van Bob of de C van Carol bovenaan te hebben. Hetzelfde geldt voor cijferreeksen of andere samengevoegde waardes.

Dat verandert nu. Gebruikers kunnen in een cel een Lijst invoegen waarbij waardes met komma's worden gescheiden, waarna Excel automatisch herkent welke verschillende waardes er in de cel staan. Dat kan overigens ook met terugwerkende kracht. Gebruikers kunnen een bestaande cel met kommagescheiden waardes omzetten in een lijst. Dat is handig voor wie al heel veel spreadsheets heeft en die niet helemaal opnieuw wil opbouwen.

De nieuwe functie is mogelijk doordat Excel nu volledige arrays in afzonderlijke cellen kan zetten. Door een bestaande array tussen accolades te zetten, blijft een array in dezelfde cel staan. Ze spillen dan niet meer naar andere cellen. Bovendien kunnen gebruikers voortaan meerdere arrays laten nesten in andere arrays. Gebruikers kunnen twee arrays zoals ={{1,2,3};{4,5,6}} combineren om ze als twee arrays in één resultaat te behandelen.

Excel waardes

De nieuwe functionaliteit om lijsten te maken in cellen is opt-in. Dat zit vooralsnog alleen in de bètaversie van Windows, specifiek vanaf versie 2610 Build 20520.20000 of vanaf versie 16.114 Build 26092111 van macOS.

Door Tijs Hofmans

Nieuwscoördinator

Feedback • 26-09-2026 10:53 123

26-09-2026 • 10:53

123

Lees meer

Reacties (123)

Komma gescheiden in een cel. Oi, hoe gaat komma gescheiden bestanden importeren dan? Als dat maar altijd goed gaat.
Het hele csv bestandsformaat is een groot mijnenveld. Ik heb ooit een importer gemaakt voor ynab van csv exports. Bij elke bank werkte het weer net anders. Dus denk maar niet dat je er met één bescheiden regex iets van kan maken.
Character separated values is inderdaad geen standaard. Ik gebruik altijd ; en . als decimaal. Dat is lastig want excel nederland ziet . als duizendtal, maar de rest van de wereld gebruikt daar , voor.

Deze feature maakt Excel nog minder handelbaar. Dit heb je echt niet nodig als tenzij je Excel wil misbruiken.
Het CSV (Character Comma-Separated Values) formaat is beschreven in RFC4180 met een update RFC711. Het is alleen jammer dat de meeste implementaties een eigen invulling/interpretatie geven van wat er met een comma separated file wordt bedoeld.

Dus zie je o.a. punt komma als separator om gedoe met punten en comma's te voorkomen terwijl de standaard beschrijft hoe je omgaat met de speciale karakters (komma, CR, LF, of dubbele quote).

Regionale formattering met komma of punt los het formaat niet op.
Nogal logisch dat niet iedereen zich aan die rfc houdt, die is pas van 2005 en csv bestanden bestaan natuurlijk al veel langer dan dat. Stellen dat programma’s hun eigen invulling aan “de standaard” geven klopt dus niet helemaal, omdat er simpelweg geen standaard was en bovendien - gezien de status van de rfc - er nu nog steeds niet is.
inderdaad, welkom in de wondere wereld van regional formatting. Zeker in de wetenschappelijke wereld gaat lang niet alle software daar goed op. decimal separators, thousand separators en die vreselijke list separator gooien regelmatig roet in het eten. En helemaal briljant als die instellingen eigenlijk een user-account op windows machine-instelling zijn. Dus inloggen met een andere gebruiker en je import-tool werkt niet meer omdat de commas nu ergens anders voor staan.

Ik heb al eens noodgedwongen twee stukken software moeten combineren, eentje die punt vereist als decimal separator en de ander die het enkel met commas doet. Dan heb je een run-as bat-script en extra useraccount nodig om dat gedrocht werkend te krijgen.

En dan kom je in Belgie, en heb je een azerty toetsenbord in twee smaken, Belgian Period en Belgian Comma, waarbij de toets in het numerieke veld dus een comma of punt geeft. Maar de gangbare toetsenbord in NL worden meestal als United States International geconfigureerd en staan dus standaard op 'punt', wat niet strookt met de NL weergave met commas. Wat zou het handig zijn geweest als we voor getalweergave ook gewoon 1 standaard zouden kunnen gebruiken.
Libreoffice gaat hier wel goed mee om. Kan het aanbevelen.

Er is een iso standaard getalweergave volgens mij.

[Reactie gewijzigd door jeroen3 op 26 september 2026 12:04]

LibreOffice respecteert alle ISO-standaarden. Is is een zegen, maar ook een vloek (voor LibreOffice dan). Juist omdat ze alle standaarden volgen en daar ook (terecht overigens!) heel rigide in zijn, maakt het dat de vertaling van in MSO gemaakte documenten niet altijd vlekkeloos gebeurt. En dat komt omdat andere partijen zich weer NIET aan die standaarden houden.

Maar inderdaad: een CSV-bestand slikt LibreOffice zonder problemen, daar waar Excel zich soms zwaar in verslikt. Sterker nog: Excel kan je de nodige "hoofdpijn" geven, vooral met hele uitgebreide en/of grote CSV-lijsten: het duurt eeuwen voordat Excel 'm opent, Excel kan 'm niet openen of, als 'ie 'm (uiteindelijk) opent, is het één grote warboel waar je eerst een hele tijd orde op zaken moet stellen.
Bij de invoer van csv-bestanden in LibreOffice komt best vaak een keuze scherm boven drijven om wat details aan te kunnen passen. Bij excel is het mij vaak opgevallen dat ze het automatisch fout doet...
En het lullige is dat het importprogramma in veel gevallen zelf wel kan bepalen wat de decimale komma en wat het scheidingsteken is.

Ik heb al eens een importprogramma geschreven dat precies dat deed. Het kan niet altijd uiteraard, maar als er ook maar ergens in je importbestand één getal staat met beide tekens, dan weet je genoeg (bv 1.234,50 / 1,234.50). Of een getal met twee duizendtal scheidingsteken (bv 1.234.567). Ook dan weet je genoeg.

Hetzelfde geldt voor het datum formaat. Ook daar kun je testen welke formaten mogelijk zijn. Zoveel zijn er in de regel ook niet: ymd, dmy en mdy. Okee en ydm maar die is gek. Anyway, test de datums in je bestand tegen deze formaten. Zijn ze ongeldig, streep dan dat formaat door. Met een beetje geluk hou je uiteindelijk één formaat over.

Het zal je verbazen hoe vaak dit goed gaat.

[Reactie gewijzigd door P_Tingen op 26 september 2026 21:12]

En dan data exporteren….de nl versie is 04-05-2016, de US versie geeft 05-04-2016

Enfin, 10 jaar later krijg je de kale CSV. Zoek maar uit wat de juiste datum is. Gelukkig stonden er ook data als 06-16-20216, dus US format. Horror

In een historisch bestand stonden ooit data van 1850-2025. Uiteraard in dd-mm-yy formaat. Was 05-04-16 nou 2016 of 1916……

Wij eisen nu dat men data in ISO 8601 notering opschrijft in (veel veldwerk gaat nog gewoon op papier)
rest van de wereld gebruikt daar , voor.
De rest van de wereld? Eigenlijk vooral één groot, vroeger machtig, maar snel geïsoleerd rakend land waar het metrische stelsel, internationale standaarden en beschaafde diplomatie nog niet doorgedrongen zijn.
Imo zijn wij op dit gebied toch echt degene die achter liggen en internationale standaarden niet accepteren. Er is een reden dat je comma separated value bestanden als standaard hebt. Omdat de komma niet als decimaal separator wordt gebruikt. Elk technisch / wetenschappelijk programma wat ik gebruik gebruikt punten als decimaal separators.
Dat is wat veel Amerikaanse software doet. Maar ISO/IEC zegt: "all ISO standards should use the comma as the decimal marker." Bron.
En volgens jouw eigen bron zegt ISO 80000-1 dat het een komma of een punt mag zijn, en alleen dat er ergens een notitie bij is gezet dat het een komma zou moeten zijn.

Maar los van wat ISO heeft bedacht, de defacto standaard in de wetenschap / technische wereld is gewoon de punt. Amerikanen zouden naar metrisch om moeten, wij zouden naar de punt over moeten imo.
Een standaard die is aangepast net onder Amerikaanse druk, laat ons wel wezen. Want waarom zou je een standaard die net duidelijkheid schept aanpassen om die duidelijkheid weg te halen? Dat doe je alleen maar omdat er druk is van 1 machtig land dat zich niet wil aanpassen.
Want Amerika zou zich anders wel aanpassen aan ISO standaarden? Standaarden waaraan we ons ook in Europa niet houden? Ik geloof er niks van...

En zoals ik schreef, het gaat verder dan Amerika, niks van technische / wetenschappelijke software (en hardware) die ik ken gebruikt komma's als decimaal seperatoren. Dan kunnen mensen heel hoog springen dat het de 'juiste' is volgens ISO, het is in de praktijk niet degene die gebruikt wordt. En dat is niet enkel Amerika. (Natuurlijk komen veel van deze dingen uit Amerika omdat ze daar gewoon voorop lopen op veel vlakken, maar zeker niet alleen).

(Overigens wil je een voorbeeld hebben waarop wij ons in Europa ook niet aan ISO standaarden houden? Bekijk de datumnotatie op GoT).
Er gaat ook geen dwingend karakter uit van ISO standaarden. Niemand hoeft zich eraan te houden. We gebruiken die standaarden alleen om afspraken te maken over hoe we bepaalde zaken behandelen.

In Europa zijn we ook niet verplicht om de ISO normen te volgen, maar kunnen we bijvoorbeeld gebruik maken van geharmoniseerde standaarden (EU versies van ISO standaarden) om een vermoeden van overeenstemming met wetgeving te realiseren.

Om trouwens wat voorbeelden te geven van technische programma's die komma's gebruiken:
  • Siemens NX heeft komma/punt als instelling (standaard als je DIN/ISO formaat gebruikt),
  • SolidWorks heeft een komma instelling, en volgt ook de instellingen van het operating systeem.
En om nu te zeggen dat wij achterlopen op de VS omdat we komma's gebruiken i.p.v. punten... kijk dan eens op de kaartjes op deze pagina: https://data.europa.eu/apps/data-visualisation-guide/number-formatting. Het gros van de landen lijkt de komma officieel te gebruiken.
Ik zeg niet dat we achterlopen op de VS omdat we kommas gebruiken. Ik zeg dat de VS voorop loopt op veel technische dingen, en hun software dus punten gebruikt.

Er zijn uiteraard programma's waar het in te stellen is, ik vermoed verrekte weinig die kommas gebruiken, maar ze zijn er vast. Overigens is automatisch punt / komma vaak heel irritant bij CSV bestanden.
Dat lijkt me echt flauwekul. Het is alleen bij computers zo omdat veel programmeertalen in de VS bedacht zijn. De afwijking is juist de . als decimaalscheidingsteken. Misschien moeten we eens ophouden de VS als standaard te zien.
Behalve dan voor IP adressen …
Ik wist niet dat IP adressen decimalen gebruiken ;) . Ik zie ze iig niet als duizendtal scheidingstekens.
Een CSV met daarin IP adressen zoals 192.168.1.200 wordt dan 1.921.681.200.
Een IPv4 adres is een 32 bits integer getal in byte-decimaal notatie.

Een IPv6 adres is op een vergelijkbare manier een integer in een creatieve notatie.

In beide gevallen weet ik dat microsoft excel daar niet mee om gaat zoals een techneut/nerd zou willen...
Er is een reden dat je comma separated value bestanden als standaard hebt. Omdat de komma niet als decimaal separator wordt gebruikt.
Je bedoelt "Omdat de komma niet als decimaal separator wordt gebruikt door, wat op dat moment, de grootste afzetmarkt was". Op Wikipedia staat een wereldkaart die toont welke standaard waar gebruikt wordt. En dat illustreert duidelijk dat de komma wel degelijk op grote schaal gebruikt wordt. TL;DR: een punt als decimaal wordt voornamelijk gebruikt in Engelstalige landen, India en China. (Wow, India en China die samenspannen om de VS een handje te helpen... Dat zie je niet vaak!)

Overigens helpt jouw argument alleen bij numerieke waarden. Als je ook met tekst werkt, dan gaat het nog steeds mis: is "Jantje, Pietje, Klaasje" één cel met de namen van (bijvoorbeeld) alle auteurs of is het bedoeld als drie cellen met elk één naam? Persoonlijk geef ik de voorkeur aan de conventie om in CSV bestanden een puntkomma als scheidingsteken te gebruiken. Het helpt de naam "C"SV een beetje om zeep, maar het voorkomt een heleboel problemen en wordt op best veel plekken ondersteund.
Je had ook USA kunnen schrijven. Daar weet iedereen wel van welk land je bedoelt 😉
Character separated values is inderdaad geen standaard. Ik gebruik altijd ; en . als decimaal. Dat is lastig want excel nederland ziet . als duizendtal, maar de rest van de wereld gebruikt daar , voor.
Microsoft heeft de fout gemaakt om opslag formaat en display formaat te mixen. Accepteer gewoon dat dat niet kan bij csv's. Bij xlsx kan dat vanzelfsprekend wel.

Voor opslag in een csv moet je nooit tekens voor duizendtallen meenemen, alleen decimale scheidingstekens. Als ze daarvoor hadden gekozen, had het niet uitgemaakt of je een komma of punt gebruikt.

Als veldscheiding is puntkomma of vertikale streep te gebruiken.
Mwah, ik zie bij mijn europese collega's ook andere export (van C++-programma's) met komma's exporteren, dus das Excel dat weer inkan lezen is voor die ene gebruiker in zijn lokaal eilandje een voordeel.
Dat is lastig want excel nederland ziet . als duizendtal, maar de rest van de wereld gebruikt daar , voor.
Dat klopt totaal niet. Bijna heel Europa, Zuid en Midden-Amerika en grote delen van Afrika gebruikt comma voor decimaal en niet voor duizendtal.

[Reactie gewijzigd door jumbos7 op 26 september 2026 14:57]

De rest van de wereld gebruikt helemaal geen , voor duizendtallen. Dat is alleen de Angelsaksische wereld. Het grootste deel van de wereld doet het net als Nederland.
Ik gebruik altijd ; en . als decimaal. Dat is lastig want excel nederland ziet . als duizendtal, maar de rest van de wereld gebruikt daar , voor.
Nee hoor, er zijn veel meer landen die het doen zoals in Nederland.
Maar het is nog lastiger want er zijn nog meer notaties wereldwijd....
Ik vertel altijd mijn collega’s dat ze CSV bestanden moeten importeren in excel, niet openen . Dan gaan dat soort zaken wel goed met csv.
tja, de meesten weten niet eens dat er knop 'get data' bestaat en zoiets als power query. Weet ook niet of ik per se blij word van deze nieuwe feature in Excel. Ik heb excel zien groeien van een simpel spreadsheet pakket naar een soort Frankenstein pakket wat van alles en nog wat doet of pretendeert te doen. Veel data-bewerkingen in excel schreeuwen volgens mij naar een betere oplossing dan de Excel-hel.
Dat houd me bezig op werk ;) laatst nog op het werk ook een Access bestand omgezet naar een Oracle database omdat het niet aan de ieisen voldoet (GDPR, backups, de hele hap).
Quoted en/of escaped inhoud kan dit prima afvangen in dit geval.
Quoted met “ of met ‘.. Engels en Nederlands brengt Excel CSV import ook in de war.
Nog leuker als een Excel bestand bijgewerkt gaat worden door iemand in een ander land (of in elk geval andere regionale settings).

Geen idee of dat inmiddels gefixt is door MS, maar rond 2003 was dat in elk geval een serieus probleem waarbij elke cel afzonderlijk een eigen regionale setting kon hebben.

Bij het kopieren en plakken van een rij of kolom werd dan de regionale setting ofwel genegeerd en alleen de waarde als ware het tekst overgenomen en ook nog niet eens altijd goed weer geinterpreteed.

Dus 1,00 gaat dan wel goed, zelfs als de decimale punt werd verwacht, maar 1,000 niet.
Inderdaad een drama. Ik heb Engelse en Nederlandse versies van Excel en import gaat dan soms fout. Grootste drama is IP adressen, wat je ook doet Excel ziet het als getallen met duizendtallen waar de punten staan.
Het gaat wel beter nu je gewoon PowerQuery in Excel kan gebruiken, dat kan je veel makkelijker je data transformeren hoe je het wil hebben.
Bij excel kun je de eerste lijn beginnen met welk teken je CSV is bvb.: sep=|
bron: https://www.ablebits.com/...ange-excel-csv-delimiter/
CSV (MT940) is natuurlijk ouderwets quick-n-dirty houtje-touwtje zonder validatie.

Hiervoor is CAMT.053 (ISO standaard) veel geschikter, gewoon een XML met DTD.
Vet, dan heb je het over https://ynab.danielhaitink.nl/ neem ik aan? Die heb ik jarenlang gebruikt, eerst voor YNAB en toen voor Actual Budget.
Eigenlijk om precies diezelfde reden, te veel verschil tussen CSV's van verschillende banken en daar was ik een beetje klaar mee :+ Was dus heel fijn om daar zo'n tool voor te hebben die iemand anders z'n probleem was!
Ha, fijn dat je er prettig gebruik van hebt kunnen maken! Was een leuk projectje om te doen.
Grappig ook hoe snel je dit nu zou kunnen maken met een LLM.
Een csv hernoem ik altijd naar txt waarna ik meer controle heb bij import en tekst naar kolommen functie.
zoals dat nu ook al gaat, met ""

"auto,fiets","tram","paardeweide 1,1234 AB,Amsterdam","voetbal,ijs,tennisbaan,xbox"
Wat ik begrijp moet je de arrays in tussen accolades zetten. Dat zal het verschil denk ik zijn met “gewoon” kommagescheiden bestanden.
Nou, precies zo: "ernst", 2026, {1,2,3}, "oud"
Om nog maar te zwijgen over het correct afhandelen van linebreaks binnen een cel. Wat dat betreft blijft LibreOffice veel sterker in CSV imports - dat zie ik Excel nooit evenaren.
Zoals gebruikelijk: niet

Comma Seperated Values, en dan de puntkomma verwachten als scheidingsteken...
Het zou niet de eerste keer zijn dat een afkorting van betekenis veranderd om beter bij de nieuwe situatie te passen; CSV wordt tegenwoordig ook uitgeschreven als character separated value (waarbij het magische teken een komma, puntkomma of desnoods een tab kan zijn). Vast blijven houden aan een slecht idee alleen maar vanwege de naam vind ik een onzin-argument.
Via json zoals atijd, csv is niet multi diminstionaal zoals xml of json zijn.
Nederlandse notatie van een bedrag is toch komma gescheiden? €1,00?
Uh ja. Maar Excel wordt voor veel meer dan verwerking van bedragen gebruikt…
Je maar als scheiding obv komma is gaat het mis bij bedragen lijkt me
Wat ik overigens echt vreselijk vind bij Excel is dat de taal van je OS ook bepaald welke taal je formules hebben. Ik kan er echt niet aan wennen om =som, =x.zoeken en =als.fout en dergelijke te moeten gebruiken. Vooral ook die vreselijke punten.

Bij MacOS kun je dit vreemd genoeg makkelijk instellen: per applicatie kun je de taal regelen.
Nou inderdaad, heb überhaupt nooit begrepen waarom formules vertaald moesten worden. Had ze gewoon altijd in het Engels gehouden wat mij betreft. Er is toch ook geen Nederlandse C# of Python 🤷🏻‍♂️
Maar de gemiddelde gebruiker is geen programmeur en spreekt niet altijd goed Engels (zeker buiten NL). Lastig is het wel, dat ben ik helemaal eens.
Ik snap het idee wel, dat men de code een soort van begrijpelijke, makkelijk leesbare mensentaal wil laten zijn, maar maak dan een heldere foutmelding bij. Nu zit de beginner alsnog vaak heel lang te klooien voor hij door heeft dat het puur aan een leesteken ligt wat met de Nederlandse taal-instelling actief anders moet zijn.
Maar alsnog hoeft dat niet zo worden opgeslagen. De formules worden geparsed en er wordt een vertaling naar code voor uitvoering gemaakt. Dan kun je ook gewoon een code gebruiken. Dan kun je gewoon die code opslaan. Vooral in het oude binaire formaat zou dat niets hebben uitgemaakt.
Het wordt juist niet in taal opgeslagen. Ik gebruik veel Excel op werk (Engels) en zie thuis (Nederlands) gewoon de vertaalde code. Simpel voorbeeld: =SUM(A1-A9) is thuis gewoon =SOM(A1-A9). En dat is maar een simpel voorbeeld waar iedereen wel uit komt, maar bij vooral logische formules wordt het wel zoeken naar de gewenste NL vertaling (of juist EN vertaling).
In de oude versies was dat niet zo. Gelukkig dat ze dat nu wel verbeterd hebben.
Ik probeer het zojuist op mijn office 2021 LTSC icm Win11 en was zo gedaan. Bestand -> Opties -> Taal.
Niet alleen de taalinstellingen zijn vreselijk, maar ook de verschillende versies van Excel die niet (volledig) compatibel met elkaar zijn. De ene versie kent meer functies dan de andere en ik kom heel vaak tegen dat mijn spreadsheet (meestal vol functies) niet door anderen gelezen kunnen worden. Andersom gebeurt minder, maar toch zo regelmatig dat het knap irritant is.
Ja en dat je tot op de dag van vandaag niet makkelijk CSV files kan openen in Europa omdat hij de komma als decimaal ziet en per se een puntkomma in de CSV wil zien als scheidingsteken. Ondanks dat 99% van CSV files een punt als decimaal hebben. Met de "import als" werkt het wel maar dat is altijd een stap extra i.t.t. gewoon dubbelklikken op de file. Gek word ik daarvan.

Bovendien, het is een comma separated values file, niet semicolon.

Maar inderdaad dat ze die functies in de lokale taal vertalen is ook van de zotte.

[Reactie gewijzigd door Llopigat op 26 september 2026 20:31]

Ik denk dat ze beter gewoon voor een JSON cel hadden kunnen gaan. In plaats van weer een nieuwe/andere notatie. Net zoals het mogelijk is in veel SQL databases. Het kan dan valideren of het een geldige JSON is of om eenvoudig een JSON schema te maken en toe te kennen aan cellen.
Wat ze nu doen is gewoon een array. Daar is niets nieuws aan. Dat kunnen veel SQL databases ook. JSON heeft in spreadsheets niets te zoeken.
Binnen spreadsheets is JSON niet echt handig, maar als export is het beter dan al die CSV varianten. Helaas ziet Microsoft dit nog steeds niet.
JSON heeft in spreadsheets niets te zoeken.
Dat is jouw mening. Ik zou het persoonlijk veel handiger vinden ivm API resultaten en uitwisselen van gegevens. En het biedt veel meer mogelijkheden.
Ongeacht of je gelijk hebt is deze discussie niet zo relevant. Microsoft heeft definitief gekozen voor een andere notatie, die overigens losstaat van de gekozen implementatie.
Nu nog een oplossing voor het belangrijkste probleem van Excel: dat het geen database is, maar de halve wereld het wel als zodanig gebruikt en denkt dat een regel een record is. Nog steeds kan een uitschieter van de muis of de poes die over het toetsenbord loopt de kolom met postcodes apart sorteren. "Huh? wat is er nu gebeurd? Weet je wat, het is al laat, bestand opslaan, morgen verder".
Het kan zeker functioneren als pseudo database mits het bestand correct is opgemaakt als Table
edit:
Excuses, ik wist niet dat informatief commentaar aangaande Excel ongewenst is.

[Reactie gewijzigd door Aduen op 26 september 2026 15:05]

Zeker, jij en ik weten dat. Maar al die vrijwilligers die de ledenadministratie voor hun vereniging opgezet hebben in Excel niet. Het zou veel duidelijker moeten zijn en met 1 knop aan te zetten. B.v. in de plaats van die "Je abonnement upgraden" knop.
Case in point: ik heb geen idee waar jullie het over hebben. Is excel niet sowieso al een tabel?
Nee, het is een rekenblad, een verzameling cellen waartussen je met formules relaties kunt leggen. Je kan een willekeurige kolom of rij apart sorteren.
Pas als je kiest Invoegen > Tabel met de optie 'Mijn tabel bevat kopteksten' gaat Excel zorgen voor sorteerknopjes boven de kolommen en de gegevens op de rijen bij elkaar houden.
Daat gaat bij mij dan al jaren automatisch ofzo
Als ik er filters opzet gaat toch meestal wel alles mee
En zo kun je excel sheets nog langer blijven gebruiken ipv er een applicatie voor te (laten) schrijven.
Maar wie durft de 15 jaar oude Excel sheet van Henk nog te wijzigen met deze nieuwe functie? Zeker als daarvoor het tabje "NIET AANRAKEN" aangeraakt moet worden :P

[Reactie gewijzigd door vickypollard op 26 september 2026 12:10]

claude of codex draaien hun hand er niet voor om.
Mooi toch? Applicaties zijn een hulpmiddel voor de business, geen doel.
Gaaf om te zien dat zulke kernfunctionaliteit nog steeds kan worden gemaakt, dat is een hele prestatie van het ontwikkelaarsteam denk ik.
Alleen jammer dat ze kortgeleden het hele office pakket van veel gebruikers onklaar hebben gemaakt...

nieuws: Optionele Microsoft 365-update lijkt Office-installaties soms te verwijderen

[Reactie gewijzigd door leploep op 26 september 2026 13:07]

Zo wordt het heel misschien uiteindelijk toch nog TreeSheets 😉
Ik denk aan quantum excel. Als je nou ook nog eens met alle waarden tegelijk kan rekenen. En de waardes in een 3d array mogen staan....
Lees nu net je reactie. (Too late) Ik dacht precies hetzelfde...
Kunnen we dan gelijk de intention-over-input functionaliteit erbij doen? Dat je spreadsheet zegmaar doet wat je wil in plaats van wat je in de cellen zet?
Weet je wat mijn grootste probleem met Excel is? Testability. Ik heb allerlei complexe kerstbomen in elkaar gezet met Power Query en weet ik weel wat niet meer. Maar een fijne testsuite om te bewaken dat het blijft werken zoals bedacht, dat is praktisch onmogelijk.
Dat klinkt natuurlijk leuk, maar ik voorzie alleen maar ellende. Excel (en Access) worden vaak gebruikt om tal van kantoor-applicaties te bouwen. Medewerkers maken iets 'slims' in Excel, stoppen daar allerlei bedrijfsinformatie in en dat bestand gaat rondzwerven. Niemand weet wie de laatste versie heeft en niemand weet wie uberhaupt een versie heeft. Vaak bedoeld als tijdelijke oplossing, maar we weten allemaal: niks zo permanents als een tijdelijke oplossing. Ook zijn ze vaak van het niveau 'hobby'. Deze 'handige feature' geeft gebruikers alleen maar meer mogelijkheden om nog meer rotzooi te maken. In het verleden in de softwareontwikkeling gewerkt. Het merendeel van de opdrachten was om een Excel of Access hobbywerkje om te zetten naar iets fatsoenlijks. Wat mij betreft mag er vooral gesnoeid worden in de Excel-features.

Om te kunnen reageren moet je ingelogd zijn