Здравствуйте.

Начну с предыстории.

Был форум на phpbb 3.x. Решили переехать на ipb 3.2..

Собственно переехали, с помощью офф. конвертера перенесли все темы и всех пользователей т.д., вобщем все было ок.

Потом хотел форум обновить до версии 3.3, но всплыла проблема с БД, а точнее с кодировкой..

Данные в таблицах и сами таблицы в utf, а кодировка соединения в latin1.

В БД была сплошная абракадабра, однако форум читал все нормально.. До обновления.. После обновления, абракадабра переехала на страницы форума..

Решил поступить следующим образом:

- Поправить кодировку средствами dumper'а

- Установить новый 3.3*

- И переконвертировать исправленную БД с 3.2 под 3.3

*Исправленную БД, подружить с действующим форумом v.3.2 никак не получалось.

Все хорошо, за исключением одного момента, вместо 3500+ пользователей, стало 400+...

Конвертер, после конвертации пользователей, отрапортовал следующее:

The following errors occurred:

2002: No password provided

2003: No password provided

2005: No password provided

2006: No password provided

2007: No password provided

2008: No password provided

2009: No password provided

......

3084: No password provided

Можете ли что нибудь посоветовать?

p/s Все манипуляции проводились на Тестовом сайте.

Это проблема не с конвертером, раз все было на месте.

Я так понял, после конвертирования БД Sypex Dumper'ом пользователи исчезли?

а 400 пользователей стало по статистике форума или в БД? как выглядит форум с этими 400 пользователями, их аватарки, сообщения есть? ? Что с сообщениями пользователей которых нет в БД или форуме? Пересчет пользователей делали?

Это проблема не с конвертером, раз все было на месте.

Я так понял, после конвертирования БД Sypex Dumper'ом пользователи исчезли?

Пользователи не исчезли. IP Converter их "видел".

Local Rows 453

Source Rows 3228

Видел, но не перенес. Стоит отметить что все остальное (темы, посты, статусы, лс (тех пользователей что перенеслись), аттачи и т.д) перенес без ошибок. Возможно тут замешан Dumper, но даже не знаю как проверить.

Вообщем что имеем:

1. БД в плачевном состоянии. Которую форум (3.2) читает нормально, а после обновления до 3.3 - кракозябры

2. Исправлял кодировку по инструкции на сайте самого dumper'а

__sypex.net/encoding/

3. Проверил наличие пользователей в БД после исправления - все на месте =_=

После конвертирования в 3.3 - большая часть пропала (phpmyadmin, таблица members - 16 страниц, когда было 108).

Возможно какая нибудь предварительная настройка поможет конвертеру их "переварить"..

а 400 пользователей стало по статистике форума или в БД? как выглядит форум с этими 400 пользователями, их аватарки, сообщения есть? ? Что с сообщениями пользователей которых нет в БД или форуме? Пересчет пользователей делали?

И по статистике и в БД. Сообщения есть, темы есть, имя прописано как Гость-* (именно так, не маска, а именно Гость-*). Скрин сделать к сожалению не могу. Все пересчеты делал (естественно о_О).

Ну что ребят. Идей нет никаких?

Скажи мне пожалуйста, каким <censored> IP.Convert тебе хеши паролей юзеров сконвертирует?

На phpbb у тебя был один метод хеширования, а на IPB уже другой, следовательно конвертация невозможна.

Сейчас у тебя только один выход и он возможен, только если ты делаешь бекапы БД.

1. Пишешь на PHP скрипт конвертации юзеров таблицы phpbb в таблицу IPB.

2. Конвертируешь.

3. Меняешь метод хеширования пароля в PHP скрипте своего форума в регистрации, логине и восстановлении пароля на тот, что у тебя был на phpbb (только ты можешь знать какой).

4. Тестишь всё это дело, если работает, то ты молодец, если же нет, то рой скрипт конвертации.

Оригинальный метод шифрования в IPB:

$cryptPass = md5(md5(<соль>).md5(<пароль>));

Пароль и соль:

Таблица members > поле memders_pass_hash и поле memders_pass_salt

Соль генерируется рандомно при регистрации юзеров и при проверке пароля юзера берется из таблицы.

На счет кодировки, вы перешли с английской версии IPB 3.2 на русскую версию IPB 3.3, а у них разные кодировки.

Вам достаточно заставить русский форум читать БД в формате ISO-8859-1, а не в UTF-8.

Так.. Вот не понимаю.

Конвертация phpbb > ipb 3.2 - все гладко.

А конвертация ipb 3.2 > ipb 3.3 - fail..

Уххх... умел бы я скрипты писать то наверно тут ничего не спрашивал...

А переходим в русской ipb 3.2 на русскую ipb 3.3

В любом же случае нужно базу поправлять, что бы в ней кракозябр не было. Не вижу смысла пытаться заставлять форум их читать.

Конвертация phpbb > ipb 3.2 - все гладко.

Это ложь. Я уже писал, что это НЕВОЗМОЖНО.

Это ложь. Я уже писал, что это НЕВОЗМОЖНО.

Вы ошибаетесь.. Стандартный конвертер перенес всех пользователей (в том числе их пароли), все темы и все сообщения.

Вопрос однако не в этом. Вопрос в том, почему он не может перенести пользователей (и только пользователей, все остальное перенес хорошо) с ipb 3.2 на ipb 3.3...

Да и черт бы с этими паролями, по почте все восстановят.. Возможно скажу глупость, если всплывают ошибки связанные с паролями, может вообще очистить соответствующие поля в БД? =_=

Вопрос в том, почему он не может перенести пользователей (и только пользователей, все остальное перенес хорошо) с ipb 3.2 на ipb 3.3...

Кто он?

Вы случайно не конвертером обновляетесь с 3.2 до 3.3 ?

Это ложь. Я уже писал, что это НЕВОЗМОЖНО.

IPS

Выберите там phpBB 3.x и посмотрите, что возможно, а что нет.

Вы случайно не конвертером обновляетесь с 3.2 до 3.3 ?

Не то чтобы обновляюсь.. Именно обновится не получилось. Конвертером адаптирую БД от 3.2 к форуму 3.3.

Все отлично, но с пользователями косяк :'(

Попробуй отдельно залить таблицу пользователей от других таблиц форумного БД.

Попробуй отдельно залить таблицу пользователей от других таблиц форумного БД.

Пробовал.. Форум ошибку выдает и посылает к администратору.

Так, давайте разберемся.

У вас есть работающий IPB 3.2, все нормально, все цело.

Вы хотите поставить IPB 3.3, но у вас появляются проблемы с кодировкой, так?

Так, давайте разберемся.

У вас есть работающий IPB 3.2, все нормально, все цело.

Вы хотите поставить IPB 3.3, но у вас появляются проблемы с кодировкой, так?

Да.. Есть работающий IPB 3.2, работает нормально. Однако имеются проблемы с кодировкой в БД, в самой бд крякозябры (выше по теме приводил скрин БД из phpmyadmin), но форуме все ок.

После обновления до IPB 3.3, крякозябры возникают на форуме.

Исправлял кодировку средствами Dumper'а. БД с исправленной кодировкой, форумы (что 3,2 что 3,3) работать отказываются.. Прописывал кодировку в .htaccess, и в конфиге форума (следуя различным советам при проблемах с кодировкой).. Безрезультатно.

Да.. Есть работающий IPB 3.2, работает нормально. Однако имеются проблемы с кодировкой в БД, в самой бд крякозябры (выше по теме приводил скрин БД из phpmyadmin), но форуме все ок.

После обновления до IPB 3.3, крякозябры возникают на форуме.

Исправлял кодировку средствами Dumper'а. БД с исправленной кодировкой, форумы (что 3,2 что 3,3) работать отказываются.. Прописывал кодировку в .htaccess, и в конфиге форума (следуя различным советам при проблемах с кодировкой).. Безрезультатно.

Попробуйте написать хостеру, что не меняется кодировка соединения с MySQL и что это говорит о серьезных проблемах в настройке сервера Базы Данных.

Посмотри свои значения, у тебя должно быть так:

Вот что у меня.... мда...

character_set_client			latin1

character_set_connection	        latin1

character_set_database			utf8

character_set_results			latin1

character_set_server			latin1

character_set_system			utf8

collation_connection			latin1_swedish_ci

collation_database			utf8_general_ci

collation_server			latin1_swedish_ci

Значит из за этого исправленную БД не принимает?.. Пишет:

Your settings could not be read by IP.Board. This is a fatal error and IP.Board cannot function while this issue persists.

This issue is generally caused by changing your character set in the ACP to one that does not support data stored in the rest of your settings, or by restoring a database backup/completing a server transfer and importing your database tables using the wrong character set or collation. You should contact IPS Technical Support for further assistance.

Как эти значения исправить?

Попробуйте написать хостеру, что не меняется кодировка соединения с MySQL и что это говорит о серьезных проблемах в настройке сервера Базы Данных.

Хостинг VDS.. Предустановленное ПО:

FreeBSD-8-ISPmanager

Apache 2.2

MySQL 5

PHP 5

Perl

(+еще много чего)

