Click on "Update Your Forum" on the Admin Home page and I get "The package you are trying to download or install is either corrupt or not compatible with this version of SMF."
Our forum is currently at release 1.1.19. All previous updates have worked like a charm.
Any suggestions gratefully received.
Thanks
Try installing this, as you'd install a mod:
http://download.simplemachines.org/index.php?thanks;filename=smf_1-1-20_update.zip
Read my sig, before you do so, though...
...woncha? ;)
Forum is at 1.1.19 and many functions crippled to the point nobody can post :(so finally dared to try and upgrade using SMF_1-1-20_update.php
Uploaded all the files as instructed or at least I think I did. A few from Sources go replicated on the root level.
All hell broke loose. :( Any suggestions gratefully received. Really need to convert to version 2
Thanks in advance
Upgrading...
Updating Settings.php... Successful.
Warning: file(/home/www/lymechat.freehostia.com/upgrade_1-1.sql) [function.file]: failed to open stream: No such file or directory in /home/www/lymechat.freehostia.com/upgrade.php on line 2201
Warning: implode() [function.implode]: Bad arguments. in /home/www/lymechat.freehostia.com/upgrade.php on line 2232
Warning: Invalid argument supplied for foreach() in /home/www/lymechat.freehostia.com/upgrade.php on line 2236
Successful.
Updating version number... done.
Taking the forum out of maintenance mode... Successful.
Upgrade Complete
That wasn't so hard, was it? Now you are ready to use your installation of SMF. Hope you like it!
Delete this upgrade.php and its data files now. (doesn't work on all servers.)
If you had any problems with this upgrade, or have any problems using SMF, please don't hesitate to look to us for assistance.
Best of luck,
Simple Machines
you should really be looking to upgrade to SMF 2.0 not SMF 1.1.20.
http://wiki.simplemachines.org/smf/Upgrading
you dont need to upgrade to 1.1.20 before you upgrade to 2.0.
Managed a forum SQL backup and a successful restore to a second empty test file.
Started plodding along with the source uploads, backed out and got Filezilla connected after which uploading especially of sub-directories was a snap.
Started running the SMF_2-0-11 upgrade. Got some errors about "nothing happening after a period of time" Pressed retry as suggested.
Step progress 14% after 42 minutes so looks like a projected 5 hours just for the database changes. Some additional SQL status metric indications than just the ticking clock would be a re-assurance that something is actually happening between the minuscule creeping status bar other than a loop. Five hours does seem excessive since database backup and restore literally took seconds. Backup.sql file is 16meg.
"this may take some time on large forums. " Is five hours usual for a 16meg database?
Thanks
!! Error Database "Scheduled_Tasks" does not exist. (14 of 42 of this script)
Clock stopped at 143 minutes. Pressing "Continue" has no effect. Not sure I even need "Scheduled_Tasks" d/b. Can I step over or create it and resume somehow. Any Suggestions?
Thanks
There seems to be something missing from my upgrade process as it is getting hung on missing SQL tables which it should have been able to create? Perhaps I need to back out and re-stratergize?
!! Error Database "Scheduled_Tasks" does not exist. (14 of 42 of this script)
Went into the PhpMyAdmin and plonked in a new table smf_scheduled_tasks using code found in upgrade_2-0_mysql.sql. as a basis. Not sure I specified it correctly.
---# Creating Scheduled Task Table...
CREATE TABLE IF NOT EXISTS {$db_prefix}scheduled_tasks (
id_task smallint(5) NOT NULL auto_increment,
next_time int(10) NOT NULL default '0',
time_offset int(10) NOT NULL default '0',
time_regularity smallint(5) NOT NULL default '0',
time_unit varchar(1) NOT NULL default 'h',
disabled tinyint(3) NOT NULL default '0',
task varchar(24) NOT NULL default '',
PRIMARY KEY (id_task),
KEY next_time (next_time),
KEY disabled (disabled),
UNIQUE task (task)
) ENGINE=MyISAM{$db_collation};
Managed to resume the update until step 16 when I got a similar problem with permissions_profiles. Attempted to add that table as well using code below as a model.
---# Creating "permission_profiles" table...
CREATE TABLE IF NOT EXISTS {$db_prefix}permission_profiles (
id_profile smallint(5) NOT NULL auto_increment,
profile_name varchar(255) NOT NULL default '',
PRIMARY KEY (id_profile)
) ENGINE=MyISAM{$db_collation};
Must have screwed up because after a hopeful resumption, I got
Executing: "Adding permission profiles for boards." (16 of 42)
!!
Error!
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 '' at line 5
Help!
if you are doing it manually in phpmyadmin, you have to replace the php with actual SQL...
{$db_prefix} needs to be your actual prefix
same thing with {$db_collation}
Hi Kindred. Thanks for your reply.
I did use the correct prefix hence step 14 and step 15 actually completed before hanging on another table at step 16, but why did I have to do this? What am I missing in the automated UPGRADE process?
I don't have the specs for your conversion process. I don't have the specs for the before and after sql databases and anyway am not qualified nor should I be messing in this way. I am just stabbing in the dark.
I used smf_2-0-11_upgrade. Is this correct to convert 1.1.19 to 2.0?
Thanks
yes, that is the correct file.
I have no idea why your server is not completing the upgrade process or performing the SQL statements...
I have done close to 100 upgrades from 1.1.x to 2.0.x at this point and I have never seen the errors that you are having.
I believe that you have them... but I have no idea what could be causing the issue.
There are a WHOLE BUNCH of SQL commands and updates that need to be made to convert from 1.1.x to 2.0.x
not sure what the step16 error is related to... might be the engine statement...
Guess I am stuck. I have to try and restore back to my broken version 1.1.19. Your update seems unable to handle my situation.
I didn't set this up originally so I don't know if it was modified in any way. I ran all the updates as they arrived no problem until update 1.1.19 (corrupt or not compatible) and just limped on from there.
Would be helpful to know just what tables I should have for version 19 and thus what I am missing that screws up the process.
it's not only new tables, there are revisions to column names and types and additional columns that need to be done for 2.0
The only way to go back would be to restore the backup of the files and database that you took before the backup attempt
Restored the SQL database. Hadn't realized that a "full backup" didn't include forum source files. Don't have a copy of the source code so downloaded smf_1-1-19_install to get the version 19 source and uploaded that back to the server.
Forum is locking me out pending upgrade. Feel like I am digging a hole ever deeper. Got to get back on the air. Any suggestions where I go from here?
Thanks
Can I do a clean install of version 2.0 then run your database conversion on my 1.1.19 SQL database?
no... a "clean install" of v2 would erase your settings.php
the only difference between a clean install and the "large upgrade" archive is that the clean install sets up a new database with new connections.
The large upgrade has all of the same files, along with the upgrade files (and does not overwrite your settings.php)
If your system is choking during the upgrade, then it would also choke during the upgrade doing what you just suggested.
locking you out how? Maintenance mode? If so, change the maintenance argument in Settings.php to 0 instead of 2.
Thanks Kindred. Changed the maintenance mode to zero and forum is back up in the same crippled mode as before but thinks it is now version 1.1.18!
All posts and members can be displayed but any attempt to post or reply to a post kicks back to home screen. Calendar returns "Invalid year value."
Logon needs a second enter to be enacted to get in. Not always able to move from one tab to another.
I noticed an option for extra debug data on the way in to the upgrade process. Perhaps I could try that also but first is there a model I can look at to compare my database to see what discrepancies there are as these seem to be screwing up your upgrade process. Scheduled_tasks and permission_profiles for starters.
I could give you credentials offline to surf the forum and see for yourself?
I'm sorry... I (personally) do not have time to do that right now. Perhaps one of the other team members can step in.
There is no specific model... but I guess you could install a separate copy of 2.0.11 and compare that against your 1.1.x database.
You are using a free host and it suggests that maybe you're hitting some limits on it. I see that freehostia gives 10Mb of MySQL Storage which, honestly, is nothing.
SMF 1.1.x does NOT have a "Scheduled Tasks" table, so the upgrade tool needs to create it. If it automatically failed maybe that is being discarded for being out of quota?
If the 10Mb limit for the database is true, I can only suggest you to find other host. You will *not* be able to run anything over that.
Or, are you using one of their paid plans?
Hi Margarett,
Thanks for taking the time to dig in to this problem.
We are on a plan with Freehostia. We have a 65 Meg MYSQL quota, and 500megs of data. we are only using a fraction of that. We are allowed 2 SQL databases. We use 1 for SMF but I did set up a second one to successfully try out the database restore. I can delete that. If the upgrade created a third interim additional SQL database that would have blown limits but we got no such message. With a projected 5hrs for the database upgrade process and a 16meg backup file, I do wonder just how much space and records are being added during this process.
The first message I got was of a missing scheduled_task table. Since you say this is a 2.0-only table a create failed somewhere in the upgrade with no error thrown. I simply created an empty one to try and resume the process and did succeed only to hang two steps further along at step 16. I was very unsure of what I was doing.
Chris
That's really not enough... 65Mb in MySQL is also very little.
As Kindred said, we have 100s of upgrades performed. Yes, there are some hiccups here and there but that's a problem I never saw and, considering the limitations of your service, I can't help but blame that...
You can always export your db and files to your localhost, run the upgrade there and then restore stuff to the server. Yet again, 65Mb of database space is NOT enough. Heck, it's kinda XX century :P
Edit: if you don't mind me asking, how much do you pay for that service?
Deleted the second SQL database so was sitting with 26.2meg in a 65meg allocation. Re-ran the upgrade and it hung in exactly the same place. smf_scheduled_tasks. Last time I created it manually and the process ran on two more steps.
Displaying my account stats, I am still sitting at 26.2meg of a possible 65meg.
Do you write a progress/error log for the process? How much more work SQL space than my database space do I need?
File space seems minimal.
48% Overall Progress
49% Step Progress
Time Elapsed: 385 mins, 23 seconds.
Database Changes
Executing database changes
Please be patient - this may take some time on large forums. The time elapsed increments from the server to show progress is being made!
Executing upgrade script 2 of 2.
Executing: "Adding Scheduled Tasks Data." (15 of 42 - of this script)
Updating indexes on "messages"...done
Updating indexes on "messages"...done
Updating indexes on "messages"...done
Updating indexes on "messages"...done
Updating indexes on "messages"...done
///////////////////
///////////////////
Sorting the boards...done
Sorting the boards...done
Sorting the boards...done
Sorting the boards...done
Sorting the boards...done
Moving to next script file...done
Populating Scheduled Task Table...done
!!
Error!
Table '**********.smf_scheduled_tasks' doesn't exist
I would seriously advise you to "assemble" your forum in your localhost (eg, use XAMPP), run the upgrade in place and then import stuff back to your server ;)
Do you guys have a cheat sheet for how to do this? XAMPP, localhost???
XAMPP or WAMPP
Downloaded XAMPP and tried it. Created an SQL database and tried to import my saved data. It told me my import file was too big. Reading the documentation (FAQs) I learn that all is done in memory and it ran out. I thought that was why we used disc files. I guess XAMPP is not an option. I don't consider 26meg a large file. The max I can upgrade to on Freehostia is 120meg SQL but only for the entire year and I have no returned errors to demonstrate that this is the problem.
Our forum has been down for too long, I have spent many long frustrating nights on this and the upgrade doesn't seem possible.
Is there a REPAIR option for my forum now version 1.1.18? I need to hunker down until there is a viable 2.0 upgrade solution? I see others now asking for help with this same upgrade, and some on localhost with XAMPP which is very discouraging?
Meanwhile,
How different in size is a 2.0 database compared with its 1.1.19 equivalent?
How many databases does the upgrade create in addition to the original if any?
How many tables are in the 2.0 database?
How much extra SQL workspace does the upgrade need as a rough percentage of the database it is processing?
Still trying to figure out total space allocation I need to upgrade having started out with 27meg database.
Thanks
I upgraded my host plan four grades more than doubling the SQL allocation limits to 140meg and allowing for 50 SQL databases instead of 2.
Restored and re-ran my upgrade script. With double the space it hung at exactly the same place as before 49% complete.
It Sorted the boards, moved to the next script file, and populated the scheduled_task table then lo and behold it hung unable to find same scheduled_task table it supposedly just populated.
Looking at my SQL usage, it is sitting at 24.5meg (26.2 last time).
Looking at the Scheduled task data, this is not something we need or would have used – we don't even keep birthdates.
There just has to be an anomaly in the upgrade script where this table is concerned at least as far as our database situation is concerned. Could you please take another look at it?
Thanks
Quote from: Imitator on February 12, 2016, 02:20:33 AM
I upgraded my host plan four grades more than doubling the SQL allocation limits to 140meg and allowing for 50 SQL databases instead of 2.
I'm sorry you did that. It's still an awful plan (140Mb is NOTHING!) and you should have considered an alternative host. For as little as $15-$20/year (even less in some cases) you find packages with limits in the Gb ranges. I hope you don't pay more than $0,05/month :-\
QuoteI guess XAMPP is not an option.
XAMPP is a perfect option ;) You can either import the database via command line (eg: mysql -u root your_database < your_sql_file.sql) or increase the upload limit if phpmyadmin
http://stackoverflow.com/questions/12707822/how-to-increase-import-size-limit-in-phpmyadmin
QuoteIs there a REPAIR option for my forum now version 1.1.18?
If you have a backup from before you started the upgrade process, just restore it and you should be fine, while we "study" why it happens to you. If not, the upgrade *must* finish now.
QuoteThere just has to be an anomaly in the upgrade script where this table is concerned at least as far as our database situation is concerned
Not really, no... Of course, the upgrade script isn't perfect but it has performed countless operations and I don't ever recall a problem like that. I can only guess that your host uses some kind of cache which creates a "time displacement" between the table creation and its availability for the following operation.
I can offer you the following: pick your database dump, zip and password protect it (use a strong password), then upload the file somewhere in the internet and PM me the download link. I'll upgrade the database for you and send it back.
I'm sorry you're having problems, but I'm strongly convinced that *no* part of that is SMF's fault... :(
Hi Margarett,
Sent you details you asked for via PM. Here is hoping I missed something obvious.
Pls confirm you were able to access the database so I can take it down,
Thanks
Hi.
I didn't get any PM from you today. Are you sure you sent it to me?
Sent 12th Feb two msgs
Indeed, sorry. I'm now replying ;)
Hope Filezilla has not corrupted the file sent to you....
"Status: Insecure server, it does not support FTP over TLS.
Status: Server does not support non-ASCII characters."
As I expected, the upgrade was performed flawlessly in my local machine.
Again, I can only suggest you (again) to choose a different host.
Just to be clear, is this (http://freehostia.com/hosting/supernatural-plan/) your current plan?
Hi Margarett,
Yes, that IS my current plan (sigh)
Thanks for coming up trumps on this. Glad it went so easily for you. Got everything uploaded but seemed to have blown the d/b access dotting one too many "i"s. Have a ticket in with freehostia support in case they have suggestions.
"Connection Problems - Sorry, SMF was unable to connect to the database. This may be caused by the server being busy. Please try again later."
repair_settings claimed d/b settings were incorrect didn't know what to suggest as a preferred value beyond /localhost. See PM.\
Thanks
A great step forward. Freehostia Support came through and reset my SQL pointers. I can now bring up a version 2 forum with your converted database.
However, this forum has the same problems as our 1.1.19 version. Can surf anywhere in the forum UNTIL I try a post. Unable to post any messages replies or send msgs.
As soon as I select the REPLY tab I cripple the forum. It kicks me back to the home screen instead and I am stuck there unable even to log off.
Had an initial pblm with theme pointers which was able to resolve. Repair_settings was crashing again. Haven't figured that out yet.
Fatal error: Call to undefined function: array_combine() in /home/www/***.freehostia.com/Sources/Subs-Db-mysql.php on line 649
Lines 648/649
foreach ($data as $dataRow)
$insertRows[] = smf_db_quote($insertData, array_combine($indexed_columns, $dataRow), $connection);
at this point, I am not sure what else we can do except heartily recommend going to a new host
Perhaps point me to the source.php files containing the theme, avatar and smiley URLs and Directory pointers which repair_settings.php shows as obviously incorrect so I can manually edit them?
Thanks
that won't help. There are no PATHS or URLS biult into those files -- they pull the path and URL info from Settings.php or the database entries
and fixing those is what repair_settings.php does
array_combine is a PHP function and it seems to be PHP5+ only. SMF does provide a compat library for pre-PHP5 versions.
So in any case, that error can NEVER occur.
Please, *please*, change hosts. At 9,95/month you can GET A VPS!!! not a crippled service with 100Mb for databases...
(do note, I'm not saying you should get a VPS, you shouldn't, it's just a comparison :P )
Guess you are right. (grovel) Cruised the Freehostia home page to explore all the wonderful and very easy ways it could be used and there was an item called discussion boards, and there was Simple Machines - just click here.
I clicked here and had a clone 2.0.1 forum set up in seconds with a welcoming post from simple machines. It did warn me about a directory problem for themes which could be instantly fixed if I "click here" which I did.
Tried to do a post and KABOOM, same as my forum, it became crippled, and kicked me back to the home screen where it froze. Will try the Freehostia customer support. These millennials, so XXI! Guess nobody tests anything anymore.....
Hi Margarett,
Your interest and special effort on my behalf is so appreciated. You have nailed it with that new PHP5 function. The PHP version was the problem and must have been since I started this thread in Oct 2014. This is displayed on the home page. Is it possible for the forum to interrogate this in the future and red flag to the user? Just a suggestion.
FreeHostia came back to me very quickly - they usually do within 20 min. My forum was running on PHP version 4.4.
They reset it to version 5.6 and my forum came back to life. There is an option screen for their users to select the version and mine was set to PHP4.4 there from day one. Not sure I was ever advised when they upgraded PHP. My unnecessary service upgrade was reversed and refunded.
My forum users are now actively posting again and I took a breather. Now back in and checking things out. We do have some problems, I assume from the conversion?
Able to Login, but Registration is inoperative "Unable to load the 'registration_agreement' template."
HELP tab non functional - "Unable to load the 'manual' template."
ADMIN is seriously problematic. Second and third level tabs missing. Many options/functions missing, return blank screen or kick back to the HOME screen. eg test of censored words. Credits just shows "array"
Unable to display my user groups. Generate reports displays options but kicks back to hope screen with CONTINUE.
The boards seem to function fine as does listing of posts from profile summaries but serious problems with my-messages. Able to list the messages but not to display them.
In spite of this, forum is robust. have never had it lock on me. have always been able to resume, and can actually log out again.
Can I somehow verify if I still have messages in my converted database?
Hope a few re-arranged pointers will solve this although concerned about the loss of messages.
Please advise,
And again, Many Thanks
First try to load fresh files, it seems that something is missing.
http://wiki.simplemachines.org/smf/How_to_upload_a_fresh_set_of_files
Hi,
The refresh did the trick. Totally flipped the look and feel to another scheme but I can live with that for now.
Now able to display all my old personal messages so nothing was missed on the conversion.
All the Admin sub-tabs are now actionable.
Think after two years I can finally close this thread as SOLVED,
Phew.
And Thank you so much
You're welcome. Glad you have it working.
Nevertheless, a point still stands. You are overpaying. A lot. Check your "paid hosts" board for much, much cheaper alternatives, who provide a better solution.