problem after upgrade !!!

[poolgame]

Good Day,

i update my installation 1.x to 2.x.

Today i have to do the reinstalled 8 x - always the same problem.

My categories are in the database, but i can not see it in the Forum.

can any body help please :S

[Steve]

Pm'ing team members will not get you help any faster. In fact, most team members have it in their signature not to pm them for support, as mine does.

Everyone has their area of expertise and when someone that can help you is online, they will.

[poolgame]

Dear SUPPORT Team,

i create a backup
i load the big upgrade package
i unzip it
i upload it
i create the Settings_bak.php
i type my ftp user and password
i start the update
after the update i get the error: Unknown column 'c.can_collapse' in 'field list' Sources/Subs-BoardIndex.php and can not see the categories in my forum

sorry guys, i test it 5 hours, i think thats enough...

i use the search function in this forum, found a little bit, have do any changes in the database, dont work...

[ninik]

I am not an expert but maybe this could help you?

https://www.simplemachines.org/community/index.php?topic=357069.0

[poolgame]

Thank you ninik for answer.

This Thread i read, and changed it in the database.

"(I'd suggest you to check the categories table and see if one of these two columns exist: can_collapse or canCollapse.
If you have the second (as I suspect), you should "simply" change its name to can_collapse (you can do it through phpmyadmin.)"

After i changed this, i get the next error:
Unknown column 'c.cat_order' in 'field list'
About this error i found the next topic:
https://www.simplemachines.org/community/index.php?topic=556788.0

but not help...

[ninik]

sorry to hear that... unfortunately, I cannot assist you any further because I myself am not good at it... 

In this case you will have to wait for the big-guns to make their appearance...

Just keep in mind that these guys are also working, have their own life, or due to time differences they may appear much later etc etc etc...

Well you know how it goes... but they do make their appearance 

[poolgame]

nice to hear ninik :S
But thank you for the good words

[Doug Heffernan]

nice to hear ninik :S
But thank you for the good words

Did you actually run the upgrade.php?

[Sir Osis of Liver]

IIRC, fixed a forum couple months ago where 1.x -> 2.0 upgrade failed because _categories table did not upgrade.  Running upgrade again did not help.  Ended up importing _categories table from scratch 2.0 database, restored categories manually. No idea what caused it.

[poolgame]

Hey orsis,

Thanks for answer, can you help me with the manually restoredbcategories?

[-Rock Lee-]

Hey orsis,

Thanks for answer, can you help me with the manually restoredbcategories?

It should not be so difficult to perform but if it is a heavy database it takes a bit, although I did not do many updates when I gave those errors I worked on the lamp until it was updated correctly ... It would be done from the SMF administrative panel although it can be do from the database but I do not recommend it at least until exhausting all the resources.


Regards!

[Doug Heffernan]

Hey orsis,

Thanks for answer, can you help me with the manually restoredbcategories?

It should not be so difficult to perform but if it is a heavy database it takes a bit, although I did not do many updates when I gave those errors I worked on the lamp until it was updated correctly ... It would be done from the SMF administrative panel although it can be do from the database but I do not recommend it at least until exhausting all the resources.


Regards!

How can it be done from the Smf Admin Panel? I am curious as how you managed to fix it.

The way I see it, if the upgrade failed to upgrade a database table which contains changes from the previous version, in theory it can be fixed by making the changes manually by comparing the old version table to the new version table. But you should keep this in mind, if that table interacts with other tables, the changes must be made there too. Suchas in php files as well. Say the cloumns have been changed, or new ones have been added for example, they need to be updated correctly to reflect the changes everywhere especially in database queries.

I think that the OP maybe did not run the upgrade script. It is worth a shot to run that script again imho.

[-Rock Lee-]

How can it be done from the Smf Admin Panel? I am curious as how you managed to fix it.

The way I see it, if the upgrade failed to upgrade a database table which contains changes from the previous version, in theory it can be fixed by making the changes manually by comparing the old version table to the new version table. But you should keep this in mind, if that table interacts with other tables, the changes must be made there too. Suchas in php files as well. Say the cloumns have been changed, or new ones have been added for example, they need to be updated correctly to reflect the changes everywhere especially in database queries.

I think that the OP maybe did not run the upgrade script. It is worth a shot to run that script again imho.

I do not know if the sea is the correct form or applies in this case, when it updates and does not take the names of the database to copy the name of the forums and agreandolo that allowed me without problems. Although I had the forum of branch 1.x and 2.x running on my machine to go correcting the problems arose when uploading version ... sorry if I did not get to fully explain my English writing is still bad.


