Sorry, sorry, sorry!! The above did not work and I would still like to know why but I got this to work doing it a different way. I removed the SysT from the query and in the OnCurrent property of the form placed the HelpPicturePath line. I threw in a unbound control on the form and then in the picture property placed the unbound control in the data source and now the picture shows properly.

I can't picture what you're saying. Can you maybe show me some screenshots?

Here's what I had when I was getting the read only error. The two tables have nothing in common so I didn't make a join. I only needed the second query, SystemT (a table I got from, I think, the ribbon video? But I thought, why waste a table and I can put some other stuff in it as well so I use it also for a Setup type 'thing') to act as a lookup reference to get the Help path. It worked until I needed to resize pictures and save that resize value but in doing so it exposed the read only issue which up to that time I didn't realize was there. I wasn't sure what was causing the read only issue until I watched your Updatable Recordset video which mentioned the lack of a new record asterisk when a read only error is present. Somewhere in all that I posted my OP when it dawned on me I could just use DLookUp to get that Help path reference and put it in the OnCurrent property. What I was saying earlier is I don't save the full path in one field, I have the path divided up into the path and then the filename. It all works now, and I understand why it went wrong but what I was asking originally was why can't two tables like that without a join or anything in common be used in a query? I did some reading on this and I do have a better understanding of the situation. Anyway, just trying to summarize what happened. Thanks!

If you don't have a JOIN clause between your tables and a query, you're going to create something called a Cartesian product where you get a copy of every record from the left table matched up with a copy of every record from the right table. It will always be non-editable.

When you create a query in Access with two tables and no JOIN clause, Access has no way of knowing how the records relate to each other. So it creates what's called a Cartesian product: every record in the first table is combined with every record in the second table. If HelpT has 10 records and SysT has 1, the result is 10 records, but if SysT had 5, you'd get 50 records.

This kind of result set is not tied to a single underlying table in a way that Access can track and update. Since each record in the result doesn't point directly back to a specific, unique record in one table, Access cannot determine which record to update when you try to change something. So it marks the entire query as non-updatable.

To be editable, a query needs a clear one-to-one mapping between each record in the result and a record in one of the source tables. That requires a JOIN, usually with a primary key/foreign key relationship. Without that, you lose update capability.

This is why your fix, removing SysT from the query and using DLookup to pull the path, worked. It gave you a clean, editable recordset from HelpT only, and just used SysT as a read-only reference outside the query.

This is one example where it's actually good to use a DLOOKUP inside of a query or a continuous form.

thanks Rich, appreciate the info. :-)