Разное расположение группировок в отчете
Забавная ситуация.
Есть две одинаковые базы. На разных серверах, она подключена к храну.
На первой, без храна, отчет выводит поля группировок так, как это обозначено в запросе отчета, к примеу 1, 1.1, 2, 2.1, 2.2, 3, ...
На второй базе, которая на другом сервере, и на подключена к храну, этот же отчет, этот же запрос в отчете, выводит на экран 2, 2.1, 2.2, 3, 1. 1.1.
Кеш чистился, Менял наименования группировок, тоже применяются. расположение группировок все равно разное.
Что может быть не так? и Где?
Есть две одинаковые базы. На разных серверах, она подключена к храну.
На первой, без храна, отчет выводит поля группировок так, как это обозначено в запросе отчета, к примеу 1, 1.1, 2, 2.1, 2.2, 3, ...
На второй базе, которая на другом сервере, и на подключена к храну, этот же отчет, этот же запрос в отчете, выводит на экран 2, 2.1, 2.2, 3, 1. 1.1.
Кеш чистился, Менял наименования группировок, тоже применяются. расположение группировок все равно разное.
Что может быть не так? и Где?
По теме из базы знаний
Найденные решения
(3) Это популярная ошибка. Если порядок не задан явно, то порядок строк результата не определен. В файловых базах, где хранение данных и алгоритмы их выборки проще, результат часто совпадает с "интуитивным". Но полагаться на это не стоит, так как это недокументированная фича. А во "взрослых" СУБД это и вовсе не так. Бывает еще "забавнее". Можно работать продолжительное время и получать результаты в одном порядке, а потом в один прекрасный момент начать получать их в другом.
Правило очень простое - везде, где подразумевается какой-то порядок, он ДОЛЖЕН быть определен явно в запросе. Никакого гарантированного "дефолтного" порядка не существует и порядок записей в результате зависит от внутренних особенностей используемых сервером алгоритмов и хранения данных. В доках по сиквелу черным по белому пишут: при отсутствии ORDER BY - порядок неопределен. И это логично, если подумать.
Правило очень простое - везде, где подразумевается какой-то порядок, он ДОЛЖЕН быть определен явно в запросе. Никакого гарантированного "дефолтного" порядка не существует и порядок записей в результате зависит от внутренних особенностей используемых сервером алгоритмов и хранения данных. В доках по сиквелу черным по белому пишут: при отсутствии ORDER BY - порядок неопределен. И это логично, если подумать.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3) Это популярная ошибка. Если порядок не задан явно, то порядок строк результата не определен. В файловых базах, где хранение данных и алгоритмы их выборки проще, результат часто совпадает с "интуитивным". Но полагаться на это не стоит, так как это недокументированная фича. А во "взрослых" СУБД это и вовсе не так. Бывает еще "забавнее". Можно работать продолжительное время и получать результаты в одном порядке, а потом в один прекрасный момент начать получать их в другом.
Правило очень простое - везде, где подразумевается какой-то порядок, он ДОЛЖЕН быть определен явно в запросе. Никакого гарантированного "дефолтного" порядка не существует и порядок записей в результате зависит от внутренних особенностей используемых сервером алгоритмов и хранения данных. В доках по сиквелу черным по белому пишут: при отсутствии ORDER BY - порядок неопределен. И это логично, если подумать.
Правило очень простое - везде, где подразумевается какой-то порядок, он ДОЛЖЕН быть определен явно в запросе. Никакого гарантированного "дефолтного" порядка не существует и порядок записей в результате зависит от внутренних особенностей используемых сервером алгоритмов и хранения данных. В доках по сиквелу черным по белому пишут: при отсутствии ORDER BY - порядок неопределен. И это логично, если подумать.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот