I don't actually need help or support, it just suddenly occurred to me that the developers might not have noticed this and it might still not be fixed because of that.

When you backup your forms RSForm doesn't (or did not, if already fixed) save form ids. The ordering is still correct after restore, but if you have previously deleted any forms so that there is a gap in the numbering of the forms, the ids of any forms after the first gap will be wrong. This will break any form links etc on restore.

Also, if the backup is large (ie submissions included) restore can fail due to PHP timeout.

Consequently, both times I have tried using backup/restore to move RSForm between Joomla installations, I ended up using phpmyadmin instead. Which actually worked just fine, so it wasn't really a problem. Just thought I'd mention this on the off chance it is something the devs have not noticed and would like to fix.

Hello,

Changing the form id is actually a correct approach. Just think of what would happen if you already had a form with the same form id on the same installation.

As for the timeout issue, this really depends on the assigned PHP maximum execution time. Naturally the bigger the backup, the longer the restoring process. My recommendation would be to backup a single form and restore it (repeat the procedure until you have restored all forms) if low resources are available.

In your case, then yes, the best approach would be using phpMyAdmin... but the process itself can be a little technical (not all users are comfortable with this).

adrianp wrote:
I did, actually. Thing is, you already have a selection box for overwriting the forms and if the user chooses to use that then the ids should be retained. So the form ids should be stored just not used by default.
adrianp wrote:
That's kind of my point, really. An ordinary user does not know about PHP execution times, so if they backup their forms and submissions, they expect restore to work. For that matter even if the user knows about PHP and knows how to use phpMyadmin they won't find out about the "backup" not restoring until they actually try to restore it, at which point the original database might not be available or might simply be useless. After all often the reason for restore is because what is in the database is somehow broken. In my case I was just moving forms between installations, so there was no issue apart from the frustration of having to "do it twice", but if someone were to use this feature as an actual backup... Well not storing the ids makes this pretty useless as a backup anyway, but you won't find out about that before you try to restore either.