Regards!

[Doug Heffernan]

How can it be done from the Smf Admin Panel? I am curious as how you managed to fix it.

The way I see it, if the upgrade failed to upgrade a database table which contains changes from the previous version, in theory it can be fixed by making the changes manually by comparing the old version table to the new version table. But you should keep this in mind, if that table interacts with other tables, the changes must be made there too. Suchas in php files as well. Say the cloumns have been changed, or new ones have been added for example, they need to be updated correctly to reflect the changes everywhere especially in database queries.

I think that the OP maybe did not run the upgrade script. It is worth a shot to run that script again imho.

I do not know if the sea is the correct form or applies in this case, when it updates and does not take the names of the database to copy the name of the forums and agreandolo that allowed me without problems. Although I had the forum of branch 1.x and 2.x running on my machine to go correcting the problems arose when uploading version ... sorry if I did not get to fully explain my English writing is still bad.


Regards!

I have no idea what you're talking about.

[-Rock Lee-]

I have no idea what you're talking about.

Sorry my English translation is bad, mainly my native language Argentine Spanish does not let me express everything right. Basically what I did was to make several upgrades locally until I could adequately achieve and apply it to the site in production tapeworm.


Regards!

[GigaWatt]

IIRC, fixed a forum couple months ago where 1.x -> 2.0 upgrade failed because _categories table did not upgrade.  Running upgrade again did not help.  Ended up importing _categories table from scratch 2.0 database, restored categories manually. No idea what caused it.

Yep, had the same problem while updating from 1.1.16 (I think) and had to do the same manual importing of certain tables (can't remember though if the _categories table was one of them, I was just happy to make the database fully 2.0.x).

One more thing though. After I did the imports in the database, I had to run the upgrade tool again on the old script linked to the new database. Nothing worked of course, but the upgrade tool though it was converting a regular 1.1.x forum with it's database to a 2.0.x version. I assumed (I was right ) that the tool will fix whatever syntax problems SMF 2.0.x had with the database, and it did . The new tables were fully SMF 2.0.x compatible, no errors .

I deleted the script afterwards, run the SMF 2.0.x fresh install script, ran repair_settings.php, repaired whatever needed to be repaired and everything was fine .

My advice would be:

1) Make a copy of the 1.1.x database and upload it as a separate database on your host.

2) Link this copy of the database with the forum script via repair_settings.php. Load the 1.1.x version of the forum, make sure that everything is working fine.

3) Upload the old SMF script (1.1.x) to a temp directory on the server, link it to the new copy of the 1.1.x database and give this forum a subdomain. Let's say smf11.myforum.com is linked with the smf11 directory (it resides in the root of your webspace).

4) Run the upgrade tool. If it throws any errors, just ignore them and try to load the forum. If it says that it has an error in this or that table in the database, empty out that table in the database and import the same table from the 1.1.x version of the database (you have both versions of that database running on the host).

5) Empty the temporary smf11 directory, copy the old version of the script in this directory (again) and run the upgrade tool again (let it fix the syntax in the table that throws the error in the 2.0.x version).

6) Keep doing this until all of the problems are fixed.

In my case, more than one table was problematic during the conversion, so I had to do this several times. If you have to do this only once... trust me, you're in luck . I had to do it 3 or 4 times via FTP on a 1Mbps connection . It's no fun .

[Sir Osis of Liver]

This was the one I fixed -

https://www.simplemachines.org/community/index.php?P=fa35e35acd8d907853e2531d7aafd477&topic=556788.msg3946252#msg3946252

[Chen Zhen]

If it is a similar issue as in the link you just posted then I can tell you it is something I have seen before.
If a table type maxes out at ie. 127 or 255 then it is due to the data type.
tinyint signed has a limit of 127
tinyint unsigned has a limit of 255

Change the data type of the table to ie.
int unsigned

[Sir Osis of Liver]

What was odd about it, forum currently has just 4 categories, but id_cat values were as high as 449.  id_cat is incremented from 1, unlikely the forum ever created/deleted anywhere close to that many categories.  Saw same thing on another small forum.  No idea why the value would get that high.

[Chen Zhen]

auto increment can be specified to start at a number greater than 0 when a table is created.
The table that was created the second time around prior to inserting data may have been set to start at 0 or by default but the initial table may have been set to start at ie. 200.
I'm not sure of the exact scenario & would likely have to look first hand to investigate.