To followup. I deleted all the database joins elements in those test tables - just because I know there are (or at least used to be) issues when you changed the rendering type (like from the default dropdown to multiselect) in a databasejoin element. Then I removed the actual table join from the list and recreated two new dboin elements again - one in each table, this time remembering to create them as multiselects right off - and then I recreated the join on the tables and tried my test again.
I now see what is happening - just no idea why. Have a look at the screenshots attached.
I didn't bother to look at the tables via phpMyAdmin until the 2nd save - but what happened when I changed the display/editing options for the repeat group from the normal "Yes" to "Always show as read only", the key values in the repeat table are replaced with sequential numbers (ignoring the parent_id) .
So the first time the form was saved, the 12 records in the repeat table had the 'repeat_states' values 1 through 12. On the 2nd save they changed to 13 through 24. And on the 3rd save they changed to 25 through 36. Only after I edited/saved the form enough times to get past the 51 options in the states list is when the option labels in the repeat group form started to show as blanks - because the keys they use didn't even exist in the 'states' table used by the database join element. That explains where the weird key values - up into the thousands - came from in the repeat tables in my actual development project. Because I was using a tabbed form - and working on testing a php form plugin script at that time - I didn't even notice this quirky bug in the repeats tab of the form until I had saved the form dozens of times.
I sure hope this can be fixed soon, because I was relying heavily on that 'Always show as read only' option to work. For security purposes, I want it so that there is no chance for a user to change or re-post those values in the repeat groups - as they are already literally bought and paid for and 'locked in' and cannot be changed.
As I have always suspected - and continues to be proven by events like this - there is a flaw in the dbjoin element when used in repeat groups that has existed for years now. One of these days I might actually figure it out, but this old man's brain power is deteriorating faster than an apple rotting at the bottom of a barrel - and it's times like this I just want to throw my hands in the air and retire from this fruitless, thankless, mad 'hobby' of mine once and for all.
