OK. I dropped all my tables and did a fresh reinstallation. I then restored all my tables. When I then went to the blog url, I got the following message:

This is b2evolution version 0.9.1.

You cannot use the application before you finish configuration and installation.
Database schema is not up to date. You have schema version 8064, but we would need 8066.

Please use the installer to finish your configuration/installation now.

On most installations, the installer will probably be either here or here... (but I can't be sure since I have no config info available! :P)

Does this mean that the version of Mysql which my ISP uses will not work with b2 version 0.9.1?

You still need to upgrade your tables, goto the install page and choose upgrade and see if it works this time.

¥

Hi ¥åßßå,

I have already tried that. The first error msg that I posted was the result of my attempted upgrade. I only tried a fresh installation because I thought that would sort it out. I tried to upgrade from the fresh installation as well, and got the same error msg as the first one posted.

and you sure that the username, password, databasename and databse server in your config is correct?

¥

Absolutely 100% sure. I just tried using an incorrect username - it gives you a different error msg.

I have now ascertained that this has been an issue with version 0.9.1b. I installed 0.9.0.12 again like a breeze. I guess I had better raise this with the developers.

Regards

whittler

Absolutely 100% sure.

I was fairly sure that you would be sure, but I had to be sure :p

I'm afraid I'm now clueless as to what's causing your error.

¥

Upgrade to Dawn went smooth for me.
Could you verify once more that your _config.php file has the correct credentials to access the database? Can you just copy the _config.php over from the existing working install of 0.9.0.12?

Sorry - I know you already said you are 100% sure, but the only thing that comes to mind in relation to that error message you're seeing is this. (How about 101% sure? ;) )

I think, but I'm not sure, that the problem is due to a partially upgraded database. Here's the deal. When you tell b2evolution you are upgrading it checks the schema to determine what it needs to do in order to bring you up to the latest version. In the screen shot you provided b2evolution has decided since your schema is 8064 it needs to alter the evo_posts table, but is obviously having a problem doing that. It therefore dies. Now nothing exists to undo the steps it completed, and therefore will never be able to go through it's full process.

Question: did you ever use any of the hacks that indexed different fields in your database? There are a few of them out there, usually geared towards speed but other things too. Have you done anything in the past to your database that would have made it slightly different from a plain installation, especially with regard to actual existing tables or fields? I don't mean adding your own table, but it might be adding a field to an existing table. SOMETHING that could cause b2evolution to think "the database must be X so I'll do Y", but it can't because you did your own Y in the past.

captsolo: 100% sure. I have these details in a separate text file which I copy and paste whenever I upgrade/reinstall.

EdB: I have only done very few hacks and none of them touch the db e.g. I changed a couple of renderers from opt-out to opt-in; and on the edit tab, I unticked a few items (so you had to tick draft etc when performing searches).

The only thing that I have done with the db is delete entries for the hitlog table. I used an sql command which I found on this forum. All it did was delete entries from one date to another.

The weird thing is, a re-installation of 0.9.0.12 worked fine. It was clean in so far as I used the original b2 files to run the installation - but kept the existing db.

Cool, not that not upgrading is cool, but I understand more now.

The thing is I seem to remember other users getting stuck half-way through an upgrade or installation, then every future attempt to do the deed would fail because of the difference between schema and what the d-base was supposed to look be like.

Oh a reinstall would work fine because it's not trying to do anything special, especially if the schema matches. It won't care if it's not exactly what it thinks - only that the schema is the number it likes. Especially if you install v12 then replace your d-base with a backup, which is slightly different than upgrading.

Let me think about this a bit. In the meantime, do you have a full backup of your existing database? If so are you capable of dropping all your tables and doing a "brand new" install of dawn? If so we can try to restore your backup and tweak it the way the installer wants, but one step at a time - and only if you have a full backup of your current site ready to revert to.

EdB

I have a full backup of my tables.

I have now dropped them all and was able to do a successful clean installation of dawn.

I am ready for further instructions if you have some ideas.

Yeah, no problem. Lemme finally do what I said I was going to do... In the meantime grab a copy of your new conf/_config file so you have your groovy database info. What we will try to do is rename your existing backup file to match what you would get if you did a backup of the new installation, then restore the freshly renamed file. Follow me? We're going to trick the new installation into thinking it's got tons of old stuff in it, but I anticipate a problem or ten.

The problems, if any, will come about because your old database seems to be stuck in a twilight zone between the old way and the new way.

What format is your backup in? When I use cpanel backup utility I get a .gz file named after my databasae. If I use phpmyadmin "export" I get a .sql file named after the database or specific table. I found it much easier to use my cpanel backup utility because the same utility lets me restore from the .gz format.

Just to verify: you used to have a happy 0.9.0.12 and want to have a shiny happy 0.9.1 - correct? I'm going to try to figure out the exact differences between the database structures so we can manually force your old one to be like the new way AFTER you restore your old one on top of your new one.

Oh and if you're feeling brave go ahead and make another copy of your backup only give it the name it would have if you backed up your new installation, then do a restore. Ain't gonna be no worse than where you are now eh?

I don't follow you 100%. Firstly, I have grabbed the new _config - no probs.

I use phpmyadmin to export, and I did each table individually - so there are 12 sql files each entitled whittlingwood-1.sql ... whittlingwood-12.sql

Correct - I would like to upgrade to 0.9.1.

I'm not sure what you meant by renaming the files in your last paragraph. What name should I change them to before restoring? Normally I just restore using phpmyadmin.

Never mind the renaming, since your backup came from exporting. The only way I can use exports to restore is to one-by-one copy and paste first the piece that makes the table then the actual content stuff into the "Run SQL query/queries on database" section after I select a specific table in the database. If you have knowledge of a method to restore from an exported backup then by all means go for it! What we want is your files to talk to this database with the old content, then to figure out how to tweak the restored database to be like a dawn installation expects.

I recently exported my hitlogs table to tinker on a project. The project failed, but I can use the .sql file as an example. This is what I see when I open that file in my favorite editor:

-- phpMyAdmin SQL Dump
-- version 2.6.3-pl1
-- http://www.phpmyadmin.net
-- 
-- Host: localhost
-- Generation Time: Sep 26, 2005 at 11:41 AM
-- Server version: 4.0.25
-- PHP Version: 4.3.11
-- 
-- Database: `wonderw_bvlt1`
-- 

-- --------------------------------------------------------

-- 
-- Table structure for table `evo_hitlog`
-- 

CREATE TABLE `evo_hitlog` (
  `visitID` bigint(11) NOT NULL auto_increment,
  `visitTime` timestamp(14) NOT NULL,
  `visitURL` varchar(250) default NULL,
  `hit_ignore` enum('no','invalid','badchar','blacklist','rss','robot','search') NOT NULL default 'no',
  `referingURL` varchar(250) default NULL,
  `baseDomain` varchar(250) default NULL,
  `hit_blog_ID` int(11) NOT NULL default '0',
  `hit_remote_addr` varchar(40) default NULL,
  `hit_user_agent` varchar(250) default NULL,
  `hit_post_ID` int(10) unsigned NOT NULL default '0',
  PRIMARY KEY  (`visitID`),
  KEY `hit_ignore` (`hit_ignore`),
  KEY `baseDomain` (`baseDomain`),
  KEY `hit_blog_ID` (`hit_blog_ID`),
  KEY `hit_user_agent` (`hit_user_agent`)
) TYPE=MyISAM PACK_KEYS=0;

-- 
-- Dumping data for table `evo_hitlog`
-- 

INSERT INTO `evo_hitlog` VALUES ( *all the actual guts of this particular hitlog entry* );

The "insert into" line is repeated for each entry in that table. The lines that start with -- are comments, and those are the lines I'm afraid to paste into the SQL box, thus the reason I do it in two steps per table. Therefore what I would do if I was you is first select my new database in phpmyadmin then select the SQL option across the top, then paste in the first part (create table) and second part (insert into, many times) into the SQL box for the 12 tables that makes b2evo run.

The two tables you will need to give special consideration to are evo_postcats and evo_hitlogs. As you noticed, it is something about postcats that's killing your upgradability. postcats and hitlog are the only tables altered by upgrading to dawn, so those are the ones we need to tinker with.

When I select my database then click on my table name I get to the table structure view, and that is where you want to be. In structure view I see a section that says "Indexes" and offers a little table with 4 columns: Keyname, Type, Cardinality, Action, and Field. My v12 and dawn installation both have the same exact info on a row beginning with PRIMARY. My dawn installation has a new Keyname called catpost. All the data on that row is: catpost, UNIQUE, 98, (edit image delete image), and postcat_cat_ID & postcat_post_ID. This might be why you can't upgrade, and what we will need to make happen in order to fake upgrading.

Next you want to look at the structure for the hitlog table. When I compare my two installations I only see one difference in this table: again it is a new row with the following information: visitTime, INDEX, 1384, (edit image delete image), and visitTime. I have no clue what these things mean, but these are the things we need to make your restored tables have so that they will be like dawn tables.

One POSSIBLE solution is to simply delete these things that might exist in your restored tables so that your tables match what a regular v12 table would be. That might get you to a point where running your_domain/install can actually function. Another POSSIBLE solution will be to craft the SQL statements that the install routine would build, effectively performing a manual upgrade. Lemme know where you're at and which way you feel good with going, and we'll see what happens next.

You're close! You're in a bad place, but you're close to getting back to regular blogging!

Rats! Normally I check the box that gives me something like "if exist drop the table then make a new table". Depending on how your export is you might have to drop all your tables before using SQL to rebuild them all.

The problem is, after I drop all the tables, those new bits from the dawn tables won't be in the restored tables (i.e. new Keyname called catpost etc) as they will have been dropped.

How do I incorporate those bits into the old tables?

Simple. Whichever bits that should be in dawn and happen to be in your v12 you can delete. After that your installer should be able to do it's thing. Alternatively, whichever bits that belong in dawn but aren't there you can just put there, then manually edit your schema value.

I like the first method better: making your v12 database really be like a v12 database then letting the installer do it's thing, however I've never done it so it's best to keep a couple of options available and in mind.

I don't really know enough about databases to do what you have suggested. All I know how to do is export sql files and then restore them again using the "locate file" browse feature on the sql tab of phpmyadmin.

So I don't know how to take elements from one table and incorporate them into another. Is this something that can be easily explained?

Yup. Check out phpmyadmin and select any of your databases. Since I have a few of them I get a dropdown box, but if you only have one this is a redundant step. Anyway select a database, then in the left-hand side select a table name. Now the right hand side fills up with stuff about that table. Take a look at it and you will see all sorts of groovy stuff about that table in that database. You will be on the structure view by the way, but you can verify that by clicking 'structure' on the tabs across the top of the right side. Check out the page and you will find a block that calls itself "Indexes". That is the only block you need to fix - as detailed above.

Bottom line is this: with your new files and old database we have a problem with at least one table. We can fix that problem, but only if you get the old database contents into the database that your new files want to connect to. Therefore if you restore EVERYTHING exactly as it was to the database that your new conf/_config file mentions you'll be able to 'fix' the problem and use dawn.

When you have your old database contents imported into your new database and see the structure of one of the tables it'll make more sense. I would do a screenshot, but it's not easy for me. I don't allow hot-linking, so I would have to build a little page for it.

Ed,

I did another fresh installation of dawn, with new tables (after dropping them all again previously). I opened it up in phpmyadmin.

Then I opened up phpmyadmin on my local machine which has a backup of my whole blog sitting on an apache server. I looked at both new and old next to each other.

The indexes (except for the cardinality figure) was the same for every table.

I have a suggestion - what if I backed up the data, but not structure, of each table. Then deleted the contents of each table. Then run a fresh installation and insert the backed up data into each table. Old data - new structure. Do you think this would work? I would have to figure out how to do the insert, but the export should be easy.

A further point - when logged in to phpmyadmin, when I tried to drop the line UNIQUE etc. (postcat_cat_ID, postcat_post_ID ) from the indexes "table" of the table evo_postcats, i got the same msg as the b2installer - Access denied for user: 'whittlingwood@localhost' to database 'whittlingwood'

Why would I be denied access when I am logged in?! I am baffled.

I am having the same problem with my local installation, so the problem is not isolated to the server of my ISP.

I'm confused. If your tables match exactly in your v12 backup and your dawn installation then there is no reason for dawn not to run, and you can see that dawn can run - just not with your old database. If this is a correct assessment then the problem has to be with your original database.

Did you try emptying the tables in a new dawn database and importing only the old content? If not I'd say go for it. Maybe move things up slowly and see if you can isolate to a specific table. For example forget about hitlog till the very end. Also save posts and postcats and comments for right before hitlog.

EdB

I've done it! Just need to run it online now.

I have now done extensive testing and ascertained the problem table.

But first, I did insert old data into the new table structure and that did not work. And also, I made an error, the indexes on those two tables were in fact different.

BUT - I have discovered that the troublesome table is evo_settings. On my local machine, I upgraded every table in sequence on a clean installation and the blog still functioned with every table upgraded except evo_settings. As soon as I upgrade that table, it all goes pear-shaped.

The first INSERT line in my evo_settings sql file is :

INSERT INTO evo_settings VALUES ('db_version', '8064');

All that I needed to do to get it to work was substitute 8064 with 8066, and away I went. Makes sense in light of the initial error msg as well.

Thanks for taking the time to help me out on this one. I really do appreciate it.

Regards
whittler

Whew!

I've tried helping 3 "can't get the upgrade to work" problems in a row, and so far the only reason the first two have gotten resolved is because the owner of the problem found the solution. In my mind I'm taking a bit of credit on both. Hope you don't mind ;)

Absolutely. Bouncing ideas off each other was what got me on the right track.

Thanks again.

I'm getting the same error.

I installed b2evo using the script library on my server (laziness! I know how) and then later I clicked to update it and... It gave me that error.

You'd think that their own script library would work with their own friggin' database.

Anyway, I made a full backup just about an hour before but adding to the awful, awful support I get there, they've disabled allowing me to restore the backup myself (I'm FINE going back to Amster and jsut staying there... as long as I have my blog back!) and require them to do it. After an email to them they're suggestion was for me to install a blank new b2evo on a new database for a fresh new blog.

Umm...

So anyway, how would you guys suggest I get this error message away and go back to the old ways. To me, as long as it works, I'm fine.