Приветствую всех. Что-то затупил в понимании логики запроса.
Привожу упрощенный пример. Есть врем.таблица втТЗ, которая потом соединяется с самим собой через условие меньше по партии:
Выбрать
тз.Номенклатура
тз.Партия,
тз.Количество
Поместить втТЗ
...;

Выбрать
  тз1.Номенклатура
  тз1.Партия,
  тз1.Количество
ИЗ втТЗ как тз1
ЛЕВОЕ СОЕДИНЕНИЕ втТЗ как тз2
  ПО тз1.Номенклатура = тз2.Номенклатура
     И тз1.Партия < тз2.Партия

где Партия - это различные документы поступления (разных видов).
Разве мы можем так сравнивать партии в соединении? Если да, то не понимаю логики

Я к тому, что одно дело сравнивать на ревенство или неравенство. А другое меньше/больше между документами разных видов. Я так понимаю, сравнение на дату документа здесь не выполняется.

(0) сравнивать можем, но это не гарантирует нам хронологический порядок

(0)[Разве мы можем так сравнивать партии в соединении]
вы можете

(0) если ошибок рантайма не возникает, то сравниваются гуиды ссылок, что скорее всего является архитектурной ошибкой.

гуиды для новых документов хоть и могут создаваться в порядке возрастания, но это в общем и целом не является истиной

(2) он и не выполняется. Я в отладке вывел поля партий из обеих таблиц, и соединение выполнилось с документом с датой меньше

ответьте себе на простой вопрос: что по-вашему означает "одна партия меньше другой" ?

(3) и? в чем суть то сравнения, логика?

похоже, еще один угнанный аккаунт...

(6) тогда логичнее сравнивать моменты времени, или даты на худой конец. А тут ссылки на документы. Это как?

(8) нет, с чего это вы взяли?

(9) спросите у того идиота, который написал "тз1.Партия < тз2.Партия"

(11) те ваш ответ нужно расценивать как "запрос неверный, явно косяк"? и логику тут искать не стоит

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

(13) я тоже так думаю, но больше ничего не увидел.

(12) ни в коем случае, это критически важный запрос, в полном объёме соответствующий ТЗ

Провел моделирование, и вот что получил:
1. Если сравнение идет между документами ОДНОГО вида, то тут анализируется хронология (скорее всего по моменту времени)
2. Если документы РАЗНОГО вида, то большим считается тот, кто ниже в дереве метаданных в конфигураторе, при это дата документа уже ни играет роли. Те документ, находящийся ниже и с ранней датой, будет считаться больше чем текущий.

Возможно предыдущий программист, скорее всего, сравнивал документы одного вида, а тут по прошествии времени, появились другие документы.
Всем спасибо.

не надо сравнивать ссылки на больше-меньше

(0) так можно делать только, если документы Партия всегда гарантированно создаются на одной машине в одном потоке. То есть - только у себя на локали для отладки.

Сравнивай дату партии просто и не парь голову

(16) ты где-то налажал. Гуид ссылки не содержит никакой информации о типе документа. Это просто гуид. Стало быть, зависимость порядка от типа, если и есть, то это случайное совпадение в твоем конкретном случае.

гуиды технически можно сравнивать на больше-меньше. Это не запрещено. Запрещено ожидать, что они как-то связаны с астрономическим временем их создания. Если сравниваемые гуиди сгенерены в одном и том же потоке, то сортировка по гуидам даст хронологический порядок. Если они сгенерены в разных потоках, то сравнение на больше-меньше может совпасть с хронологией их генерации а может не совпасть.

хотя, если это guid v4, то и в одном потоке может что угодно получиться на больше-меньше

(20) Это запрещено здравым смыслом

(22) как выяснилось технически это работает. Но зачем это было написано ранее кем-то, непонятно

(22) ну, может цель была в том, чтобы рандомно раскидать выборку

В 7,7 Так сравнивались позиции документа проверялась дата и время с учетом того что 1с давала записать в 1 и туже секунду несколько документов тот, что раньше тоже вычислялся.
Есть любители писать все приходы в 6-00-00 и тогда сравнивать просто дату и время мало. А такое значение вполне корректно работало. Возможно чел недавно с 7,7 перешел и по привычки юзает старые механизмы.