News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

Going from 1.1.11 to 2.0.newest

Started by bwaynef, March 14, 2015, 11:06:37 PM

Previous topic - Next topic

bwaynef

I posted this thread ...and let it die:
http://www.simplemachines.org/community/index.php?topic=519312

I'm running 1.1.11 and want to upgrade.  Initially when I created my site I used a script provided in the cpanel of my webserver.  Now, 1.1.11 isn't available so I'm having to do all these pieces manually.

I've created a database, a user, and associated that user w/ all rights to the created database.
I've installed the install pkg for 1.1.11 to the webserver.
When I go to domain.com/install.php I'm now getting:
Deprecated: Function mysql_list_tables() is deprecated in /home/intouch/public_html/beta/install.php on line 798
Some of the queries were not executed properly. This could be caused by an unsupported (development or old) version of MySQL.

Technical information about the queries:
Line #22: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE=MyISAM' at line 16
Line #40: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE=MyISAM' at line 13
Line #63: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE=MyISAM' at line 18
Line #75: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE=MyISAM' at line 7


and there are many more lines of the same.

I've 'replace-all-ed' "TYPE=MyISAM" to "ENGINE=MyISAM" in install.php and saved it and uploaded it again (although there are only 2 instances in the file).  Try it again, and it gives the same results.  Any help?

bwaynef

Well, that was quick.

I found 41 instances of TYPE=MyISAM in 'install_1-1.sql' and changed them to ENGINE=MyISAM.

Now this:
Some of the queries were not executed properly. This could be caused by an unsupported (development or old) version of MySQL.

Technical information about the queries:
Line #563: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(14) /*!40102 NOT NULL default CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP */,' at line 3
Click here to try this step again.




Then I found this thread:
http://www.simplemachines.org/community/index.php?topic=426591.0

...and made the change given in the next-to-last post.  I've now got a freshly-installed 1.1.11 forum. 

Now I've got to export the database from my current board into this one, then upgrade this one, ...then copy it to my current/production board after I've got everything working.


Does that sound right?

Herman's Mixen

just overwrite your files with the "Large upgrade package" ... run upgrade.php when done you should have an good functional forum period..

if you have problems after that post them here, make sure your host is using php 5.3 .x at least !! and mysql 5x
Met vriendelijke groet, The Burglar!

 House Mixes | Mixcloud | Any Intelligent fool can make things bigger, more complex, and more violent.
It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Albert Einstein

Former Godfather of our dutch community ;)

Kindred

actually, bwaynef, no.... your process is not correct.

SMF is not intended to be moved around like that - and by copying upgrading and copying back, you are adding TONS of work for yourself.

BACKUP. BACKUP. BACKUP

then Upgrade in place - directly on your production site.
http://wiki.simplemachines.org/smf/Upgrading

If you want to test the upgrade process first, then go ahead and try it on a test forum... but copying your database back and forth will cause you lots of headaches and will likely lead to errors.
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

bwaynef

I'd really like to upgrade on my non-production site.  How about something like this.

Production site    |     Beta site
production db     |      Beta db

Export production db ...and restore it to beta db.  Upgrade Beta site.   Then copy files from beta site (pointing to beta db) to the filespace for production site so in the end it would look like:

Production site            |    Beta site
Beta-turned-Prod db    |    Beta-turned-Prod db


It may be obvious from my questions how little I know, but I appreciate feedback.

Kindred

No. I am telling you that trying to do it by copying files is a sure road to disaster.

Practice on the test site... But don't mess around with copying back and forth...   Upgrade production in production, just make sure to take a backup first
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

bwaynef

Part of my concern is that I want to make sure that I have WORKING backups.  So I want to make sure I know how to export AND import the database. 

When I go to phpMyAdmin and export the db from my production site, then go to my beta site (both 1.1.11) and try to import it, I get the following error:
Error

There seems to be an error in your SQL query. The MySQL server error output below, if there is any, may also help you in diagnosing the problem

