ahyeah, forgot something (might be useful):

trying to add a new forum (over the admin-panel) to the 2.0.3a-board i get the following error:
"Unknown column 'forum_group' in 'field list'. Please, try another name or value."

MySQL said: Documentation
#1060 - Duplicate column name 'topics_count'

If such error appears and the execution stops, it only means you already have the mentioned field and don't need to add it. So you will need to exclude this SQL requests from the generic SQL update list, and continue execution. If the "ignore" statement won't work, you need to execute each and every SQL statement from update list, until you are sure all columns are added. This should be done before you execute convdb.php.

aaaah! :)

i thought the sql-process would still continue, even if an error occurs. now i excluded the requests that produced the duplicate-errors and it works!

thanks for the quick answer! all the best!

I just moved to new host and after exporting database with phpmyadmin into sql file and importing it to new host, all special characters are gone. In Slovenia we are using letters like č and now all this letters have changed to ? (question mark)

I use iso-8859-2 on forum and database was imported in utf-8. Any idea what to do?

tnx

Unfortunately there are very many problems with encoding and this appears the custom issue for us, so we can help only providing paid support. However my advice would be that you need to backup your database properly first, in the proper encoding all records are saved in. If there is cPanel on your old hosting, I would recommend to do a database backup using it's internal tool.

For restoring the database, I recommend to use BigDump: Staggered MySQL Dump Importer tool, which provides outstanding speed and proper results even for large data sets.

phpMyAdmin stinks in the terms of exporting/importing data, so I never use it for such purpose myself.

Thanks Paul!

I tried all this and nothing helped. The problem is, that even when browsing old database i don't see special characters, only some weird characters like 3/4 (small) instead of the proper char. When exporting whole db and importing with bigdump i see no difference.

I think i'm stuck with search and replace. I will change this weird characters with utf-8 codes.

Anybody knows good find&replace program that can work with large amounts of text. I have 20mb db

tnx

I see utf code is translated

I meant this

#382 for Â

It appears that from very beginning you were using improper coding set, so now it would be a hard job to restore all of it. As always I would recommend Notepad2 program which could help you for large files.

I know on many hosting servers there are internal problems with the standard mySQL encoding settings. For example if you run the following statement:

(or for older mySQL versions it could be like this:

)

you must be sure that character_set_server and other same kind variables are set for the same encoding. If some of them differs, this usually causes wrong posting of the characters into DB and displaying them later.

For foreign language symbols I would always recommend to set up the forums in UTF-8 mode. Having UTF-8 you will most likely avoid future problems with such symbols.

I have found a solution for replacing inside database and works fine

update minibbtable_posts set post_text = replace(post_text,'Æ','#268;')

The problem now is that special characters are not displayed properly when posting a message. I can only see š and ž all others are displayed as question mark.

I have tried changing language file from iso-8859-2 to utf-8 but that's even worse, since non of this characters are showing.

tnx

Found the problem!

Collation was set to latin1_swedish_ci. After changing to utf8_unicode_ci i could again post all special characters.

I will replace "again" all utf8 code with proper characters and hopefully all should be OK.

Any comment on this solution?

Thanks Paul

Such problems are always specific... my only comment would be: if it works, congratulations!

Two questions:

I just downloaded the latest version of minibb and updated from 2.0.5 to 2.1c. I read through the !update.txt and replaced the files that had changed and uploaded them to my site. Ran the mysql command to drop the columns from the two tables. Everything seems fine. Only thing I'm confused about is adding the versioning to the admin panel ({$version}). It still says 2.0.5. What might I be missing so that it would read 2.1c?

Also in the !update.txt file, under setup_options.php, it says that $useSessions option has been eliminated, but it's still there. And it mentions $emailCharset, which I can't find in setup_options.php. The date on the setup_options.php file is May 24, 2007, which sounds like it's too old.

Any advice appreciated!

harootun wrote: It still says 2.0.5. What might I be missing so that it would read 2.1c?

I believe you are missing the latest bb_functions.php available in the miniBB forum 2.1 package.

harootun wrote: Also in the !update.txt file, under setup_options.php, it says that $useSessions option has been eliminated, but it's still there.

I think it is safe to just remove $useSessions from your copy of setup_options.php yourself.

harootun wrote: And it mentions $emailCharset, which I can't find in setup_options.php.

Just add it to your setup_options.php.

harootun wrote: The date on the setup_options.php file is May 24, 2007, which sounds like it's too old.

Wow, it does sound old! Let's wait for an official response from Paul/Team on this one.

All the best,
mb

Marsbar,

Thanks for the first tip. I must have forgotten to upload bb_functions.php to the site. It did the trick!

In terms of the rest, eager to see what Paul/Team have to say.

Thanks again.

I would only accept what marsbar wrote already.

$useSessions was eliminated from the core files. I think it is still kept in the setup_options.php because we have forgotten to remove it :-) Will be done in the next release.

$emailCharset is not a mandatory option and it's not included in setup_options.php by default (as few other options as well). So it is not needed to put it there if you don't have problems with emails encoding.