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

ты не думай, ты пей (С) Наша Раша
на самом деле регистр не периодический и независимый, откуда там появится период(момент добавления в базу)?

(1) Порядок добавления в базу я имел ввиду физический (т.е. никакой сортировки нет вообще).

Меня интересует вопрос: откуда сортировка по Штрихкоду идет, почему не по другому какому-то реквизиту? (Владелец, Характеристика, Серия, качество). Ну какое-то объяснение этому должно быть?

+(2) Возьмем справочник Номенклатура, там сортировку можно менять: Код, Наименование, Артикул,.. Тут все ясно, сортируется по этим полям,

отом

+(3) Тут все ясно, сортируется по этим полям, потому что они индексные... А в (0) как объяснить...

...

Почему то всегда думал, что РС сортируется по возрастанию Измерений, от первого до последниего.

SQL «смотрит как-то недовольно, свирепо и в то же время грустно и с недоумением» на автора:

SELECT TOP 20
T1._Fld89,
T1._Fld90,
T1._Fld91
FROM _InfoRg88 T1 WITH(NOLOCK)
ORDER BY (T1._Fld90) ASC, (T1._Fld91) ASC

НО!

Это в форме списка, то бишь в динамике.

В "статике" обычного запроса:

ВЫБРАТЬ
   РегистрСведений1.Измерение1,
   РегистрСведений1.Измерение2,
   РегистрСведений1.Ресурс1
ИЗ
   РегистрСведений.РегистрСведений1 КАК РегистрСведений1


все красиво - в порядке добавления записей, аля:

SELECT
T1._Fld90,
T1._Fld91,
T1._Fld89
FROM _InfoRg88 T1 WITH(NOLOCK)

(9)
БЕРЕМ УТ, УправлениеРозничнойТорговлей.ПолучитьШтрихКод
в которой запрос
   |ВЫБРАТЬ ПЕРВЫЕ 1
   |    РегШтрихкоды.ТипШтрихкода,
   |    РегШтрихкоды.Штрихкод
   |ИЗ
   |    РегистрСведений.Штрихкоды КАК РегШтрихкоды
   |ГДЕ
   |    РегШтрихкоды.Владелец = &Владелец
   |    И РегШтрихкоды.ЕдиницаИзмерения = &ЕдиницаИзмерения
   |    И РегШтрихкоды.ХарактеристикаНоменклатуры = &ХарактеристикаНоменклатуры
   |    И РегШтрихкоды.СерияНоменклатуры = &СерияНоменклатуры
   |    И РегШтрихкоды.Качество = &Качество
Добавляем на товар два разных штрихкода одинакового типа (ЕАН13), все измерения, кроме самого штрихкода одинаковые:
первый 2000000000015, второй 1234567890128
Запрос вернет второй штрихкод. Теперь удаляем эти ШК, и добавляем два в таком порядке: первый 1234567890128, второй 2000000000015. Запрос вернет все равно ШК 1234567890128.

Вот теперь вопрос: что в запросе подправить чтобы в случае нескольких ШК он возвращал физически созданный первый ШК (ну или последний), а не в порядке возрастания(убывания) самого поля ШК

не Постгрии случаем?

не, файловая

Есть в SQL-терминах понятия явная/неявная сортировка, хотя для такого простого запроса даже неявная сортировка не должна стартануть. Странно...щас на постгри проверю

(13) Там как раз неявная сортировка

Все просто - в выборке нет измерений!

нет измерений! -> нет ресурсов!

Нет ресурсов - SQL юзает IndexScan при выборке - выборка упорядочена по измерениям.
Есть ресурсы - SQL юзает TableScan при выборке - выборка получается "как есть"

IndexScan по индексу Измерений
_InfoRxxx_ByDims_SRRRRRR

+(13) У меня аналогично как в (10)
(17) Чем если не секрет ловишь SQL-запросы?

Радует:
файловая работает также как SQL
Интересует:
Как дела в постгри

Короче хз почему, но
1)
ВЫБРАТЬ    
   РегШтрихкоды.ТипШтрихкода,
   РегШтрихкоды.Штрихкод,
   РегШтрихкоды.Владелец
ИЗ
   РегистрСведений.Штрихкоды КАК РегШтрихкоды
ГДЕ
   РегШтрихкоды.Владелец = &Владелец

2)
ВЫБРАТЬ    
   РегШтрихкоды.ТипШтрихкода,
   РегШтрихкоды.Штрихкод,
   РегШтрихкоды.Владелец
ИЗ
   РегистрСведений.Штрихкоды КАК РегШтрихкоды


Результат первого запроса упорядочен по Штрихкод, результат второго запроса НЕ упорядочен, а выводит как есть в таблице физически

(19) profiler + enterprise manager + execution plan

аналогично неправильно :)

+(21) хотя тут ни в 1) ни 2) ресурсов нету

(24) Смотреть план запроса.

Сортируйте принудительно!
инфа 100%

(21) А у меня - оба отсортированны по коду