ERROR: Unknown Punctuation String @ 113
STR: />
SQL:
<!DOCTYPE html>
<html dir="ltr">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta name="google" content="notranslate" />
    <title>cPanel Login</title>
    <link rel="shortcut icon" href="/cPanel_magic_revision_1356811873/unprotected/cpanel/favicon.ico" />

    <!-- EXTERNAL CSS -->
    <link href="/cPanel_magic_revision_1366085305/unprotected/cpanel/style_v2_optimized.css" rel="stylesheet" type="text/css" />

    <!--[if IE 6]>
    <style type="text/css">
        img {
            behavior: url(/cPanel_magic_revision_1356811823/unprotected/cp_pngbehavior_login.htc);


SQL query:

<!DOCTYPE html> <html dir="ltr"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta name="google" content="notranslate" /> <title>cPanel Login</title> <link rel="shortcut icon" href="/cPanel_magic_revision_1356811873/unprotected/cpanel/favicon.ico" /> <!-- EXTERNAL CSS --> <link href="/cPanel_magic_revision_1366085305/unprotected/cpanel/style_v2_optimized.css" rel="stylesheet" type="text/css" /> <!--[if IE 6]> <style type="text/css"> img { behavior: url(/cPanel_magic_revision_1356811823/unprotected/cp_pngbehavior_login.htc);

MySQL said: Documentation
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '<!DOCTYPE html>
<html dir="ltr">
<head>
    <meta http-equiv="Content-Type" cont' at line 1


Any ideas?

Kindred

#7
Did you run repair_settings.php?

See, this is what I mean about copying contents being problematic. There are all sorts of configurations stored in the database which point to directories, urls and paths. Those all have to be corrected to point to the test location when you do what you have done.
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

bwaynef

The error comes in phpMyAdmin when I try to import it.  What does reapit_settings.php do?

Illori

what exactly are you trying to import into phpmyadmin? it seems whatever it is, is not your database but some other file type.

have you opened the backup file in a text editor to confirm it is a database backup? it should be a .sql file.

bwaynef

It appears I didn't get all of the database EXPORTED the last time. 

I went to phpMyAdmin, chose my smf database for my production site, username_smf1, chose export and made sure sql was the type chosen.  Waited on it to export.

Then I chose my beta database, username_smf3, and chose import ...and browsed to my file, username_smf1.sql.  It took its sweet time importing, but eventually I saw that it'd imported $someNumberOfRows successfully.  <--This was different behavior than I'd reported earlier.

I thought, awesome!  I can go to beta.domain.com and it should be roughly the same as domain.com. 

It is not.  There is nothing different about the beta site.  I'm apparently missing something.  I'll prod at this as I have time over the next few evenings.

Kindred

I have alreayd told you that you can't just do that. You MUST run repair_settings.php at the very least, In order to correctly set all of the paths and urls to your test location.

This is what I was trying to tell you...   There are settings in the database which are specific to the location of files... And by just moving the database contents over, things are still pointing to the OTHER location.
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

bwaynef

repair_settings.php on my beta site prior to the import ...or on my production site?

Essentially in this process I'm testing my backup procedure wherein I backup/export the db and restore/import the db.  You make it sound like testing backups is not recommended.

margarett

Run repair_settings in your "duplicate" setup. It will "detach" it from your "original" location.

Read this, it will explain what the tool does:
What is repair_settings.php?
Se forem conduzir, não bebam. Se forem beber... CHAMEM-ME!!!! :D

QuoteOver 90% of all computer problems can be traced back to the interface between the keyboard and the chair

bwaynef

I gather I'm exasperating a few of you.  For that I apologize. 

Can someone explain to me why, after I export the DB from my production site and import it into my beta site db, that I don't see any change on the board?  I've done this before and the beta board was filled with posts and users from the production side.  When I clicked a link on the beta site, since I hadn't run repair_settings.php, it took me to the production site.  ***IF*** that was the behavior I was seeing now, it would make a lot more sense why I'm being told to run repair_settings.php on my beta side.  ...That's NOT the behavior I'm seeing, and when I upload and navigate to beta.domain.com/repair_settings.php ...every value I see already populated is what I'd expect it to be.

(And full disclosure, I chose "save settings" and the behavior is the same.)

Illori

only reason i can think of is you uploaded your backup to the wrong database and it is not what your beta site is looking at.

bwaynef

I've done stupider, but I was pretty sure I was doing this right.  I'll try again ...maybe with better note-taking.

bwaynef

So, I took screenshots this time so I'm pretty sure I didn't do anything stupid (...but I have evidence if I did).  BUT I think I've discovered (at least) one of my issues.  Yesterday the export of my db was much smaller than today's, and much slower.  I suspect there was a server issue that led to some timeout on export, leading to an incomplete export.  That explains why I didn't see the changes reflected on my beta site.

I'll research this a more when I get time later today, but if any of you've run into this ...or it makes sense what's happening and could offer advice, I'd appreciate it.  I'm getting this error on import to my beta db now.

Error

SQL query:

[...]

MySQL said: Documentation
#1062 - Duplicate entry '1' for key 'PRIMARY'


This is likely due to the (partial) import that happened yesterday.

margarett

Yes, you should drop all tables from your "target" database before you start importing again ;)
Se forem conduzir, não bebam. Se forem beber... CHAMEM-ME!!!! :D

QuoteOver 90% of all computer problems can be traced back to the interface between the keyboard and the chair

bwaynef

Dropped tables and imported w/ (apparent?) success.  Now when I go to the beta site:

Connection Problems
Sorry, SMF was unable to connect to the database. This may be caused by the server being busy. Please try again later.


I'll try repair_settings.php later.

Advertisement: