Вход | Регистрация
 

СрезПоследних возвращает разный набор данных (разные записи ВЫБРАТЬ ПЕРВЫЙ 1)

СрезПоследних возвращает разный набор данных (разные записи ВЫБРАТЬ ПЕРВЫЙ 1)
Я
   МишельЛагранж
 
17.02.21 - 12:24
СрезПоследних по РС возвращает разный набор записей, т.е. ВЫБРАТЬ 1 - разные вызовы возвращают разные значения.
Пример:
1 набор:
Пользователь 1 - 01.12.2019 << ВЫБРАТЬ ПЕРВЫЕ 1
Пользователь 2 - 01.01.2019
Пользователь 3 - 01.12.2018

2 набор:
1 набор:
Пользователь 2 - 01.01.2019 << ВЫБРАТЬ ПЕРВЫЕ 1
Пользователь 1 - 01.12.2019
Пользователь 3 - 01.12.2018
(значение по 'ВЫБРАТЬ ПЕРВЫЕ 1' показаны условно "по консоли запросов", т.к. порядок записей, выводимый в консоли, и порядок реальной выборки - разные, но принцип "один запрос - разные записи" аналогичен).

В РС несколько измерений (да, изначально при проектировании РС одно из измерений - нужно было сделать реквизитом, т.к это искомое значение, по нему отбор не используется, но уже не переделаешь).
Условия через ГДЕ, а не в параметрах (т.е. сначала отбираются последние записи, а потом на них накладывается фильтр, а не последние среди условий как в противном случае).
Запрос не меняется, естественно.
Кто что думает, почему так?
   Глупый ответ
 
1 - 17.02.21 - 12:25
сортировать пробовал?
   МишельЛагранж
 
2 - 17.02.21 - 12:28
(1) пробовал, но вопрос в другом - SQL возвращает разные наборы. В случайном порядке. То правильно, то - неправильно. Причем неправильно - набор всегда одинаков, как и "правильно".
>>кстати, читать "
2 набор:
1 набор:"
как:
"2 набор:"
   МишельЛагранж
 
3 - 17.02.21 - 12:28
Да, исходный запрос без сортировки и отбора по дате.
   fisher
 
4 - 17.02.21 - 12:29
При отсутствии явной сортировки порядок возвращаемых записей не гарантируется и может быть разным. Твой запрос неявно завязан на порядок, поэтому сортировка обязательна.
Но вообще странно, что каждый раз разный. Обычно план выполнения запроса кэшируется и порядок повторяется до изменения каких-то внешних условий (самого запроса, обновления статистики, обновления кэша планов выполнения и т.п)
   Ненавижу 1С
 
5 - 17.02.21 - 12:31
показывай уже свой запрос
   МишельЛагранж
 
6 - 17.02.21 - 12:33
>>сортировки порядок возвращаемых записей не гарантируется и может быть разным
Не "может быть", а разный))
Мне непонятно только, почему он "разный" в случайный момент времени, и всегда разный "одинаково" - т.е. нет других возвращаемых порядков кроме этих двух.
Поэтомы row-хранение записей в SQL отпадает, т.к. физический порядок записей не повторяется (если её изменяют), или вообще не меняется в таблице (если её только читают).
   МишельЛагранж
 
7 - 17.02.21 - 12:35
(5) запрос неправильно написан, не по данному РС, я уже это отметил.
Он элементарный.
Да, нужно менять или РС (измерение - перебросить в реквизит), либо запрос (сортировка, отбор по дате и т.д.)
Мне интересно, что происходит с данными именно по этому запросу)
   fisher
 
8 - 17.02.21 - 12:38
(6) Что такое разный "одинаково"? Один и тот же запрос при последовательном выполнении попеременно выдает то один порядок, то другой?
Да кто ентот оптимизатор запросов разберет. Похоже на то, что в зависимости от какого-то "дрожащего" параметра выбирается то один план выполнения, то другой. Можно запрофайлить. Либо даже это "дрожание" находится под оптимизатором запросов - порядок обхода страниц почему-то разный бывает. ИМХО, это может быть интересно только для очень узких специалистов. Прикладному программисту достаточно знать только вышесказанное. Есть завязка на порядок - сортируй.
   МишельЛагранж
 
9 - 17.02.21 - 12:40
Кому вот прям интересно, что за запрос. Но это ничего вам не даст :)
ВЫБРАТЬ ПЕРВЫЕ 1
    ОтветственныеЛицаСрезПоследних.Период,
    ОтветственныеЛицаСрезПоследних.Документ,            <<ИЗМЕРЕНИЕ 1
    ОтветственныеЛицаСрезПоследних.Организация,            <<ИЗМЕРЕНИЕ 2
    ОтветственныеЛицаСрезПоследних.Подписант КАК ОсновнаяПодпись,    <<ИЗМЕРЕНИЕ 3
    ОтветственныеЛицаСрезПоследних.Приказ
