The causes for this are explained in this video
Not Updateable

Also send an image of the query in design layout

Thanks for the very fast reply Shami.
I have watched the "Not Updateable" video, and the Trouble-shooter too.
I have attached the query as requested.

Take a look at Invoicing where Richard shows how to build an order entry system.

Hi Stephen
I highly recommend that you follow Kevin's advice. It will help you greatly.

John

Thanks guys.
I have been through the Invoicing video, but the order items subform was very basic, based on a single table, so didn't have a combo box to lookup the product and price from the Products table, etc. I will go through it again though.

Hi Stephen, a data entry form should be based on a single table, not a query, to avoid the form being non-updateable.  I know you want a query to include fields from other tables, but you can do that without using a query.  You can use combo boxes, DLookup(), etc., and other methods to bring data from other tables onto the form.

But doesn't that go against what Richard is teaching in his lessons and Tech Help videos Kevin?
He says that any calculations should be done in a Query, not a form as in his "Invoicing" video and in Access Expert 8 classes.
Have I completely misunderstood?
I have just watched them again and he does use Queries and data from more than one form.

He has also said a data entry form should be based on a single table, although I can't recall where he said it.  Calculations in a query do not necessarily make a query non-updateable.  If it's non-updateable, then you have to make changes in order to enter data.  And the best way is to use a single table for a data entry form.

So in my case then, I would have to do the data entry in 3 steps somehow?
Data-entry form 1 to add order info
Data-entry form 2 to add product info
Data-entry form 3 to add line item info
It seems like a lot of work - do you know of any videos that show you how to do this?
Acess is obviously very different to my current database where the process is really easy with just a primary form and subform.

That is exactly what I'm suggesting: separate data entry forms for separate tables.  Order form and order line-item form can be combined into one form, in a main form-subform setup -- but main form should be based on a single table, subform based on a single table.  Products should be on a different form, customers should be on a different form, etc.  You can have forms open one another to make for a better user experience.  For instance, on the order form, make a little button for the user to open up the customer form to add/edit customers.

Yes, you may need to do (much) more work at your end as a developer, but it is the end-user experience that counts.  If you have to spend twice the time to develop something that will enable your users to get things done in half the time, what would you do?  Exactly.  Your time spent on development is only a one-time occurrence, but the time your users spend on using your app will be *recurring* (weeks, months, years).  So you always try to minimize the users' time, not your time.  If your boss tells you otherwise, tell him what I just told you: double your development time, and you will halve your users' computing time and double their productivity.

Thanks Kevin
To be honest, it's the end-user I'm worried about, I'm not worried about my development time (it's my small company).
In my current system (attached screenshot), they have just one form (with two subforms) to open. The primary Orders form pulls information from the Orders table and the Customers table. There's a button to jump to the full Customers form if the customer doesn't currently exist.
The Line Items subform pulls from the Orders table and the Products table.
This Priary / subform / subforms works really well - it draws and saves data instantly during data entry, and is equally fast when using it to search for records.
I just don't seem to be able to do the same (or better) with Access. I'm struggling to see how to link the customer to a sales order and a product without joins between the three tables.
I'll keep researching,  but every tutorial I find (either Richard's or others) do it the same way with a query to pull from the three tables and perform the calculations.

In my old job where I used Access for exactly this kind of thing, my order line item table had its own "line item message" field.  When the user selected a product from the combo box, the product description was copied from the combo box's Column property to the "line item message" field, so the user could see the description, plus any additional info from other tables that DLookup() could get if I chose to.  What's more, the user could add additional line item message into the order, since it was part of the table.  That would be one way to do it with just a single table.

Sorry for the late reply Kevin, been tied up with other things (house moves) for a good few days.
Thanks for your suggestion, I'll go away and try a completely different approach as you suggest.
One question though - do you find that DLookUp() slows things up a lot?

Your user won't notice the slowness of DLookup in that instance because DLookup runs during data entry, when there are pauses between the user entering one field and the next.  Unless your user types faster than the time it takes for DLookup to run (which is usually less than a second), then your user won't notice the difference.  The slowness of DLookup (and other domain aggregate functions) is much more noticeable when it runs hundreds or thousands of times in succession, such as in a query.