Missing table smf_priv_check when trying to update from SMF 2.1 RC1 to RC2

Started by Towelie, January 12, 2020, 06:35:28 AM

Previous topic - Next topic

Towelie

Hi everyone,

I have a bit of an issue:

When trying to update to SMF 2.1 RC2, the upgrade process fails and it tells me i am missing smf_priv_check table.
Upon checking the database, indeed table is missing.
Checking my older backups, table is also missing.

What can I do ?

Dzonny

Hello there.

Did you used latest available upgrade pack from our downloads page?

Can you paste the exact error you're getting please?

Towelie

Quote from: Dzonny on January 13, 2020, 05:51:57 AM
Hello there.

Did you used latest available upgrade pack from our downloads page?

Can you paste the exact error you're getting please?
Hi,
I used the SMF 2.1RC1 to RC2 large upgrade package from the forums.
The error literally just said "Missing table smf_priv_check" and would prevent me from continuing. The message was displayed in the bottom left of the page as text.
My forum is pretty old and has gone through probably a lot of upgrades, so it would not surprise me if the issue was due to my forum being an "upgrade mutant" (eg so many upgraded versions one after another).
I had initially installed this forum in 2012.

PS: Currently I have given up on upgrading and won't try again until I am able to figure out why this error occured and how to get past it. I had a friend check a new SMF 2.1 RC2 installation and that table wasn't even present in the database so... strange indeed.

m4z

AFAIK for such "minor" upgrades the preferred method is to use the "Patch update" package. But I'm not sure if the Large Upgrade should work, too (I'd assume so).
But if it isn't supposed to be used, or if this is a bug, it might be that this table only exists in 2.0.
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!

Illori

there is no package manager patch for RC to RC releases. you can only us the large upgrade package.

shawnb61

This message is very confusing. Screenshots might help. 

I don't think there has ever been a table smf_priv_check in SMF???

Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

Illori

 D:\wamp\www\github2.1\other\upgrade.php (6 hits)
   Line 847:    $create = $smcFunc['db_create_table']('{db_prefix}priv_check', array(array('name' => 'id_test', 'type' => 'int', 'size' => 10, 'unsigned' => true, 'auto' => true)), array(array('columns' => array('id_test'), 'type' => 'primary')), array(), 'overwrite');
   Line 850:    $alter = $smcFunc['db_add_column']('{db_prefix}priv_check', array('name' => 'txt', 'type' => 'varchar', 'size' => 4, 'null' => false, 'default' => ''));
   Line 853:    $drop = $smcFunc['db_drop_table']('{db_prefix}priv_check');
   Line 2633:    $create = $smcFunc['db_create_table']('{db_prefix}priv_check', array(array('name' => 'id_test', 'type' => 'int', 'size' => 10, 'unsigned' => true, 'auto' => true)), array(array('columns' => array('id_test'), 'primary' => true)), array(), 'overwrite');
   Line 2636:    $alter = $smcFunc['db_add_column']('{db_prefix}priv_check', array('name' => 'txt', 'type' => 'varchar', 'size' => 4, 'null' => false, 'default' => ''));
   Line 2639:    $drop = $smcFunc['db_drop_table']('{db_prefix}priv_check');

i guess that table is to be dropped according to upgrade.php.

i have not read the upgrade.php file but why create the table if you are just deleting it again?

shawnb61

Oh lord, it's a dummy table created/modified/dropped within the upgrader to ensure the user has the proper privileges...   I had never noticed that before. 

So, if there's a problem with it, this points very strongly to a lack of proper privileges for the DB user used in Settings.php. 

I would audit that user in the DB & ensure all the proper privileges were granted. 
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

Dzonny


shawnb61

It's written to do exactly that.  Don't know why it is failing in this instance. 
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

Towelie

Quote from: shawnb61 on January 13, 2020, 06:03:10 PM
Oh lord, it's a dummy table created/modified/dropped within the upgrader to ensure the user has the proper privileges...   I had never noticed that before. 

So, if there's a problem with it, this points very strongly to a lack of proper privileges for the DB user used in Settings.php. 

I would audit that user in the DB & ensure all the proper privileges were granted.
My db name is towelie_smf (initially I used one of those shared hosts, long story)
My user is also towelie_smf
User has all permissions for the database towelie_smf


User doesn't have any global privileges (but then again it shouldn't need them)


NOTE: The only reason I was trying to re-create the db is because the installer wanted me to have a db xD
What should I do in this case?

shawnb61

Quote from: Towelie on January 16, 2020, 10:51:07 AM
User doesn't have any global privileges (but then again it shouldn't need them)
If that is the db user used in settings.php for smf to connect to the db, yes, it needs those privileges.

I'm confused by your installer note.  The installer is intended to create a new db - that's its lot in life.  If you wanted to keep and upgrade an existing db, then consider running the upgrader.
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

Advertisement: