Не работает сортировка ORDER BY
Не сортирует конструкция order by языка MYSQL.
Вот какой запрос пишу:
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Не работает сортировка по ORDER BY
Всем доброго времени, суток, мне нужно сделать, чтобы данные из таблицы БД выводились в обратном.
Добрый день , создал форму, добавил все что надо, вот собственно код . void __fastcall.
двойная сортировка в ORDER BY
Есть SQL-запрос к базе на выборку по двум полям, в первом выбирается несколько конкретных записей и.
kilogram, Обратите внимание. Числа — синие и выровнены направо. Строки — зеленые и выровнены налево.
Строки сортируются по алфавиту. «1» 1
А как тогда сортировать таблицу вот такого типа:
| id | model | sku |
| 1484 | Бур (SDS-Plus) 25 х 260 мм MAKITA | 1434 |
| 1485 | Бур (SDS-Plus) 25 х 310 мм MAKITA | 1435 |
| 1486 | Бур (SDS-Plus) 25 х 350 мм TAMO | 1436 |
| 1488 | Бур (SDS-Plus) 25 х 450 мм ТАМО | 1438 |
| 1487 | Бур (SDS-Plus) 25 х 450 мм MAKITA | 1437 |
| 1489 | Бур (SDS-Plus) 26 х 260 мм MAKITA | 1439 |
| 1490 | Бур (SDS-Plus) 26 х 310 мм MAKITA | 1440 |
| 1491 | Бур (SDS-Plus) 26 х 450 мм MAKITA | 1441 |
| 1407 | Бур (SDS-Plus) 4 х 110 мм TAMO | 1357 |
| 1408 | Бур (SDS-Plus) 4 х 110 мм MAKITA | 1358 |
| 1409 | Бур (SDS-Plus) 4 х 160 мм TAMO | 1359 |
| 1410 | Бур (SDS-Plus) 5 х 110 мм TAMO | 1360 |
| 1411 | Бур (SDS-Plus) 5 х 110 мм MAKITA | 1361 |
| 1413 | Бур (SDS-Plus) 5 х 160 мм MAKITA | 1363 |
| 1412 | Бур (SDS-Plus) 5 х 160 мм TAMO | 1362 |
| 1414 | Бур (SDS-Plus) 6 х 110 мм TAMO | 1364 |
| 1415 | Бур (SDS-Plus) 6 х 110 мм MAKITA | 1365 |
| 1417 | Бур (SDS-Plus) 6 х 160 мм MAKITA | 1367 |
| 1416 | Бур (SDS-Plus) 6 х 160 мм TAMO | 1366 |
| 1419 | Бур (SDS-Plus) 6 х 210 мм MAKITA | 1369 |
| 1418 | Бур (SDS-Plus) 6 х 210 мм TAMO | 1368 |
| 1420 | Бур (SDS-Plus) 6 х 260 мм TAMO | 1370 |
| 1422 | Бур (SDS-Plus) 8 х 110 мм MAKITA | 1372 |
| 1421 | Бур (SDS-Plus) 8 х 110 мм TAMO |
Добавлено через 9 минут
Не успел отредактировать.
Сортировка по полю `model`
Я в phpMyadmin выполняю запрос:
Возможно мое сообщение было не информативно, см. вложение.
Необходимо сортировать по модели с «человеческой логикой», т.е.:
| 1407 | Бур (SDS-Plus) 4 х 110 мм TAMO | 1357 |
| 1408 | Бур (SDS-Plus) 4 х 110 мм MAKITA | 1358 |
| 1409 | Бур (SDS-Plus) 4 х 160 мм TAMO | 1359 |
| 1410 | Бур (SDS-Plus) 5 х 110 мм TAMO | 1360 |
| 1411 | Бур (SDS-Plus) 5 х 110 мм MAKITA | 1361 |
| 1413 | Бур (SDS-Plus) 5 х 160 мм MAKITA | 1363 |
| 1412 | Бур (SDS-Plus) 5 х 160 мм TAMO | 1362 |
| 1414 | Бур (SDS-Plus) 6 х 110 мм TAMO | 1364 |
| 1415 | Бур (SDS-Plus) 6 х 110 мм MAKITA | 1365 |
| 1417 | Бур (SDS-Plus) 6 х 160 мм MAKITA | 1367 |
| 1416 | Бур (SDS-Plus) 6 х 160 мм TAMO | 1366 |
| 1419 | Бур (SDS-Plus) 6 х 210 мм MAKITA | 1369 |
| 1418 | Бур (SDS-Plus) 6 х 210 мм TAMO | 1368 |
| 1420 | Бур (SDS-Plus) 6 х 260 мм TAMO | 1370 |
| 1422 | Бур (SDS-Plus) 8 х 110 мм MAKITA | 1372 |
| 1421 | Бур (SDS-Plus) 8 х 110 мм TAMO | |
| 1484 | Бур (SDS-Plus) 25 х 260 мм MAKITA | 1434 |
| 1485 | Бур (SDS-Plus) 25 х 310 мм MAKITA | 1435 |
| 1486 | Бур (SDS-Plus) 25 х 350 мм TAMO | 1436 |
| 1488 | Бур (SDS-Plus) 25 х 450 мм ТАМО | 1438 |
| 1487 | Бур (SDS-Plus) 25 х 450 мм MAKITA | 1437 |
| 1489 | Бур (SDS-Plus) 26 х 260 мм MAKITA | 1439 |
| 1490 | Бур (SDS-Plus) 26 х 310 мм MAKITA | 1440 |
| 1491 | Бур (SDS-Plus) 26 х 450 мм MAKITA | 1441 |
Картинка в плохом качестве.
В спойлере полный вывод того, как отработал запрос в моем первом посте.
Сортировка то все равно не правильная.
Думал проблема в пробелах, удалил лишние пробелы.
Источник
Почему у меня не работает сортировка с помощью ORDER BY GROUP BY?
Пробовал написать запрос по данному ответу для сортировки таблицы по передаваемому параметру.
Вот код с запросом:
В итоге в выборке получаю только первую запись, а у меня их в таблице 5.
Пытался сделать так:
Результат тот же.
Пытался сделать без GROUP BY :
Выдаёт все нужные записи по (по лимиту их 3), но не сортирует.
В phpMyAdmin выполнил это:
Тоже не помогло. Параметры я проверял, все валидные, вывод ошибок у меня включён, при запросе их нет. В чём же тогда проблема?
2 ответа 2
prepared statements не могут менять структуру запроса. Поля в order by или group by — это всё ещё структура запроса.
Формально вы отправляете
Внимание на кавычки. Просто строковую константу, одно и то же значение для всех строк результата. Конечно сортировка ничего полезного не сделает, если у всех строк одно и то же значение для сортировки.
При сортировке у вас заведомо известен список возможных полей, по которым вы можете разрешить сортировать. Вот и проверьте переданное пользователем значение, есть ли оно среди допустимых. Если есть — подставьте в сам текст запроса. То есть проверка по белому списку, что безопасно с точки зрения sql injection .
Пытаться через выключенный ONLY_FULL_GROUP_BY получать первую строку в группе — к большим приключениям. Поищите (или задайте новый вопрос если найдёте) как эта задача должна нормально решаться для вашей версии СУБД.
Источник
Почему ORDER BY не срабатывает при использовании UNION в mysql?
Вопрос по mysql. Какие есть тонкости использования UNION в mysql?
Столкнулся с такой штукой — у меня есть два селекта, первый из них содержит ORDER BY . между селектами UNION стоит. сортировки в первом селекте почему-то НЕ происходит. То есть, выводит без сортировки, и ошибку не выдает никакую.
Создал базу данных
Создал таблицу ukraine
Создал таблицу russia
Объединяю с помощью UNION c ORDER BY, не срабатывает
Объединяю с помощью UNION c ORDER BY, не срабатывает
Объединяю с помощью UNION c ORDER BY, который ставлю в КОНЕЦ, сработало
Вопрос — почему ORDER BY срабатывает только в конце? Он, по идее, он должен срабатывать внутри каждого запроса.
5 ответов 5
Представьте, что каждый подзапрос вставляет данные в некоторую временную таблицу, а потом общий селект эти данные вытягивает. Тогда очевидно, что нет разницы в каком порядке были вставлены. Учитывается только итоговый порядок выборки
Трансформируется в некоторое подобие такого
Тогда понятно, что какие бы ORDER BY Вы не указывали в промежуточных запросах последний селект будет использовать свой порядок сортировки
Вы делаете именно union , не более простой и глупый union all . union без указания какой именно это union выполняет union distinct . Т.е. попытается удалить дубликаты строк из объединяемых множеств.
Обычно это само по себе не то поведение, на что вы рассчитывали и почти всегда когда говорят про union хотят видеть на самом деле union all . Если все строки разные, это просто лишняя операция, если есть совпадающие строки — то их вы потеряете из выборки и это может быть совсем не тем, что вы хотели получить.
И да, поиск дублирующих строк изменяет сортировку набора строк потому что он так сделан.
Фактически union all просто склеит две выборки одну за другой и не затронет сортировку. Не помню исключений для запроса верхнего уровня, но да, это не гарантируется стандартом. Если порядок критично важен то имеет смысл пересортировать после объединения:
Этот запрос гарантированно выдаст сначала записи из таблицы ukraine, отсортированные по названию, затем — из russia, тоже отсортированные по названию.
Источник
MySql сортировка работает ненормально
Я написал хранимую процедуру, которая возвращает отсортированные (восходящие или нисходящие) данные на основе столбца, который выбрал пользователь. Чтобы добиться этого, я использовал операторы Case в своем порядке по предложению , как в следующем фрагменте кода
Проблема в этом коде заключается в том, что он не сортирует данные должным образом, если выбран какой-либо столбец с целочисленным типом данных. Он рассматривает целочисленное значение как varchar и сортирует данные соответственно
Если requestId выбран в порядке ASCENDING .
Я попытался использовать пару решений для этой проблемы, таких как использование ABS () для преобразования значения varchar в целое число и т. Д., Но они не помогают мне решить проблему.
Я был бы признателен, если бы вы, ребята, помогли мне решить проблему
6 ответов
В самом деле, когда вы объединяете разные типы данных таким образом, выражение преобразуется в varchar , даже когда p_filter_type и p_filter_column указывают, что только числовой столбец должен определять результат этого выражения.
Один из способов решить эту проблему — создать отдельное выражение order by для каждой из возможностей, создав null для всех из них, кроме той, которая имеет отношение к делу. Таким образом, каждое из выражений может придерживаться своего собственного типа данных:
Например, когда p_filter_type = ‘DESC’ и p_filter_column = ’employeeID’ , то вышеприведенное предложение ORDER BY действительно разрешает следующее:
Который следует заказать так же, как если бы вы только что написали:
Гибридное решение
Конечно, вы можете выбрать какое-нибудь промежуточное решение, в котором вы сгруппируете поля, имеющие одинаковый тип данных, в одно выражение, чтобы преобразование типов данных не происходило. Таким образом, у вас может быть 6 выражений в предложении order by : одно для полей varchar , одно для полей int , одно для полей date , а затем каждое из них повторяется для убывающего случая:
Я думаю, что поскольку ваш столбец с типом varchar содержит цифры, и вы хотите отсортировать это поле по номеру, вам нужно привести это поле VARCHAR к INT во время упорядочения, как я пытался в приведенном выше коде. Надеюсь, что это поможет вам.
Как насчет добавления этого заказа ASC в первый случай?
Это работает? Кроме того, Вы уверены, что дата, которую Вы использовали в качестве примера неправильной сортировки, не находится в столбце Varchar? Похоже, это работает как один.
Если вы просто хотите преобразовать значение varchar в целое число, предполагая, что эти значения являются цифрами, mysql может сделать это просто, пусть этот столбец плюс 0, например так:
Поскольку CASE возвращает атомарное значение, возвращаемый тип данных может быть только одним. Вы не можете иметь другой возвращенный тип данных в другом исполнении. В этом случае все неявно преобразуется в varchar. Чтобы получить нужный вам порядок, вы должны убедиться, что целые числа будут упорядочены в соответствии с правилами упорядочения строк. Вот так:
Для упорядочения он изменит значения на 01, 02, 03, 10 , что позволит отсортировать их так, как вы хотите.
Я не уверен, что ваши даты будут упорядочены правильно, это зависит от ваших локальных настроек.
Вы можете сгенерировать подготовленный оператор, используя функцию CONCAT:
В качестве бонуса подготовленный оператор может использовать индексы (если они определены).
Однако вам может понадобиться сначала подтвердить ввод.
Другой обходной путь может заключаться в использовании LPAD для числовых полей и заполнении числа нулями:
Но это будет работать только для неподписанных типов.
Источник
Не работает сортировка MySQL
Помощь в написании контрольных, курсовых и дипломных работ здесь.
сайт работает, выборка из mysql работает, но ошибка в одном скрипте
Could not successfully run query (SELECT * FROM `pack` WHERE `name` = ») from DB: MySQL server has.
Сортировка в mySQL
Добрый день! Вот есть табличка следующей конструкции: id MEDIUMINT AUTO_INCREMENT.
Сортировка MySQL
Ребята подскажите какие то нюансы выполнения данного ТЗ пожалуйста. В базе данных содержится.
Здравствуйте, уважаемые форумчане. При выводе из БД MySQL (denwer) на локалхосте товаров все.
messages.id – такого поля нет, по крайней мере в тек. таблице
Добавлено через 1 минуту
И что за пробел перед .date_x? Лучше совсем уберите табличный префикс.
Что бы было понятно в таблице хранятся статьи/сообщения эти статьи можно комментировать, так вот свежая статья должна находится в верху списка, а свежий комментарий наоборот внизу
Что бы было понятно в таблице хранятся статьи/сообщения эти статьи можно комментировать, так вот свежая статья должна находится в верху списка, а свежий комментарий наоборот внизу Вот этот запрос не работает:
Пытался еще объединить 2 запроса с помощью UNION к примеру если parent_id > 0(комментарий) то DESC и если parent = 0(статья) то ASC, но тоже безрезультатно
Источник