Либо как-то изменить запрос, чтобы не блокировать всю таблицу, но не выдавались одинаковые заявки?
Так самого запроса-то и не видать... поди пойми что там происходит под капотом...
Но если по сути... как я понимаю, в таблице есть некое поле "ответственный", в которое надо вместо NULL (или там нуля) положить ID текущего оператора. Но коли так, то никаких предварительных телодвижений и не нужно. Просто
UPDATE заявки
SET оператор = @current_operator
WHERE оператор IS NULL -- только незарезервированные заявки
ORDER BY дата_заявки ASC LIMIT 1
после чего проверить, что ни с кем не произошло пересечения, а заодно и получить идентификатор заявки
SELECT id_заявки
FROM заявки
WHERE оператор = @current_operator
Возможны варианты:
- вернулся один номер - всё нормально, заявка распределена оператору
- вернулось ноль номеров - кто-то перехватил эту заявку, повторяем резервирование
- вернулось более одного номера или сделано более какого-то числа неуспешных попыток резервирования - что-то не в порядке, зовём администратора задачи
Иван Мельников, я не вижу подробного описания логики происходящего. Только желание зачем-то избавиться от агрегатной функции в её оконном представлении, на практике совершенно бессмысленное.
Или вопрос носит чисто академический характер и не имеет реального практического воплощения?
если хадкорно прописывать, то соответственно они вставляются в конец таблицы.
В таблице в принципе нет понятий "начало/конец/перед/после/выше/ниже/раньше/позже/прочее". Таблица - это куча. Несортированная куча.
Если нужен некий порядок записей - то он обеспечивается в получающем записи запросе с помощью соответствующего выражения в ORDER BY.
Если ORDER BY не задан - записи возвращаются в произвольном порядке. И в двух последовательных получениях этот порядок имеет полное право различаться. Если же задано ORDER BY, но его выражение не обеспечивает уникальности записей, то указанная возможность получения произвольного порядка распространяется на каждую отдельную группу, для которой значение выражения сортировки одинаково.
Что же касается последовательной нумерации в группе - она выполняется программно. Например, триггером на основании дополнительной опорной таблицы.
Если переопределение скорости выполнять так же часто, как мигает светодиод на индикацию трафика, связи не было бы вообще. Autonegotiation требует в среднем около секунды (ну то есть само по себе оно быстрее, но пока пойдут байты, секунда, а то и две, проходит).
Вот в неправильную разводку или некритичный пробой - верю.
Ну сообщение об ошибке же совершенно явно говорит - при попытке подключиться клиент (PHP) не говорит серверу (MySQL), что тот должен запросить пароль учётной записи.
Это то же самое, что и разница между mysql.exe --user=root и mysql.exe --user=root --password
phpmyadmin с пользователем root и пустым паролем не подключается.
Это PHP не подключается.
Проверяйте настройки подключения. Может, MySQL работает только через сокет, а PHP пытается подключаться по IP? или ещё какие несоответствия? файрвол опять же...
PS. Сообщая о проблеме, следует цитировать полученные сообщения об ошибках. Причём полностью, и в неизменном виде.
несколько чатов быть не может, в данном контексте чат = лс
Нынешняя структура таблицы никак не препятствует наличию таких дубликатов. Потому несколько чатов может быть. Возможно, как следствие сбоя либо ошибки, даже если клиентская логика типа против. И возможность наличия/существования таких дублей даже не обсуждается.
Так самого запроса-то и не видать... поди пойми что там происходит под капотом...
Но если по сути... как я понимаю, в таблице есть некое поле "ответственный", в которое надо вместо NULL (или там нуля) положить ID текущего оператора. Но коли так, то никаких предварительных телодвижений и не нужно. Просто
после чего проверить, что ни с кем не произошло пересечения, а заодно и получить идентификатор заявки
Возможны варианты:
- вернулся один номер - всё нормально, заявка распределена оператору
- вернулось ноль номеров - кто-то перехватил эту заявку, повторяем резервирование
- вернулось более одного номера или сделано более какого-то числа неуспешных попыток резервирования - что-то не в порядке, зовём администратора задачи
Такая реализация не должна никого блокировать.