This is an extension of the same bug I've been whining about in this thread....
Can't delete database join
So this proves that it's not JUST database join elements.
When you try to delete (empty trash) for ANY element that was trashed from a repeat group, you will get an error and are unable to do so. (see attachment).
And that's because (just as was explained in the 'Can't delete database join' post) the code is now assigning the parent table name as the prefix to the element name.
e.g. In my example I am deleting the element 'fb_report_settings___report_data' - BUT the code is using the parent table name and in so doing trying to delete the column 'fb_report___report_data' (which doesn't exist - and if it did I would NOT want it deleted).
To make matters worse, and all the more confusing - if you don't check the element in response to the prompt "Select elements where you want to drop (delete) the associated database column" (to get past the bug) - even though the element gets removed from the joined table group, the element is NOT removed from the actual group that it comes from. So those 2 linked elements/groups are no longer in synch and the 2 linked groups will have a mismatched number of elements.
Between these 2 recent examples I have provided, I'd consider this a major bug (as who knows where else this bug is affecting data or the way it is being presented or stored?) - yet it's being ignored despite my recent efforts to bring it to light.
As mentioned in that 'Can't delete database join' thread - this bug goes much deeper than just being unable to trash an element - it also is causing the wrong table name being used as a prefix for any *_repeat_* table created.
I sure wish someone would take notice and fix this already.
Can't delete database join
So this proves that it's not JUST database join elements.
When you try to delete (empty trash) for ANY element that was trashed from a repeat group, you will get an error and are unable to do so. (see attachment).
And that's because (just as was explained in the 'Can't delete database join' post) the code is now assigning the parent table name as the prefix to the element name.
e.g. In my example I am deleting the element 'fb_report_settings___report_data' - BUT the code is using the parent table name and in so doing trying to delete the column 'fb_report___report_data' (which doesn't exist - and if it did I would NOT want it deleted).
To make matters worse, and all the more confusing - if you don't check the element in response to the prompt "Select elements where you want to drop (delete) the associated database column" (to get past the bug) - even though the element gets removed from the joined table group, the element is NOT removed from the actual group that it comes from. So those 2 linked elements/groups are no longer in synch and the 2 linked groups will have a mismatched number of elements.
Between these 2 recent examples I have provided, I'd consider this a major bug (as who knows where else this bug is affecting data or the way it is being presented or stored?) - yet it's being ignored despite my recent efforts to bring it to light.
As mentioned in that 'Can't delete database join' thread - this bug goes much deeper than just being unable to trash an element - it also is causing the wrong table name being used as a prefix for any *_repeat_* table created.
I sure wish someone would take notice and fix this already.