Что в БД может быть не так настроено... Щаc настроим +_+

Для начала необходимо все таблицы привести в сравнение с генералом, далее уже пропускать их например через Sypex Dumper. Я использую Sypex Dumper 2.0.9.

Вот пхпшечка, которую необходимо скинуть в корень нужного форума. Назовем ее php.php

<?php

$db = mysql_connect('localhost','myuser_mydbuser','mypassword');

if(!$db) echo "Cannot connect to the database - incorrect details";

mysql_select_db('myuser_mydbname'); $result=mysql_query('show tables');

while($tables = mysql_fetch_array($result)) {

foreach ($tables as $key => $value) {

mysql_query("ALTER TABLE $value COLLATE utf8_general_ci");

}}

echo "The collation of your database has been successfully changed!";

?>

Надеюсь не нужно говорить про изменение myuser_mydbuser, mypassword и т.д., на свои значения.

Если сравнение прошло успешно, то должна появиться надпись: The collation of your database has been successfully changed! (Операция по сравнению может занять от нескольких секунд до нескольких минут. Зависит от размера таблиц).

Далее необходимо пройтись по адресу http://сайт.ru/php.php

Как это будет сделано, нужно установить Sypex Dumper 2.0.9., например в папку dump на форуме. Во вкладке экспорт указать дефолтную кодировку, отметить необходимые таблицы для экспорта и собственно экспортнуть их (без сжатия). Во вкладке Импорт, выставить кодировку utf-8, выбрать коррекция кодировки и импортировать дамп.

Если все сделано правильно, таблицы должны быть в правильной кодировке и отображать русские символы.

P.S. Вот это просто самое важное, делайте всегда перед какими-либо сложными операциями бекап бд, над которой вы работаете. Потому, что испортить легко, а восстановить тяжело.

Вполне возможно, что перекодировать не удастся, будут например знаки ????? место русских букв, тогда пиши сюда, будем разбираться дальше.

Скоро создам тему на форуме с информацией по пользованию программой Sypex Dumper, возможно кому будет интересно.

Так, если у вас стоит сам сервер MySQL и можете его самостоятельно настроить это лучше.

Google. Там по самой первой ссылке смотрите, только вместо

cp1251 

подставляйте

ut8_general_ci[/code]
.

Если не получится, то все равно смотрите в этом направлении.

Doogle

Спасибо за совет, однако вопрос не в этом.

Как исправить кодировку в самой таблицы я уже в курсе.

А трабла в том что ipb 3.2 ее не читает..

То есть вот новая БД, Collation - utf8_general_ci; все содержимое таблиц так же в utf8, киррилица читается, косяков нет.

Кодировку в таблице исправлял тоже через Dumper, экспортировал в latin1, импортировал в utf8 с коррекцией.

Но форум ее, читать не хочет.. Что действующий, что копия на денвере.. Одно и тоже:

FATAL ERROR

Your settings could not be read by IP.Board. This is a fatal error and IP.Board cannot function while this issue persists.

This issue is generally caused by changing your character set in the ACP to one that does not support data stored in the rest of your settings, or by restoring a database backup/completing a server transfer and importing your database tables using the wrong character set or collation. You should contact IPS Technical Support for further assistance.

Насколько я понял, форум настроен на работу с БД в latin1.. Как его перенастроить на БД в utf8?...

Сделай все так, как я написал выше. Вопрос, зачем ты импортировал в кодировке latin1?

Откройте файл conf_global.php и посмотрите, что у вас там в

$INFO['sql_charset'][/CODE]

Сделай все так, как я написал выше. Вопрос, зачем ты импортировал в кодировке latin1?

Экспортировал в latin1.. Извините ошибся при написании.. Исправил..

Откройте файл conf_global.php и посмотрите, что у вас там в

$INFO['sql_charset'][/CODE]

Там пусто..

$INFO['sql_charset'] = '';

Ставил там ut8_general_ci.. Менялся текст ошибки.

Вместо

[size=2]Your settings could not be read by IP.Board. This is a fatal error and IP.Board cannot function while this issue persists.[/size]

[size=2]This issue is generally caused by changing your character set in the ACP to one that does not support data stored in the rest of your settings, or by restoring a database backup/completing a server transfer and importing your database tables using the wrong character set or collation. You should contact IPS Technical Support for further assistance.[/size]

Выдавал

[size=2]There appears to be an error with the database.[/size]

[size=2]If you are seeing this page, it means there was a problem communicating with our database. Sometimes this error is temporary and will go away when you refresh the page. Sometimes the error will need to be fixed by an administrator before the site will become accessible again.

You can try to refresh the page by clicking here[/size]