Actually, I've just had another look at that query, and it's going to update the incorrect table (my bad ). However given that you are already storing the MaterialsID in your Docket Table, you really don't need to store prices as well. You can simply collect the price based on the materialsID you are already storing in the docket table.
And this is where the problem is, the MaterialsID is not stored in the docket and that wouldn't be handy because I would always have the latest prices in the MaterialsDB. but The crux is that I need the Values of Materials!BuyPrice and Materials!SalesPrice stored in Docket!BuyPrice and Docket!SalesPrice so they reflect the value for the materials at that moment. If the prices in the MaterialsDB are changed these prices should be written to the new records created..
When I now run QRY_PriceUpdate, I get a message box asking for BuyPrice and SalesPrice but then the Prices in the materials database are updated..
One good thing it does it at the right place. So fired from a double click event, I would not have to open the table to edit the price of a material.
This leaves open the fact that when I open the DocketTable none of my BuyPrice or SalesPrice is filled with prices from the MaterialsTable, not in the old records and not in new records created..
As far as I know, storing the ID will only give me the current prices, this is why I need to store the prices itself in the table.. A fact is that the operator of this Touchscreen does not know the prices so the fields will be hidden when everything works,,