Duplicate entry 'Артем' for key 'name' - LINE 170

12
N
На сайте с 06.05.2007
Offline
419
#11

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

С высокой вероятностью индекса уникального нет.

Кнопка вызова админа ()
Mad_Man
На сайте с 10.11.2008
Offline
162
#12

netwind, ещё раз: отцепитесь от своего Vbulletin, речь не о нём. Я понимаю, ничего больше вы произнести не сможете, но всё же попробуйте активировать соображалку: топикстартер спрашивает не только про снятие индекса уникальности, а про смену кодировки поля таблицы. Это приведёт к тому, что часть никнеймов станут идентичными (о чём и сообщает фраза "Duplicate entry") для поиска по строковому равенству (а соответственно по всем JOIN'нам к данному полю) в любой выборке движка, которая опиралась на уникальность никнеймов. Вы не можете советовать снимать индексы уникальности не зная сорцев рассматриваемого движка.

N
На сайте с 06.05.2007
Offline
419
#13

Mad_Man, как это будет работать в конкретном движке - заранее не известно. Почему бы не работать нормально, если на примере vbulletin все работает ?

Как бы это ни казалось странным, два и три одинаковых логина вполне себе работают независимо в vbulletin.

До тех пор пока у них пароли разные:)

Разве не так работает говносайтинг ? Пробуй и получишь счастье.

Люди, которые понимают что им тут в SQL повывалило ошибок, вопросы не задают, а просто смотрят исходники и делают.

Mad_Man
На сайте с 10.11.2008
Offline
162
#14
netwind:
Mad_Man, как это будет работать в конкретном движке - заранее не известно. Почему бы не работать нормально, если на примере vbulletin все работает ?
Как бы это ни казалось странным, два и три одинаковых логина вполне себе работают независимо в vbulletin.
До тех пор пока у них пароли разные:)

Это в корне неправильно советовать так делать топикстартеру, пока он либо не будет уверен в том, что движок написан с поддержкой одинаковых никнеймов, либо пока он точно не поймёт перед этим действием, что последствия могут быть абсолютно любые: от возможности перерегистрировать его админский акк до возможности управления чужим аккаунтом.

netwind:
Разве не так работает говносайтинг ? Пробуй и получишь счастье.
Люди, которые понимают что им тут в SQL повывалило ошибок, вопросы не задают, а просто смотрят исходники и делают.

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

N
На сайте с 06.05.2007
Offline
419
#15
Mad_Man:
последствия могут быть абсолютно любые: от возможности перерегистрировать его админский акк до возможности управления чужим аккаунтом.

Т.е. предлагаете вообще ручки сложить и на каждый чих нанимать Квалифицированного Программиста или Администратора Баз Данных ?

Опомитесь, вы на каком форуме ? Тут так не принято.

Бесчеловечные эксперименты над пользователями, ужасающие удаления Артёмов и Женьков - вот истинное лицо русского говновеба.

Да, я напоминаю ТС, что раз уж в базе изначально был уникальный индекс, то он может и иметь какой-то смысл в данном конкретном движке, а не просто быть для порядка, как во многих других случаях.

Не буду призывать к геноциду пользователей по буквенном признаку, а то припишут статью, но это наиболее надежный вариант.

Вы знаете что делать.

Mad_Man
На сайте с 10.11.2008
Offline
162
#16
netwind:
Т.е. предлагаете вообще ручки сложить и на каждый чих нанимать Квалифицированного Программиста или Администратора Баз Данных ?
Опомитесь, вы на каком форуме ? Тут так не принято.

Я признаю тот факт, что 95% населения после двадцати лет развиваться отказывается. Всё к чему подобные прикасаются остаётся для них за гранью понимания. Более того, есть даже те, кто годами спрашивают на форумах одно и то же, но понимания от этого у них не прибавляется. И я рекомендую для подобных не писать ответы без пояснений о последствиях, не думать вместо них, не делать им курсачи\лабы\что_ещё_они_там_хотят_чужим_трудом, а сделать единственно верное - дать выбор и указать где подробнее ознакомиться с матчастью. Принимать выбор они должны сами. И сами должны своим умом доехать до ситуации и разобраться в ней раз уж они решили задавать вопросы, а не оплачивать труд и время программистов.

Советовать снимать индексы также не стоит по одной простой причине: форум достаточно хорошо индексируется и сюда приходят дети и домохозяйки, которые дальше первого ответа без пояснений не читают, что провоцирует дальнейшие джунгли в головах обывателей и дальнейшие глупые вопросы при появлении проблем из-за своих необдуманных действий.

K
На сайте с 03.06.2015
Offline
45
#17

Остается вопрос как этим всем Артемам удалось записаться в поле с ограничителем по уникальности?

---------- Добавлено 17.06.2015 в 05:50 ----------

А, понял из-за чего две страницы. Ну так все правильно советовали - надо снять уникальный индекс с поля логина, провести все нужные мероприятия и затем вернуть этот уникальный индекс поля логина.

Это стандартный паттерн в дампах бд. То есть структура таблицы и данные таблицы в начале дампа, а определения всех ключей - в конце. Так делается специально чтобы не потерять никаких данных, чтобы прерывание сработало в фазе добавления ключей, а не в фазе добавления данных.

Например если у ТС тридцатьтри Артема в поле логин, то сняв UNIQUE KEY он спокойно может все добавить-отредактировать. Затем сделав попытку добавить UNIQUE KEY он увидит все ли сделано правильно - если да, то ограничитель добавится, а если нет - драйвер разорется что Артемы все еще повторяются.

MYSQL PHP JS HTML CSS SEO TXT США СССР
12

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий