Support

This is something that happens at backup time, not at restoration time.

First, a list of all tables (and database entities, if you have so chosen) is generated. This list has the original entity names, e.g. new_redirect_links.

This list is then processed and a mapping between the real (original) entity names and the abstract Joomla!-style entity names -e.g. new_redirect_links to #__redirect_links- is created. Basically we create a mapping between table names and a notation which allows us to replace their prefixes.

Then we process the CREATE command of every table, view, procedure etc, replacing the original table names with their abstract versions.

Unfortunately, this is NOT enough. Newer versions of the Joomla! CMS as well as third party extensions use named table indices, using the database table name prefix. If we do not address that the restoration WILL fail if you are restoring to the same database as the original site (since you cannot have two named indices with the same name under the same database). So we have to blindly replace `new_ with `#__. This also matches columns names which begin with the same string as the database prefix INCLUDING the underscore.

Considering the frequency of each eventuality (restoring to the same database vs using a misguided prefix like old_, new_, created_, modified_, asset_, vgroup_ etc) we have concluded that the former happens several thousands of times more frequently than the latter. Therefore we have to keep the blind replace. The other option would be writing a SQL parser which, to the best of my knowledge, nobody has managed to do in PHP in a way that's actually usable in a generic way and does not require manual intervention on every tenth table.

So, basically, you draw the short straw. You have to change the prefix of all your tables and their indices manually before taking a backup. And never, ever, EVER use the prefix old_ or new_ again. Just like bak_ and #__ it has special meaning and causes all sorts of trouble. Use a random four to five character prefix instead. Not less, not more and don't use non-random words.

Maybe just an idea to avoid others to face the same issue : why not having a warning about those "dangerous prefixes" when akeeba sees that such a prefix is used

Because in eleven and a half years spanning over twenty eight thousand tickets and three thousand emails we had exactly one issue report. Yours. You drew the short straw. Sorry.

Also, it's not a closed set. If the prefix matches the beginning of a row name you get a conflict. We do warn about bak_ and #__ which some people do use and had reports about at backup time. In fact, we will refuse to take a backup of these tables because they will definitely cause a restoration issue.

Very marginal and EXTREMELY uncommon cases are neither documented not warned about. Yours is such a case. The case of having a comment which contains valid (but commented out) SQL code inside a procedure on the same line as a non-comment SQL statement is another. The thing is, these issues affect less than 0.01% of our clients, making it unappealing to address them.