FYI - ERROR found in default version of

[♥yesudo]

line 247 - in drop table query :

 

prodcts_description

 

should be:

 

products_description

[Guest]

if you look at your database.php file, in the catalog\install\includes\functions on line 201 it is there too.

 

so the one in the catalog\admin\backup.php file line 247 may be tied in with how the installation procedure is working.

[AlanR]

if you look at your database.php file, in the catalog\install\includes\functions on line 201 it is there too.

 

so the one in the catalog\admin\backup.php file line 247 may be tied in with how the installation procedure is working.

To save me the time of figuring out the implications of this for installs can you explain what problems this could create for newbies?

[♥yesudo]

my understanding on how it will effect the backup process is that the error appears in the restore element.

 

it attempts to drop the table to then restore a backup - but as it attempts to drop a table that doesn't exist(spelling mistake) then the correct table will still be there creating a 'Table already exists error' upon restore.

[AlanR]

my understanding on how it will effect the backup process is that the error appears in the restore element.

 

it attempts to drop the table to then restore a backup - but as it attempts to drop a table that doesn't exist(spelling mistake) then the correct table will still be there creating a 'Table already exists error' upon restore.

I understand that and I've made notes and already corrected a few files, thanks.

 

Most of time I spend here is spent on watching just for things like this but also helping newbies. So everytime I see something that could stump a newbie, especially on installs, I make a note.

[♥yesudo]

i think the file that Mibble mentions will create the same problem on an install if you are installing over an existing osc db.

[241]

is it not a case of drop table if exist and as the table does not exist it will not drop it.

 

I have had no issues or errors on restoring a database.

 

You are correct in that it is a typo.

 

What happens to all the additional tables added by contributions.

[♥yesudo]

it says drop Table prodcts_description which doesn't exist and as such leaves products_description in place.

 

which in essence could create a duplicate table error - but upon looking at a backup the tables are also dropped, by sql, b4 restore and the correct table name is used. thus circumventing a problem.

 

so yes there is an error - but it appears to get corrected, I assume, by sql.

 

I also wondered about additional tables - added when adding a contrib - but i think as the backup/restore is actually dealt with at sql level these will all automatically get included - i think the php drop table query maybe a herring(of the red variety).

[241]

yes that was my thoughts as there is no function to automatically add tables created by contributions to that part of code and as you say correctly this is dealt with at sql level without issue

[Chris Dunning]

It seems to me that if your database is kaput, your store is probably down....so wouldn't it be better to do that backup and restore through phpMyAdmin or whatever you have?

[♥yesudo]

It seems to me that if your database is kaput, your store is probably down....so wouldn't it be better to do that backup and restore through phpMyAdmin or whatever you have?

depends why you want to restore i would have thot - not always because db is kaput.

 

some people don't have phpmyadmin, don't know how to use it or don't know it exists.

[Chris Dunning]

I suppose that's true....and I could see that you might want to do a database backup for reasons other than a complete meltdown. However, I find it more than a little comforting to know that I have regular backups stored on my hard drive here as well as on the server in case everything goes bad.

 

I took a peek at the code and it seems to me that the osC backup function is pulling a list of tables from the database then backing up using that list, not a pre-defined list of the tables that existed in the original distribution. This really seems like the easiest way for the code to be written and the best way. I don't think the code is the issue if all of your tables don't go.

 

I have in the past had issues with the backup function not working properly - tables were left out or what have you. I think it was more a timeout issue than a coding issue. I think at the very least you should examine every backup you make (regardless of whether you do it with osC or phpMyAdmin) and make sure that all the tables came through. If you see "zones" at the end that's a pretty good indication.

[♥yesudo]

I think at the very least you should examine every backup you make (regardless of whether you do it with osC or phpMyAdmin) and make sure that all the tables came through.

i agree having also experienced probs b4.

[Arcadiauk]

Just been reading this, i presume this code needs to be changed whether it causes a problem or not, is that correct?

 

Derek

[♥yesudo]

Just been reading this, i presume this code needs to be changed whether it causes a problem or not, is that correct?

 

Derek

i have changed it on the stores I manage/build.

[241]

Just been reading this, i presume this code needs to be changed whether it causes a problem or not, is that correct?

 

Derek

In the view of correct coding then you can change this, however as pointed out in this topic it is dealt with at sql level and therefore changing the code should bring no discernible difference.

 

choice is your own