You got that right (while still saving your arm for holding appropriate celebratory refreshment and your back for sitting upright enough to drink it). I'll give it a whirl in 1.5.x and let you know if anything odd turns up. Jolly good.
Dunald, congratulations, go ahead and mark your opener Solved.
And rph, thank you for the improvement, I just noticed your Edit and downloaded the file. (Those of you who downloaded the original file but didn't see the edit, yet, should look a few posts above at rph's download link.) The initial one works well, gives OC complete Backups that are on the order of half the sizes of phpMyAdmin complete Exports, when for full safety bringing down both. The revision presumably won't degrade that in the least. Jolly good!
And rph, thank you for the improvement, I just noticed your Edit and downloaded the file. (Those of you who downloaded the original file but didn't see the edit, yet, should look a few posts above at rph's download link.) The initial one works well, gives OC complete Backups that are on the order of half the sizes of phpMyAdmin complete Exports, when for full safety bringing down both. The revision presumably won't degrade that in the least. Jolly good!
Hi I am back!
New and larger site and same problem!
My new site can´t make backup (yes i am using the vqmod "backups_improved.xml")
I was able to make backup earlier but now with more then 20.000 products it´s the same problem.
I have very short descriptions and no product images. But a lot of categories and sub-categories.
Any idea how to make the backup work for a site with a larg amount of products?
Please let me know :-)
New and larger site and same problem!
My new site can´t make backup (yes i am using the vqmod "backups_improved.xml")
I was able to make backup earlier but now with more then 20.000 products it´s the same problem.
I have very short descriptions and no product images. But a lot of categories and sub-categories.
Any idea how to make the backup work for a site with a larg amount of products?
Please let me know :-)
Some servers pose difficulties when databases rise through several hundred mb. How big is your database itself (if you use the host's "backup" or the phpMyAdmin Export)?
The categories and products are neatly singled out by JNeuhoff's export tool, which has several tabs in one Excel file that is easily amended so that you can send it back up with additions, changes, deletions. Have you tried that? (If you download it be sure to grab the correct version of it for your own OC.)
The categories and products are neatly singled out by JNeuhoff's export tool, which has several tabs in one Excel file that is easily amended so that you can send it back up with additions, changes, deletions. Have you tried that? (If you download it be sure to grab the correct version of it for your own OC.)
Hi,
When making a backup with phpMyAdmin the file is 16,8 MB.
Big or not?
I use a export/ import tool so yes I can edit my products. But It is more easy (faster) to be able to use OC backup if something goes wrong. If my import/export tool makes 50 new categories and a lot of sub-categories it takes forever to erase them one, by one....
When making a backup with phpMyAdmin the file is 16,8 MB.
Big or not?
I use a export/ import tool so yes I can edit my products. But It is more easy (faster) to be able to use OC backup if something goes wrong. If my import/export tool makes 50 new categories and a lot of sub-categories it takes forever to erase them one, by one....
I doubt we'll find these in any technical dictionary; or would want to. Large, under 100 mb. Big 100 mb up. I've seen one (not with OC) continue working at 160 mb and counting. In the grand scheme of things there are gargantuan databases out there. Practical concerns include being able to transmit it and to open it, and whether via phpMyAdmin and mysql documentation you see limitations for your own server, sometimes on the order of 20 mb.
The tool should be conveying the categories, subcategories, and products and their few tables up and down, without affecting the other tables. The db backup can be selective or of all tables. The tool is principally for working with categories, subcategories, and products, and allows you to work in a spreadsheet program. The db backup is principally for the sake of recovery, and allows you to work in a database program. Both have their tedious aspects, but neither should take forever.
Database backup using OC System / Backup (and in reverse Restore) is expedient and should work without incident. Database backup using host phpMyAdmin / Export (and in reverse Import) is expedient when you're used to it and should work without incident, but it also gives you opportunity to work with fundamental structure of the database itself. The more probably failsafe choice is phpMyAdmin (which on the remaining improbably few servers won't take back its own syntax). Using BOTH means, OC and phpMyAdmin, to back up databases helps to safeguard against complete loss when even one server is involved, but also when two or more servers are involved as in a migration. Servers are computers; set up and maintained by people; who booboo sometimes.
The tool should be conveying the categories, subcategories, and products and their few tables up and down, without affecting the other tables. The db backup can be selective or of all tables. The tool is principally for working with categories, subcategories, and products, and allows you to work in a spreadsheet program. The db backup is principally for the sake of recovery, and allows you to work in a database program. Both have their tedious aspects, but neither should take forever.
Database backup using OC System / Backup (and in reverse Restore) is expedient and should work without incident. Database backup using host phpMyAdmin / Export (and in reverse Import) is expedient when you're used to it and should work without incident, but it also gives you opportunity to work with fundamental structure of the database itself. The more probably failsafe choice is phpMyAdmin (which on the remaining improbably few servers won't take back its own syntax). Using BOTH means, OC and phpMyAdmin, to back up databases helps to safeguard against complete loss when even one server is involved, but also when two or more servers are involved as in a migration. Servers are computers; set up and maintained by people; who booboo sometimes.
Problem seems server. Point is to use phpMyAdmin for entire database, and to use export tool for category/product tables isolated for practicality of using Excel to add/modify/delete and put pack up. Some servers will have problems even with phpMyAdmin, but you're probably not near that limit.
In the present context it may help to take an approach to accommodating JNeuhoff's export/import tool (http://www.opencart.com/index.php?route ... sion_id=17) is to raise php.ini values -- preferably in cPanel (or similar) on host itself, with OC php.ini off so as not to override, but alternatively by editing OC php.ini if host change is unavailable and server honors the php.ini file(s). High enough values stop misbehaviors of the tool, and might well also simplify OC backups that exceed nominal sizes.
memory_limit 512M (64 marginal, 128 or 256 workable, 512 covers contingencies)
post_max_size 999M (set to more than upload_max_size)
upload_max_filesize 998M (set to less than post_max_size)
max_execution_time 300 (300 for contingencies and stabilities, if host permits or doesn't object)
memory_limit 512M (64 marginal, 128 or 256 workable, 512 covers contingencies)
post_max_size 999M (set to more than upload_max_size)
upload_max_filesize 998M (set to less than post_max_size)
max_execution_time 300 (300 for contingencies and stabilities, if host permits or doesn't object)
Who is online
Users browsing this forum: Majestic-12 [Bot] and 54 guests