See the Not Updateable video.

Most likely your query is to complex for access to understand.

Hi Peter, your KlantenT table is joining to two foreign key fields: KlantID in one able, and KlantID in another.  Neither KlantID field is a primary key (no key symbol next to the field name).  When one table joins to two foreign keys like that, it's an automatic non-updateable query, mainly because those foreign keys are on the "many" side.  Let me illustrate this with an example.

See my picture below.  I have a customer table, order table, and invoice table, all normalized with proper primary keys.  But in the order table, the CustomerID field is not a PK.  It is a foreign key that would end up on the "many" side of a query.  Same is true in the invoice table.  CustomerID is not a PK, but a "many" field in a query.

I create a query similar to yours, by joining the customer table to the two CustomerID fields in the other tables.  The result of the query contains duplicate data everywhere.  This is what happens if you join to multiple "many" fields in that manner.  The query becomes non-updateable because Access wouldn't know what to do.  The invoice number "INV10000" is on the first and fourth row, even though it exists as just one row in the invoice table.  More importantly, this query returns nonsensical data that you can't use in any meaningful way.

Hi Kevin, I now realise that the structure itself is not correct. I do not have 'nonsensical' data, but I am missing records in the update (DVB_FU_T) table!
The purpose of the query is to show the customers with 'product X" who need to be serviced/checked regularly. But a new customer doesn't automatically gets a 'service record' in this way, so there isn't even a field I could update!

For now I have made a 'workaround' by adding some (update) fields to the KlantenT tabel itself and a checkbox to 'check' when the customer needs to be serviced or not.
So the selection and data input is all on one table now. This means partly double data input , but ok.