ИЗ
    РегистрСведений.ОтветственныеЛицаСрезПоследних КАК ОтветственныеЛицаСрезПоследних

ГДЕ
    ОтветственныеЛицаСрезПоследних.Организация = &Организация
    И ОтветственныеЛицаСрезПоследних.Документ = &СчетФактура
   Глупый ответ
 
10 - 17.02.21 - 12:41
(9) добавь сортировать По не иби нам созг.
   Глупый ответ
 
11 - 17.02.21 - 12:41
мозг
   МишельЛагранж
 
12 - 17.02.21 - 12:42
(8)>>Один и тот же запрос при последовательном выполнении попеременно выдает то один порядок, то другой?
Именно :)
Я и так старался подробно описать, что такое "разные наборы".
   МишельЛагранж
 
13 - 17.02.21 - 12:43
(10) умный ответ в первой части. Но глупый - в целом.
Все это давно понятно -> (7)
   fisher
 
14 - 17.02.21 - 12:46
(13) Ну, если у тебя нестерпимый исследовательский зуд, то я бы для начала запрофайлил и сравнил планы выполнения запроса, когда он выдает разный порядок.
   МишельЛагранж
 
15 - 17.02.21 - 12:47
(8)>> Прикладному программисту достаточно знать только вышесказанное
Понимаешь, люди годами работали, и, возможно, нивелировали ошибки на своем урвоне - просто меняли вручную, когда неправильно выводилось, списывая на "это опять там где-то в базе чей-то поменяли с подписями".
А выясняется вот такая "магия" тут, оказывается, работает - и выдает эта "магия" разные результаты. Поэтому нужно как-то обосновать, что данный участок надо переделывать.
   fisher
 
16 - 17.02.21 - 12:48
(15) Об эту "магию" убился еще легион криворуких семерочных программистов, перенося базу на сиквел :)
   МишельЛагранж
 
17 - 17.02.21 - 12:49
(14) прикол еще и в том, что совершенно непонятно, когда-какие наборы выдаются.
Вообще неясен триггер данного поведения - со стороны пока в случайный момент времени меняется вывод.
Правильно - правильно - правильно - неправильно - правильно - неправильно - правильно - правильно - правильно
   Глупый ответ
 
18 - 17.02.21 - 12:49
(16) Забанен в 12:12 и все равно пишет, он ИЗБРАННЫЙ.
   МишельЛагранж
 
19 - 17.02.21 - 12:49
(16) так и не разобрались до конца? :)
   МишельЛагранж
 
20 - 17.02.21 - 12:50
(18) он модератор веток
   Глупый ответ
 
21 - 17.02.21 - 12:50
(19) Были уволены нафиг. Ибо нехер рабочее время на фигню спускать.
   fisher
 
22 - 17.02.21 - 12:52
(19) Это РТФМ. В СУБД со страничной организацией данных порядок выдачи результата при отсутствии явной сортировки не гарантируется.
Просто для файловых баз прокатывало (простые алгоритмы ходили по данным всегда в одинаковом порядке), а во "взрослых" СУБД извлечение данных зависит от кучи факторов.
   Провинциальный 1сник
 
23 - 17.02.21 - 12:52
Нельзя рассчитывать на порядок результата запроса без явного указания сортировки.
   МишельЛагранж
 
24 - 17.02.21 - 12:56
(22) т.е. железобетонно без заумностей ничего не показать в обосновании?
Жаль.
Я, правда, тоже ничего не нашел по данному вопросу в инете.
>>В СУБД со страничной организацией данных порядок выдачи результата при отсутствии явной сортировки не гарантируется
Это понятно, но это RTFM (т.е. как подойдет доказательство - на этапе внедрения), а база с таким косяком уже внедрена, и работала годами :)
   МишельЛагранж
 
25 - 17.02.21 - 12:57
>>(т.е. как подойдет доказательство - на этапе внедрения)
"т.е. как доказательство подойдет толькько на этапе внедрения"
   fisher
 
26 - 17.02.21 - 12:57
(18) Меня пока только в политических ветках забанили. Что для политических веток великий модераторский прогресс, должен признать.
   fisher
 
27 - 17.02.21 - 13:01
(24) Работало годами в сиквеле? Либо везло, либо забивали, либо и то и другое.
В обосновании очень просто: трудновыявляемая ошибка в запросе. Это явная ошибка, за которую линейкой по рукам лупят.
   Йохохо
 
28 - 17.02.21 - 13:08
(24) она ждала момента
   Кирпич
 
