После того как я попросил хостера изменить переменную character-set с latin1 на cp1251 он очень долго говорил о том что нужно перекодировать всю базу (может он и делал что-то на эту тему) а когда что-то сделал получилось следующее:

mySQL query error: INSERT INTO ibf_posts (author_id,use_sig,use_emo,ip_address,post_date,ic
on_id,post,author_name,forum_id,topic_id,queued,at
tach_id,attach_hits,attach_type,attach_file) VALUES ('1','1','1','мой IP','1101161477','0',' 123 ','Admin','13','14','0','','','','')

mySQL error: Duplicate entry '315' for key 1
mySQL error code:
Date: Tuesday 23rd of November 2004 01:11:17 AM

я смотрел саму таблицу, 315 запись есть и она последняя.
Так происходит при добавлении строк в некоторые другие таблицы (после работы хостера). И ситуация с последней строкой та же.

Помогите пожалуйста решить проблему.

СУВ.
ЗЫ. Переменную хостер таки поменял.

Цитата(PILOT @ 23.11.2004, 01:12)

Так происходит при добавлении строк в некоторые другие таблицы (после работы хостера). И ситуация с последней строкой та же.

1. Нужно проверить остался ли аттрибут auto_increment на столбце с первичным ключом нга этих таблицах. Если нет - проставить.
2. создать тестовую таблицу с автоинкрементным полем и вставить несколько строк, если нормально, то снять дамп базы и восстановить (этот вариант маловероятен).

Если же не помогло, то нужно объяснить хостеру, что у него автоинкремент теперь криво работает и заставить исправить.

сделай DESC ibf_posts; и запости сюда ответ сервера!! Может правда с автоинкрементом косяк...

Цитата(GoodBoy @ 23.11.2004, 11:41)

DESC ibf_posts;

Я и не знал, что у DECSRIBE есть синоним

Вот ответ сервера на DESC ibf_posts:

Field Type Null Key Default Extra
pid int(10) PRI NULL auto_increment
append_edit tinyint(1) YES 0
edit_time int(10) YES NULL
author_id mediumint(8) MUL 0
author_name varchar(32) YES NULL
use_sig tinyint(1) 0
use_emo tinyint(1) 0
ip_address varchar(16)
post_date int(10) YES NULL
icon_id smallint(3) YES NULL
post text YES MUL NULL
queued tinyint(1) YES NULL
topic_id int(10) MUL 0
forum_id smallint(5) MUL 0
attach_id varchar(64) YES NULL
attach_hits int(10) YES NULL
attach_type varchar(128) YES NULL
attach_file varchar(255) YES NULL
post_title varchar(255) YES NULL
new_topic tinyint(1) YES 0
edit_name varchar(255) YES NULL

Цитата(PILOT @ 23.11.2004, 12:28)

pid int(10) PRI NULL auto_increment

Интересно, почему не NOT NULL...
Автоикремент на месте. Все вопросы к хостеру.

Цитата(Ignat @ 23.11.2004, 12:33)

Интересно, почему не NOT NULL

Это нормально!!!

Код

desc philiales; +--------+-----------------+------+-----+---------+----------------+ | Field  | Type            | Null | Key | Default | Extra          | +--------+-----------------+------+-----+---------+----------------+ | id     | int(4) unsigned |      | PRI | NULL    | auto_increment | | name   | varchar(50)     |      |     |         |                | | hidden | int(1) unsigned |      |     | 0       |                | +--------+-----------------+------+-----+---------+----------------+

Цитата(GoodBoy @ 23.11.2004, 13:11)

Это нормально!!!

Для первичного ключа логично ставить NOT NULL, ведь там пустого значения по определению быть не может.

Ставь, не ставь - все равно получешь NULL в поле Default... :-))))))) Проверено!

Цитата(GoodBoy @ 23.11.2004, 14:43)

Проверено!

Угу... Уже проверил.

я вот например предыдущую запись удаляю, и форум схватывает одно сообщение, а последующие опять нет.
Народ, а если я кому-нить из вас дам доступ к базе? посмотрите?

СУВ.

Цитата(PILOT @ 23.11.2004, 18:08)

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

Логично, индекс-то сохраняется.

Цитата(PILOT @ 23.11.2004, 18:08)

Народ, а если я кому-нить из вас дам доступ к базе? посмотрите?

Посмотреть можно, но думаю ничего нового не увидим, разве что диагноз хостеру поставим (не его базе, а именно хостеру).

Я исправил.

Значит создал дамп проблемных таблиц.
Создал их копии с помощью дампов, и заменил ими проблемные таблицы.
Пока никаких вопросов, кроме одного: что было то?

СУВ.

возможно просто был какой-то сбой... а ты пересоздал таблицы и всё исправилось...

Цитата(PILOT @ 23.11.2004, 23:20)

что было то?

Может проблема была в файле с данными, а при удалении тыблицы удаляется файл.

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

СУВ.

Цитата(PILOT @ 25.11.2004, 01:24)

я не удалял старые таблицы... я их переименовал

и соответственно получил новые файлы с этими таблицами!!! А при повторном создании исходных таблиц заново создались и файлы в которых они лежат!!! И если было нарушение целостности файлов, то при пересоздании таблиц эта ошибка была исправлена...

А вообще попробуй почитать вот это: http://dev.mysql.com/doc/mysql/ru/Disaster_Prevention.html
и особенно проверить вот это: http://dev.mysql.com/doc/mysql/ru/REPAIR_TABLE.html