Hi Marc!
since the addition of the multi-row delete (and edit) feature, we have a nested forms situation when PMA_linkOrButton() decides that (probably due to a missing primary key), a generated link would be too long, and creates a mini form instead.
I just read that item, and I was shocked. I almost completely forgot about this. :-)
I see a general problem with the form method. When we place them all in a huge loop it will create huge amounts of POST data, which can lead to timeouts or POST-size limits when dealing with blob-fields without primary keys.
- When called from display_tbl.lib or display_tbl_links.lib,
pass an additional parameter to PMA_linkOrButton(), which would tell the function to avoid creating a button via a form if the URL length is too big. So the only way to edit or delete this row would be by ticking and use "With selected".
As an enhancement to that solution we could edit/delete a single row, if we move the tag each button per row with a unique id. The evaluation of tbl_row_delete will then take care that the row on which the button was pressed will be seen as marked.
With JavaScript, the button could just untoggle all rows and only toggle the one of the clicked row and submit it then to tbl_row_delete. This would workaround having to click on "With selected".
- Before starting the form that calls tbl_row_delete, try to
detect if the rows data is going to trigger the generation of a button, and if so, do not offer the multi- feature. The absence of no unique keys would be a case.
Regarding the note above I see too many possible problems and I think it would be best to disable multi-row for that cases. Additionally I think a visible (but not disturbing) message should be generated on screen which tells the user that he SHOULD put a primary key on his column.
$0.02, Garvin.