29 - 17.02.21 - 13:43
Запрос может выполняться в несколько потоков. Каждый поток возвращает в результат свою порцию данных. Какой поток быстрее, того записи и первые упадут в результат.
   Вафель
 
30 - 17.02.21 - 14:15
обоснование - ибо это г..нокод
 
 Рекламное место пустует
   Вафель
 
31 - 17.02.21 - 14:58
Это примерно как ходить по стройке и каску не носить.
Можно всю жизнь ходить и ничего не словить.
А можно и словить
   МишельЛагранж
 
32 - 17.02.21 - 15:44
(27)то и плохо, что такую корявость еще и доказать нужно, чтобы изменения внести
   fisher
 
33 - 17.02.21 - 15:49
(32) Пойдет в качестве доказательства? https://docs.microsoft.com/ru-ru/sql/t-sql/queries/top-transact-sql?view=sql-server-ver15
"Если вы используете TOP с предложением ORDER BY, в результирующий набор включаются только первые N строк отсортированного результата. В противном случае TOP возвращает N строк в неопределенном порядке"
   fisher
 
34 - 17.02.21 - 15:53
Ну или из встроенной справки 1С: "Будут отобраны самые первые (в соответствии с правилами упорядочивания результатов запроса) строки"
Ошибка - правила упорядочивания не были заданы. Что тут еще обосновывать?
   МишельЛагранж
 
35 - 17.02.21 - 16:13
(34)>> Что тут еще обосновывать?
Как-то обыгрывать возражения "код же рабочий" и "работало же" :)
   МишельЛагранж
 
36 - 17.02.21 - 16:15
Плохо, что пользователи не в курсе, я вот сунулся использовать эти разработки - и дальше уже как-бы моя "ошибка" пойдет, поэтому желательно сразу поправить.
   Вафель
 
37 - 17.02.21 - 16:21
(36) не используй для своих доработок эту процедуру.
если уж не дают конфу корячить
   МишельЛагранж
 
38 - 17.02.21 - 18:28
(37) оставляя как прежде - я "подтверждаю", что там все ок. А это не так.
Запрос-то так и работает непредсказуемо.
   fisher
 
39 - 17.02.21 - 18:29
(35) "Усы вот и хвост мои документы!" (с)
   Провинциальный 1сник
 
40 - 17.02.21 - 19:09
(27) Такие ошибки и в типовых встречались..
   fisher
 
41 - 18.02.21 - 10:12
(40) Каких только ошибок в типовых не встречалось. Чай не боги их пишут, всяк ошибиться может. Но одно дело провтыкать - это со всеми бывает. А вот по незнанию - это плохо. Такие вещи специалист понимать должен. Тут же даже на уровне здравого смысла просто обязан родиться вопрос - если я выбираю первую из многих, то какая именно должна быть первой и почему?
   программистище
 
42 - 18.02.21 - 11:23
(41) на такой случай в платформе должна быть защита от дурака и сортировка ПО умолчанию
   ДедМорроз
 
43 - 18.02.21 - 11:32
В регистре сортировка при выборке по кластерному индексу,но он здесь изначально по периоду,соответственно,в зависимости от обновления статистики будет выполняться или полное сканирование или сканирование по индексу,что даст разные результаты.
Ещё можно предположить,что до этого выполняется подобный запрос,результат которого идёт как база для текущего.

Как бы,план запроса для двух случаев посмотреть не мешает.
   vi0
 
44 - 18.02.21 - 12:02
(42) с таким ником давать подобные рекомендации грех
   программистище
 
45 - 18.02.21 - 12:45
(44) сейчас чувства неверующего задели (словом грех), осторожней
   fisher
 
46 - 18.02.21 - 13:47
(42) С чего вдруг? Есть ведь варианты, когда устраивает любая первая. И даже наличие дефолтовой сортировки вовсе не исправляет логическую ошибку программиста, когда алгоритм зависит от порядка, но порядок явно не определили. Будет точно такая же логическая ошибка, которая может выстрелить не сразу. Заведут новый элемент в базу, который в соответствии с дефолтовой сортировкой (но против задумки) вылезет вперед - и вуаля.
   vi0
 
47 - 18.02.21 - 14:07
(45) грех осторожничать
   Провинциальный 1сник
 
48 - 18.02.21 - 15:35
(42) Любая сортировка по умолчанию - это изначально дополнительные тормоза, даже там где сортировки не требуется. Оно надо?
   brainguard
 
49 - 18.02.21 - 16:34
(9) Перенеси ГДЕ в параметры виртуальной таблицы.


Список тем форума
Рекламное место пустует  Рекламное место пустует
Независимо от того, куда вы едете — это в гору и против ветра!
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.