Previous Thread
Next Thread
Print Thread
Rate Thread
Joined: Jul 1999
Posts: 118
Enthusiast
Enthusiast
Offline
Joined: Jul 1999
Posts: 118
I am upgrading from 6.1 to 6.3

Problems

a) I think it is very inconvenient to do this with web based altertable routines. The web page usually timed out after 10 minutes or so. Then I just had an error message, did not know if the update step really had been done.

I watched the server activity with the top command, that kind of helped me to see when the mysql activity had died down, so I assumed that step had been finished.

So after a timeout at an url like xxxxxxx.com/ubbthreads/altertable-6.1-6.2.php?step=step3 I got an error page like "server could not be found"

So I tried a logical thing: hit the reload button. This seems to have the effect that the same step will be executed again, as suddenly the database was using up all the cpu time again, for a long time.

So instead of hitting reload on that url
xxxxx.com/ubbthreads/altertable-6.1-6.2.php?step=step4

I tried to guess the next url, like
xxxxx.com/ubbthreads/altertable-6.1-6.2.php?step=step4


then of course, I also did not get a page, but the altertable just went through its next step.

** summary:
this web based altertable with timeout is definitely not user friendly or easy to use. It does not allow to really verify if the database changes have been done correctly. Do you have another suggestion how to verify if I ended up corrupting the database? When the webserver times out, are you sure the altertable continues?

Also I had to watch the altertable constantly, without feedback. If there was some feedback (maybe execute 10 000 changed, then output a progress message), things were much easier, maybe even the timeout could be avoided.

I suggest that there should be at least a log file on the server that shows the success or failure of the altertable steps.

=====
now my problem.
while xxxxx.com/ubbthreads/altertable-6.1-6.2.php

was running, I got bored and wanted to look at then next step. So I clicked on http://www3.xxxxxx.com/ubbthreads/altertable-6.2-6.3.php expecting I would be warned before it would execute.

Instead, in the middle of altertable 6.1 to 6.2, the altertable 6.2 to 6.3 ran. with error message as follows

=======
Altering the Posts table to store the parent user id to restore the in reply to userrname.
SQL ERROR: Wed, Jun 18 2003 12:49:56 -0400 Unable to do_query: ALTER TABLE w3t_Posts ADD B_ParentUser INT(9) UNSIGNED, ADD B_LastPosterId INT(9) UNSIGNED, ADD B_LastPostNum INT(11) UNSIGNED
Duplicate column name 'B_ParentUser'Altering the Users table to add a field for banned users.
SQL ERROR: Wed, Jun 18 2003 12:50:02 -0400 Unable to do_query: SELECT B_Uid FROM w3t_Banned
Unknown column 'B_Uid' in 'field list'
Warning: Supplied argument is not a valid MySQL result resource in /home/httpd/www3.angeles2.com/ubbthreads/mysql.inc.php on line 131
Adding a table to store languages users can choose from...
Done

The Re: Username was re-introduced with this version and will appear on new posts. If you would like to update old posts you can now run this script to update these posts. This may take a while and might time out. If it does time out you can just reload the script and it will pick up where it left off. You may need to do this several times before it actually finishes.
------------

at the end, after the (hopefully) completion of the altertable 6.1 6.2, I ran this routine again.

this time I got these error messages.
Question: what should I do now??

==========
Altering the Posts table to store the parent user id to restore the in reply to userrname.
Altering the Users table to add a field for banned users.
SQL ERROR: Wed, Jun 18 2003 14:00:06 -0400 Unable to do_query: ALTER TABLE w3t_Users ADD U_Banned INT(1) UNSIGNED DEFAULT '0', ADD U_CoppaUser INT(1) UNSIGNED DEFAULT '0'
Duplicate column name 'U_Banned'SQL ERROR: Wed, Jun 18 2003 14:00:06 -0400 Unable to do_query: SELECT B_Uid FROM w3t_Banned
Unknown column 'B_Uid' in 'field list'
Warning: Supplied argument is not a valid MySQL result resource in /home/httpd/www3.angeles2.com/ubbthreads/mysql.inc.php on line 131
Adding a table to store languages users can choose from...
SQL ERROR: Wed, Jun 18 2003 14:00:06 -0400 Unable to do_query: CREATE TABLE w3t_Languages ( L_Entry INT(9) NOT NULL AUTO_INCREMENT PRIMARY KEY, L_Language VARCHAR(255), L_Description VARCHAR(255), L_Active INT(1) )
Table 'w3t_Languages' already existsSQL ERROR: Wed, Jun 18 2003 14:00:06 -0400 Unable to do_query: CREATE TABLE w3t_Mailer ( M_Time INT(11), M_Subject VARCHAR(255), M_Message TEXT, M_Groups VARCHAR(255), M_Bogus VARCHAR(255), M_Onebyone INT(1), M_Loop INT(9), M_Type VARCHAR(10) )
Table 'w3t_Mailer' already existsDone

The Re: Username was re-introduced with this version and will appear on new posts. If you would like to update old posts you can now run this script to update these posts. This may take a while and might time out. If it does time out you can just reload the script and it will pick up where it left off. You may need to do this several times before it actually finishes.

===============

Sponsored Links
Joined: Jul 1999
Posts: 118
Enthusiast
Enthusiast
Offline
Joined: Jul 1999
Posts: 118
[:"red"] probably only the last message if of maior interest.
I suspect I should get my backup and spend another 3 hours redoing this, while the board is still down!!

Unfortunately I forgot to do a backup right before the altertable. Well ....

I might run into the same problem though, if I get the timeouts. I wonder how I can avoid that? running it on the server, via lynx??

It seems that I need a setting in my.cnf to show I have dual cpu? because usually only one cpu worked on the altertable task!!

[/]

[root@a3p err_mysql]# cat 20030618_mysql.log
[ERROR][Wed, Jun 18 2003 12:44:19 -0400] [/ubbthreads/ubbthreads.php] [200.165.232.163] Unable to do_query: SELECT U_FrontPage, U_Groups, U_TimeOffset,U_Display,U_Favorites,U_WhichForums,U_Categories,U_Username,U_Password,U_SessionId, U_StyleSheet, U_Status, U_Privates, U_FrontPage, U_Number, U_Banned FROM w3t_Users WHERE U_Number = '795' - Unknown column 'U_WhichForums' in 'field list'
[ERROR][Wed, Jun 18 2003 12:44:19 -0400] [/ubbthreads/ubbthreads.php] [200.165.232.163] Unable to do_query:
SELECT t1.Mod_Board,t1.Mod_Uid,t2.U_Username
FROM w3t_Moderators AS t1,
w3t_Users AS t2
WHERE t1.Mod_Uid = t2.U_Number
- Unknown column 't1.Mod_Uid' in 'field list'
[ERROR][Wed, Jun 18 2003 12:44:19 -0400] [/ubbthreads/ubbthreads.php] [200.165.232.163] Unable to do_query:
SELECT DISTINCT Cat_Title,Cat_Number,Cat_Description
FROM w3t_Category
WHERE Cat_Type = 'forum'

ORDER BY Cat_Number
- Unknown column 'Cat_Type' in 'where clause'
[ERROR][Wed, Jun 18 2003 12:49:56 -0400] [/ubbthreads/altertable-6.2-6.3.php] [200.165.232.163] Unable to do_query:
ALTER TABLE w3t_Posts
ADD B_ParentUser INT(9) UNSIGNED,
ADD B_LastPosterId INT(9) UNSIGNED,
ADD B_LastPostNum INT(11) UNSIGNED
- Duplicate column name 'B_ParentUser'
[ERROR][Wed, Jun 18 2003 12:50:02 -0400] [/ubbthreads/altertable-6.2-6.3.php] [200.165.232.163] Unable to do_query:
SELECT B_Uid
FROM w3t_Banned
- Unknown column 'B_Uid' in 'field list'
[ERROR][Wed, Jun 18 2003 12:58:15 -0400] [/ubbthreads/altertable-6.1-6.2.php] [200.165.232.163] Unable to do_query:
ALTER TABLE w3t_Messages
DROP INDEX Messindx1
- Can't DROP 'Messindx1'. Check that column/key exists
[ERROR][Wed, Jun 18 2003 13:13:22 -0400] [/ubbthreads/altertable-6.1-6.2.php] [200.165.232.163] Unable to do_query:
ALTER TABLE w3t_Messages
DROP INDEX Messindx1
- Can't DROP 'Messindx1'. Check that column/key exists
[ERROR][Wed, Jun 18 2003 13:13:48 -0400] [/ubbthreads/ubbthreads.php] [200.165.232.163] Unable to do_query: SELECT U_FrontPage, U_Groups, U_TimeOffset,U_Display,U_Favorites,U_WhichForums,U_Categories,U_Username,U_Password,U_SessionId, U_StyleSheet, U_Status, U_Privates, U_FrontPage, U_Number, U_Banned FROM w3t_Users WHERE U_Number = '795' - Unknown column 'U_WhichForums' in 'field list'
[ERROR][Wed, Jun 18 2003 13:13:48 -0400] [/ubbthreads/ubbthreads.php] [200.165.232.163] Unable to do_query:
SELECT t1.Mod_Board,t1.Mod_Uid,t2.U_Username
FROM w3t_Moderators AS t1,
w3t_Users AS t2
WHERE t1.Mod_Uid = t2.U_Number
- Unknown column 't1.Mod_Uid' in 'field list'
[ERROR][Wed, Jun 18 2003 13:13:49 -0400] [/ubbthreads/ubbthreads.php] [200.165.232.163] Unable to do_query:
SELECT DISTINCT Cat_Title,Cat_Number,Cat_Description
FROM w3t_Category
WHERE Cat_Type = 'forum'

ORDER BY Cat_Number
- Unknown column 'Cat_Type' in 'where clause'
[ERROR][Wed, Jun 18 2003 14:00:06 -0400] [/ubbthreads/altertable-6.2-6.3.php] [200.165.232.163] Unable to do_query:
ALTER TABLE w3t_Users
ADD U_Banned INT(1) UNSIGNED DEFAULT '0',
ADD U_CoppaUser INT(1) UNSIGNED DEFAULT '0'
- Duplicate column name 'U_Banned'
[ERROR][Wed, Jun 18 2003 14:00:06 -0400] [/ubbthreads/altertable-6.2-6.3.php] [200.165.232.163] Unable to do_query:
SELECT B_Uid
FROM w3t_Banned
- Unknown column 'B_Uid' in 'field list'
[ERROR][Wed, Jun 18 2003 14:00:06 -0400] [/ubbthreads/altertable-6.2-6.3.php] [200.165.232.163] Unable to do_query:
CREATE TABLE w3t_Languages (
L_Entry INT(9) NOT NULL AUTO_INCREMENT PRIMARY KEY,
L_Language VARCHAR(255),
L_Description VARCHAR(255),
L_Active INT(1)
)
- Table 'w3t_Languages' already exists
[ERROR][Wed, Jun 18 2003 14:00:06 -0400] [/ubbthreads/altertable-6.2-6.3.php] [200.165.232.163] Unable to do_query:
CREATE TABLE w3t_Mailer (
M_Time INT(11),
M_Subject VARCHAR(255),
M_Message TEXT,
M_Groups VARCHAR(255),
M_Bogus VARCHAR(255),
M_Onebyone INT(1),
M_Loop INT(9),
M_Type VARCHAR(10)
)
- Table 'w3t_Mailer' already exists
[ERROR][Wed, Jun 18 2003 14:26:51 -0400] [/ubbthreads/ubbthreads.php] [test99] Unable to do_query:
REPLACE INTO w3t_Online
(O_Username,O_Uid,O_Last,O_What,O_Extra,O_Read,O_Type)
VALUES ('test99','795','1055960811','ubbthreads','','','r')
- Unknown column 'O_Uid' in 'field list'
[ERROR][Wed, Jun 18 2003 14:26:52 -0400] [/ubbthreads/ubbthreads.php] [test99] Unable to do_query:
SELECT DISTINCT Cat_Title,Cat_Number,Cat_Description
FROM w3t_Category
WHERE Cat_Type = 'forum'

ORDER BY Cat_Number
- Unknown column 'Cat_Type' in 'where clause'

Joined: Nov 2001
Posts: 10,369
I type Like navaho
I type Like navaho
Joined: Nov 2001
Posts: 10,369
Probably alot of key steps got skipped because the database wasn't ready with all the fields yet from the first altertable.

It's definately usually bad to run an altertable more than once.

I would restore a backup and run the altertables - one at a time - in order to ensure nothing got screwed up.

That 6.1-6.2 one was a doosey - and if it gets run more than once you'll lose Private Messages and favorites etc...

Joined: Dec 2000
Posts: 1,471
Addict
Addict
Offline
Joined: Dec 2000
Posts: 1,471
You can run the altertable scripts via commandline, that prevents the timeouts of the php-script.
Running the altertable script one more time will make things even worther...
Maybe you can rescue the data if you compare your current db-state to a fresh installed db. But as Josh said, PM etc may be gone.

Joined: Jul 1999
Posts: 118
Enthusiast
Enthusiast
Offline
Joined: Jul 1999
Posts: 118
I managed to fix almost all.

I ran the scripts via command line, for the second time. Took me a lot of work. I wish the upgrade documentation were clearer and had less pitfalls!!

Seems I did screw up the private messages!! Is there an easy way to recover them selectively from an old backup????? Or are they still around somewhere and can be recovered? how did they get lost in the first place??

I hope there is not another MAIOR problem caused by a repeat run of the altertable scripts.

Sponsored Links
Joined: Nov 2001
Posts: 10,369
I type Like navaho
I type Like navaho
Joined: Nov 2001
Posts: 10,369
Again - the altertables shouldn't be run more than once.

I would restore to before you ran them and run them again - in order - only once.

If the altertable gets run more than once - or gets interrupted - all the private messages end up assigned to User Number 0 - so they are gone - or there's no way to piece them back together - other than restoring and running the altertable again uninterrupted.

The upgrade instructions suggest dumping old Private Messages (from the admin menu) before the upgrade - as that step is intense - and depending on how the server is setup it can time out.

[]Before upgrading you may want to purge very old private messages via the admin section. This upgrade makes some major changes to the database structure and the step to process private messages can take the longest.
[/]

Last edited by JoshPet; 06/18/2003 10:04 PM.
Joined: Jul 1999
Posts: 118
Enthusiast
Enthusiast
Offline
Joined: Jul 1999
Posts: 118
how did they get assigned to user 0? Just curious!

is there any other damage done from the double running of the altertables 6.1 to 6.2, and 6.2 to 6.3??

it is kind of too late to run all this again! What other solutions are there??

a) delete all priv messages of user #0 (how), and getting them from yesterday's backup (how exactly?)? Is there any problem? I suppose the new priv message numbers do not conflict with the old ones!?

Same for favorites??

b) restore an old copy of the board, without upgrade in a different location so people can recover whatever was important!!!!! This would at the same time have a good cleansing effect, as most unnecessary old messages will not be in the new board.

(I think there is a way to send a PM to ALL registered people to inform them about the location of the messages?????)

c) use yesterday's database and do all the upgrading again (unpleasant thought, also that way one day's posts are gone)

Joined: Nov 2001
Posts: 10,369
I type Like navaho
I type Like navaho
Joined: Nov 2001
Posts: 10,369
That'll happen if the altertables get run more than once.
Or time out and start over on their own.

There's a lot of information on this at Community. Here is one topic - but there's a lot of discussion about the PM issue over there and some potential work arounds. Do a search.

Joined: Jul 1999
Posts: 118
Enthusiast
Enthusiast
Offline
Joined: Jul 1999
Posts: 118
infopop simply leads people astray, does not give clear warnings and instructions, allows more and more people to screw up their databases, their boards, and to lose hours and hours of time!!!

I never had a warning. The altertable php has no warnings that this might time out and thus corrupt the database. No explanation what to do in case of a timeout.

Simply, in my case, the upgrade cannot be done the way they say it. When I ran the altertable php from the telnet command line, one part took almost 2 hours. There is no web routine that reliably does such a chore without timeout. Just not possible.


A well documented software gives clear warnings. Maybe prints a time estimate for the duration of the data base manipulation before starting the routine.

They could easily just give a altertable file with mysql database commands, instead of web based commands for dummies. Maybe upgrade in batches of 10 000.

Infopop people try to make things easy, and this way they REALLY make it complicated!!!! Clicking away happily at routines that are DOOMED to fail is not good. Looks easy until the corruption surfaces.


While I am complaining, maybe someone at infopop is interested in the fact that wwwthreads.com and wwwthreads.org web sites are dead. No forwarding, just plain dead. No problem for me, but lost business opportunities for infopop.


Joined: Jun 2003
Posts: 1,025
Junior Member
Junior Member
Offline
Joined: Jun 2003
Posts: 1,025
Well, every set of instructions I have read has told me to backup the database before upgrading. This tells me that something could go wrong and I may have to restore and try again. That just seems logical to me. Granted, I haven't read the instructions for 6.3, so it might not say that in there.

Most hosted sites don't have telnet command line access. Hence the need for web based scripts.

I'm just saying...

Sponsored Links
Joined: Jul 1999
Posts: 118
Enthusiast
Enthusiast
Offline
Joined: Jul 1999
Posts: 118
ok I confess I did not take that backup warning seriously. I had yesterday's automatic backup, thank god.

But a warning that the upgrade ROUTINELY crashes the database, if the database is big, would have alerted me and convinced to backup. Still, it took me 5 hours of work to find out the database crashed, 4 hours of work to find the fix, another 5 hours of work to redo the database upgrade. Then more hours of work to look for the fix on the lost PM. That could be easier!!!

Also, as it is completely impossible to do an online altertable that takes 90 minutes to complete, they should offer another option, a command line php routine, and a command line mysql command list. I had to build my command line php files myself (after all it is 9 steps), and only after I already crashed the database.

Or find out how to split the stuff up in pieces of 10 000 posts at a time, or whatever. Like change 10 000 posts, output a message (to keep the connection alive), then do the next 10 000, output a message, etc.

Joined: Nov 2001
Posts: 10,369
I type Like navaho
I type Like navaho
Joined: Nov 2001
Posts: 10,369
It doens't "ROUTINELY crash the database". Well it does seem that way for you, but you don't ever seem to follow the directions.

I have upgraded more forums than I can count, including one with over a half million posts.... and I haven't had any trouble with the current altertable. I did with the early beta of it (when 6.2 first came out). I can routinely upgrade forums in 2-3 hours depending on their size... using all sorts of different servers, hosts and platforms.

The big step in the 6.2 altertable is the private messages. Not the posts.

From Upgrading.html
[]
Before upgrading you may want to purge very old private messages via the admin section. This upgrade makes some major changes to the database structure and the step to process private messages can take the longest.
[/]

It warns that large numbers of PMs could take a while and might time out. That's because it has to convert every one of them from user name to user number... and match them all up. It can't be done with a series of queries... it's a series of loops and joins etc... When that process gets run twice it sets the User Id on the PM to 0 - check the table - all the PMs are there - you just ended up running it through that process twice. And unfortunately once they are all assigned to user "0", there's not really an easy way to reassign them..without going back to a backup of that table. I'd restore the database to second database - run the altertable on that - the extract the Messages table to the live database. Then you don't need to step backwards with posts etc.... and can just deal with what's most likely broken.

I'm thinking your *real* trouble came when you ran two altertables simultaniously because you were impatient.
So in that case - you are correct. Infopop does not warn you that running 2 altertables at the same time can mung up your database. But they do say to run them in order.

I understand you expected a warning - but in all the altertables that there have been, I think only 2 of them were broken into steps - and even those do the first step the minute you start it. The rest just go right through it.

From the upgrading.html file... at the very top:
[]
Upgrade instructions are listed in reverse order. So if you keep up with each upgrade, your upgrade instructions will be right at the top. (NOTE: If you have to run an altertable, make sure you only click on it one time and do not hit the stop button during this time. Some altertables will take awhile to finish.

If you can it is always a good idea to back up your SQL database. You can use something like phpMyAdmin for this or from a telnet prompt... blah blah blah

WARNING: When running some of the altertable scripts your browser may end up timing out. Do not reload/refresh the page. Mysql will still be working and it will continue as normal when it's done.
[/]

But in your first post above you said:
[]
So I tried a logical thing: hit the reload button.[/]

For the vast majority of folks - when the directions say "do not" then it's really not the "logical thing".

For your next upgrade, I'd backup the database - read the directions. If you are among the first to upgrade, I'd even head on over to infopop.com and see if anyone's having any issues or troubles. That'll give you a heads up if there's anything you need to be aware of. Then take your time and do the steps in order. It shouldn't take you that much time and should be relatively painless.

Joined: Mar 2000
Posts: 21,079
Likes: 3
I type Like navaho
I type Like navaho
Joined: Mar 2000
Posts: 21,079
Likes: 3


- Allen wavey
- What Drives You?
Joined: Jul 1999
Posts: 118
Enthusiast
Enthusiast
Offline
Joined: Jul 1999
Posts: 118
I did [:"red"] NOT [/] naturally hit the reload button.

I watched the mysql demon, via top. When it stopped, I just went on with the upgrade, manually changing the url to the next step. What else could I have done?


Also there was no clear warning that timeouts were likely and would screw up the database. I think these altertables should be made with timeout in mind, sort of timeout proof. See below.


Then when the board showed all kinds of error messages, I checked what parts had not been done, and redid this step.

After a few iterations, I had redone most steps of the altertable 6.1 6.2 as half of these steps had timed out.

I think there is an inherent problem: I think after a web server timeout, the processes started by it get killed. Does not make sense to allow a bunch of runaway processes continue forever while their output will never reach the web page

So this is what causes the problem.


[:"red"] So I suggest to reconsider my suggestions:
[/]
a) provide altertables also in mysql command format and/or php command line format. Even people with shared web servers can ask admin to run one routine for them once a year!!

b) Keep "DROP" commands for a later time, when we have tested all the upgrade. This way no information gets lost. so it is easy to re-run just one part of the altertable again. In other words, use an altertable/addtable routine, and only much later a droptable routine.

Please make altertable routines "timeout proof"!!
Long altertables that time-out should be made in a way that they can be redone with no problem.


Something like: for all rows where UID is not equal to default keep processing.

This way that process can be redone various times. And it will skip the part that already has been done, so eventually it will end.

Also, before starting a step, the altertable should give clear instructions what to do in case of a timeout or other problems. Actually, it should be in a way that reload will solve.
What do you expect a regular user, without telnet, to do after he gets the "server not found" or whatever timeout error message??? sit for how many hours doing nothing? or get to the next step of the altertable how?

There are only 2 naturally possible reactions. "Reload" or "Back". Both seem quite fatal!! I guessed the url for the next step and typed it in manually. I still do not know what should have been done!?

I finished this, so it is of no maior concern to me. I write this more so infopop can improve their documentation and procedures, to make them userfriendly.

So people can follow them without having to spend 5 hours of detailed study of the altertable programming details, and another 5 hours pouring over the board to find if there are any issues.

Joined: Nov 2001
Posts: 10,369
I type Like navaho
I type Like navaho
Joined: Nov 2001
Posts: 10,369
from your message:
[]
So I tried a logical thing: hit the reload button.[/]

The timeout won't screw up the database - doing it a second time will.

Read the directions:
[]
WARNING: When running some of the altertable scripts your browser may end up timing out. Do not reload/refresh the page. Mysql will still be working and it will continue as normal when it's done.[/]

It's tough to make things timeout proof, since the timeout limit is set in the php.ini and many people run in safe mode.

Again, I think the *real* problem was that you ran two of them at the same time. That is the part that screwed up your database. And again, you're right there was no clear warning not to do that.
Of course, until recently there was no warning on McDonald's coffee not to dump it in my crotch either. But I always figured it'd be a bad idea.

This isn't infopop's site. If these are suggestions that you'd like for a final release for Infopop - there is a suggestion forum at http://community.infopop.net
We do non-infopop supported hacking here, not offical infopop support or development.

Joined: Oct 2000
Posts: 2,223
Veteran
Veteran
Offline
Joined: Oct 2000
Posts: 2,223
[]mario2 said:
Also there was no clear warning that timeouts were likely and would screw up the database.
[/]

I beg to differ with you.

[]UPGRADING.html
Upgrade instructions are listed in reverse order. So if you keep up with each upgrade, your upgrade instructions will be right at the top. (NOTE: If you have to run an altertable, make sure you only click on it one time and do not hit the stop button during this time. Some altertables will take awhile to finish.


If you can it is always a good idea to back up your SQL database. You can use something like phpMyAdmin for this or from a telnet prompt. The command varies for different SQL servers. MySQL for example would be something like this:

mysqldump databasename > databasename.dump
[/]

[]UPGRADING.html
WARNING: When running some of the altertable scripts your browser may end up timing out. Do not reload/refresh the page. Mysql will still be working and it will continue as normal when it's done.
[/]

[]http://www.infopop.com/support/ubbthreads/UBBThreads_within_licensed_upgrade.html
Backup your database. (Also, if you have installed hacks to certain files, make sure you note the filenames and hacks before upgrading---you can then systematically reapply the hacks after the upgrade.)
[/]

[]http://www.infopop.com/support/ubbthreads/UBBThreads_within_licensed_upgrade.html
Note: For large message boards, these may take some time to run---do not stop them while they are running. Your browser may also “time-out” before the process is complete; don’t worry, the process will continue until it is complete, and you will see a message saying that it is complete.
[/]

While I am indeed sensitive to your complaints and do want to make the upgrading process easier there are, nonetheless, some simple and basic precautions that you need to follow when doing something as drastic as altering your database.

Could the altertable process be better? Oh yes, it could be far better. There's no mistaking the fact that this is chief amoung our concerns as .threads grows in popularity and more and more technically unsophisticated users such as yourself purchase it.





Picture perfect penmanship here.
Joined: Jul 1999
Posts: 118
Enthusiast
Enthusiast
Offline
Joined: Jul 1999
Posts: 118
[:"red"] One more time: I am finished with my problem, if I pick a fight with infopop here, it is out of concern with other customers, out of concern with infopop's quality control. I have nothing to gain from this argument. Only infopo can gain, better instructions, better upgrades, a better product!

If you show me that my understanding of computers is totally out of whack, then I will apologize for my statements
[/]


[]
http://www.infopop.com/support/ubbthreads/UBBThreads_within_licensed_upgrade.html
Note: For large message boards, these may take some time to run---do not stop them while they are running. Your browser may also time-out before the process is complete; don't worry, the process will continue until it is complete, and you will see a message saying that it is complete.
[/]

I have never seen a timed out browser suddenly reviving itself and giving a message. Are you sure about what you are saying?????


I did not stop anything, it did NOT complete. This is NOT true!!!!! Patently wrong!! It got aborted by itself!! Aborted by the web server or operating system, whatever! not by me!!!!!!


Read the boards, there are more people complaining about the same symptoms that I had. Incomplete altertable upgrades!!!!!!! This happens more often, and infopop, incorrectly, thinks it does not happen to people who follow their instructions carefully.


Any webserver times out if it takes 90 minutes to get a reply. Or the browser times out. Or even the internet connection.

And after a webserver timeout the runaway routine should be killed by the operating system or the web server. if that does not happen, then there is a bug in the web server!!

do we have any apache/linux specialist here that can confirm that subprocesses of timed-out web pages get killed????


I even tried the altertable with lynx running on telnet on the database server. Did also time out.


You do not think that those poor people without telnet access (for which you put these web altertables instead of mysql database comands "mysql w3t <altertable") will have privileges to change the web server or process timeout, do you??? that requires root privileges, not just telnet!!


[]Your browser may also time-out before the process is complete; [...] and you will see a message saying that it is complete.
[/]

Yeah right, I waited a few hours in front of a timed out browser. This is the hard way how I learned this: believe me there NEVER will come another message after the message "server cannot be reached". NEVER. Not in all eternity!!!! this is simply NOT true!!!!!


And for the unitiated without any inside knowledge of altertable, there are only two options:

the "back" button or the "reload" button.

The third option would be staring until eternity at an empty page with an error message "server cannot be reached"?? Or do you explain in your instructions what to do in that case?????


The instructions are WRONG! A timeout has consequences that you do not explain in your instructions.

  • there will be no completion message seen on the browser. the url for the next step will never be reached
  • the database upgrade will, most likely, be aborted at an undefined time, and thus leave a "corrupted" database
  • starting over again with the same altertable with a correctly backed up database will lead to the same timeout. It is just a waste of another few hour's time.

    Doing the same thing (run altertable) with the same data (the original backed up database) on the same machine will lead to the same result (timeout and database corruption). Expecting anything else is pure superstition.



These false statements mislead me. I actually thought that the database changes were completed, only that the message did not reach the web server due to timeout. Only much later did I deduce, from interpretation of error messages, that the database change was NOT completed.



[:"purple"]
I can suggest you a scientific experiment.

I will use the backed up database. I set up a board for you. YOU can run the altertable off my web server, I give you the url. And we will see if you manage to complete the database upgrade correctly, using the altertable on a web server!!

Anyone wants to take bets????
[/]

Joined: Nov 2001
Posts: 10,369
I type Like navaho
I type Like navaho
Joined: Nov 2001
Posts: 10,369
I bet Infopop would take that bet for $149 (the price of their upgrade services) as would I for my normal hourly rate.

Joined: Jul 1999
Posts: 118
Enthusiast
Enthusiast
Offline
Joined: Jul 1999
Posts: 118
please could you be specific! which of my statements are wrong?

Please be very specific as to what you would do once you see a browser screen saying "web server not found", at aprox step 2 or 3 of the altertable.

Please use only information contained in the documentation, not secret shortcuts known only to insiders.


Joined: Nov 2001
Posts: 10,369
I type Like navaho
I type Like navaho
Joined: Nov 2001
Posts: 10,369
No secret shortcuts. I simply run the altertables once (ONE AT A TIME ) - in the browser. If it times out I just close the window and let the server do it's thing.

Sometimes, if it's a huge database, I peek at the process list in phpMyAdmin so I can tell when it's finished... but it's not necessary - MySQL will handle all queries thrown at it.

Once the 6.2 altertable got busted down into steps (initially in beta is was one big step) I think it only timed out on me once. When it did I just changed the ?step=6 to ?step=7 in the URL and went on.

That part probably could be clarified more.... but looking at the URL it seemed very logical for me....and timeouts once it was busted down into steps were rare. When I did the very large forum upgrade, the 6.2 altertable did not time out. On my first time through - I did a test upgrade - and it took 4 hours. I was moving it to a new server at the same time, and it turns out MySQL was not properly configured or tuned. We got MySQL properly configured, then the "real" import took a couple of hours. It was over 20,000 users and over half a million posts.

But again - if you are trying to provide cricicism (or constructive criticism) to infopop - why are you telling us? This isn't infopop. No suggestion here is officially tracked, recorded etc... We don't write the software you're posting about.

I figure you are here because you modify your code. If you want to play by the written rules and written instructions:
[]
NOTE: If you modify ANY code within UBB.threads, we at Infopop Corporation cannot offer you support - thus modify at your own peril!
[/]


Just my opinion, but given how you seem to not follow directions well, or even read info here in the forums before posting repeated duplicate questions, I'd question what modifications you've done along the way improperly which may have contributed to your trouble. Likewise if you had the ability to make adjustments/changes to your server configuration, myself, I'd wonder if there might be several different factors complicating things for you.

So when you make those types of adjustments - warned at your own peril, you have to be ready to roll with the punches if other abnormalities pop up along the way.

Like I said - I do alot of upgrades, and 99% of them are point and click that simple, and I'd venture that infopop couldn't charge only $149 for an upgrade if it repeatedly took their support people 8 hours to do and there were complications every time.
I'm sure they find their problems from time to time too. I've had some puzzling things pop up on ugrades, but most of them are related to modifications and such. But most normal upgrades are no problem for me. No tricks either. I did two earlier this week, going to do another one tonight and another one this weekend.

Certinaly making it easier and simplier can be a plus for all involved. Given your track record with directions, I'd highly doubt that giving you queries and stuff to run at a command line level would be a good idea. It would probably lead to complications of record proportion for you.
But that's just my opinion.

Joined: Oct 2000
Posts: 2,223
Veteran
Veteran
Offline
Joined: Oct 2000
Posts: 2,223
"do we have any apache/linux specialist here that can confirm that subprocesses of timed-out web pages get killed????"

They do not. Once the query is issued to MySQL you can close your browser, close down Apache if you want to. MySQL neither knows nor cares.

Let me reiterate again that making the altertable process more foolproof is high on our priority list of concerns.


Picture perfect penmanship here.
Joined: Mar 2000
Posts: 21,079
Likes: 3
I type Like navaho
I type Like navaho
Joined: Mar 2000
Posts: 21,079
Likes: 3
I'll update it for you Mario, just pm me the necessary information. Be sure you have a backup just in case an under-powered/poorly optimized server eats it the first time


- Allen wavey
- What Drives You?
Joined: Jun 2003
Posts: 1,025
Junior Member
Junior Member
Offline
Joined: Jun 2003
Posts: 1,025
Umm, this is kind of off topic but, do you guys think that it is a good idea to optimize tables before you upgrade. It seems to me that it would make the upgrade go more smoothly/take less time. If I'm way off base here, let me know.

Thanks,
Jeff

Joined: Mar 2000
Posts: 21,079
Likes: 3
I type Like navaho
I type Like navaho
Joined: Mar 2000
Posts: 21,079
Likes: 3
Most likely, I try to optomize before upgrading whenever possible


- Allen wavey
- What Drives You?
Joined: Nov 2001
Posts: 10,369
I type Like navaho
I type Like navaho
Joined: Nov 2001
Posts: 10,369
Yes -

Anytime there's an upgrade that involves database steps - Optimizing the tables will usually help it go faster.

Joined: Jul 1999
Posts: 118
Enthusiast
Enthusiast
Offline
Joined: Jul 1999
Posts: 118
from what I understand these messages still clog up the system, filed away under user ID 0 or 1 (who is this? anonymous?)

If I just request to delete all PM older then a week, will that remove these old messages???? Without causing any collateral damage??

Additional question:

someone seems to be hacking the Private messages of other people in our board. This cannot be related, in some way, to this issue? these PM are not reachable in some weird way, like for anonymous users, or whatever??

Joined: Nov 2001
Posts: 10,369
I type Like navaho
I type Like navaho
Joined: Nov 2001
Posts: 10,369
0 is nobody - 1 would be deleted users.

If you purge old PM's it should still purge these.

You could also do an SQL query to remove any with IDs of 0.

Joined: Jun 2003
Posts: 1,025
Junior Member
Junior Member
Offline
Joined: Jun 2003
Posts: 1,025
Remember to backup the database before running the SQL query though...Just in case.


Link Copied to Clipboard
Donate Today!
Donate via PayPal

Donate to UBBDev today to help aid in Operational, Server and Script Maintenance, and Development costs.

Please also see our parent organization VNC Web Services if you're in the need of a new UBB.threads Install or Upgrade, Site/Server Migrations, or Security and Coding Services.
Recommended Hosts
We have personally worked with and recommend the following Web Hosts:
Stable Host
bluehost
InterServer
Visit us on Facebook
Member Spotlight
isaac
isaac
California
Posts: 1,157
Joined: July 2001
Forum Statistics
Forums63
Topics37,573
Posts293,925
Members13,849
Most Online5,166
Sep 15th, 2019
Today's Statistics
Currently Online
Topics Created
Posts Made
Users Online
Birthdays
Top Posters
AllenAyres 21,079
JoshPet 10,369
LK 7,394
Lord Dexter 6,708
Gizmo 5,833
Greg Hard 4,625
Top Posters(30 Days)
Top Likes Received
isaac 82
Gizmo 20
Brett 7
WebGuy 2
Top Likes Received (30 Days)
None yet
The UBB.Developers Network (UBB.Dev/Threads.Dev) is ©2000-2024 VNC Web Services

 
Powered by UBB.threads™ PHP Forum Software 8.0.0
(Preview build 20221218)