О ключах

[RedFox]

Цитата:

Сообщение от Milk

Пока писал, придумал изврат: добавить новое поле в таблицу и вначале ключа поставить новое поле, которое никогда не будет заполняться, а потом уже "Entry No."... Гы, а ведь хоть какое-то решение

Так поставте фильтруемое поле вперед.

[rov_imported]

Цитата:

Сообщение от RedFox

Так поставте фильтруемое поле вперед.

А тогда записи будут отсортированы по этому полю, а не по первичному ключу! Не катит...

Milk - а решение с фиктивным полем на самом деле классное! Действительно решит проблему.
Про то, что нельзя сделать вторичный, начинающийся с первичного - блин как-то не сталкивался ни разу,
и не знал про это. Или знал - но забыл...

[RedFox]

Цитата:

Сообщение от rov

А тогда записи будут отсортированы по этому полю, а не по первичному ключу! Не катит...

Так зачем тогда фильтр накладывать? Или изначально подразумевается сложный фильтр?
По поводу доп. поля пустого - это не добавить производительности никак. Мне не понятно цель операции в таком случае.

[rov_imported]

Цитата:

Сообщение от RedFox

Мне не понятно цель операции в таком случае.

ну вообще это конечно вопрос к автору - для чего ему это надо.
Но я бы с ходу придумал бы такой пример:
необходимость отследить хронологию ФИФО. Для этого необходимо отфильтровать ТКО по типу "Продажа"
(этого в задаче нет - но суть не меняется), затем налоджить фильтр по дате, например с 01.02.08 по 05.02.08.
Причем записи должны быть отсортированы по первичному ключу. В результате, если не было нарушений
хронологии учета - то все даты в операциях будут возрастать. Более свежая операция - большая дата. А если
хронология нарушена - то более свежие даты будут в начале списка, ну или раньше, чем менее свежие даты.

[RedFox]

Цитата:

Сообщение от rov

ну вообще это конечно вопрос к автору - для чего ему это надо.
Но я бы с ходу придумал бы такой пример:
необходимость отследить хронологию ФИФО. Для этого необходимо отфильтровать ТКО по типу "Продажа"
(этого в задаче нет - но суть не меняется), затем налоджить фильтр по дате, например с 01.02.08 по 05.02.08.

Вторичный ключ работает нормально

Цитата:

Причем записи должны быть отсортированы по первичному ключу. В результате, если не было нарушений
хронологии учета - то все даты в операциях будут возрастать. Более свежая операция - большая дата. А если
хронология нарушена - то более свежие даты будут в начале списка, ну или раньше, чем менее свежие даты.

Во-первых не забываем, что в NAV в конце каждого вторичного ключа добавляется первичный (типа для уникальности, но более правильно описано в доке по SQL). Поэтому обычно они и будут либо возрастать (ASC), либо убывать (DESC)
Во-вторых, корректные нарушения так не выявишь

[Fordewind]

Цитата:

Сообщение от RedFox

Так поставте фильтруемое поле вперед.

Это тоже самое, что просто сделать вторичный ключ только по фильтруемому полю. И это не подходит