Yes, I will be changing the structure to use numeric keys. Thanks all. I've been building databases for something like 30 years and yes, I should have known better :).
When I put together the sample mini database to display the problem, I found the cause. Ridiculously silly misspelling that escaped us and that even managed to get rekeyed with the same typo, good grief. Sorry to clutter the boards with crazy user error, but a sigh of relief that things aren't...
If only it were so simple lol.... the name gets exported into other places and has to match the way it was done in the first place.... BUT, yes, I DO have a solution by changing the main form/subform link to use a different field - but at this point it's just a puzzling thing that has my...
The photo is imported as an attachment, with a file name that is shorter than many, and all have a jpg extension, so it wouldn't be an issue with the filename rules. The database is huge, but maybe I can create a scaled down version with just a dummy main form and subform to recreate the...
I modified the table with the photo title so that the primary key is an autonumber instead of the photo name. Added the foreign key to the thumbnail table, and changed the master/child fields on the form/subform to use the auto number primary key instead of the former string primary key. As...
It matches. Not ideal that the primary key is a text string (photo name), but we have deleted the record and recreated it, rekeying the primary and foreign key entries, still with same issue. Later today I will see what happens if I add a numeric key and use that as the link, but even if that...
I have a database which is linked out to a backend that has thumbnail attachments in it. Opening the linked table allows me to view the thumbnail attachments, no problem. The thumbnails were all imported from jpg files, and one of the jpg file names is "Kingfisher with Treat.jpg" A subform...
AND... just learned something new that is valuable with that @ format which I can use - but now knowing that it also apparently strips other formatting properties. Totally getting off topic here now, but it seems like it's only useful when we want to substitute text for a null or zero string...
OMG Vlad - found the cause. The string field on the linked table had a format property of @. I don't recall ever setting that - as a general rule I do all formatting at the form level. When I saved the linked table as a local table, it stripped the format property - hence the local table was...
I created another database that has nothing other than the underlying table and one form with a list box that is using that table (lt_categories). Problem persists. The table is a linked table. I opened the linked table - saved it in design view to a local table, and pasted the same records...
oh wow. New database. Did not bring in problem form. Created a new form and only put ONE list box on it, which is using the same Row Source. There are only two fields in the source. I changed the forecolor to red just for giggles. Then when I go to form view, the primary key appears in...
Sounded like it would be worth a try - but even with a totally new database, the issue remains. However, I copied and pasted the form objects - and maybe just maybe it will be better to not use anything from the old form - to actually build the problem form totally from scratch? I'm going to...
Vlad - you missed part of the thread. I originally reported this as a coding issue, but it turns out it has nothing to do with the code. As a matter of fact, with all code STRIPPED from the form (recreated), the problem is still there. Picture a form that has a handful of list boxes on it...