Вам нужен составной индекс. Сначала по номеру отдела, потом по порядковому номеру.

Если номер отдела и порядковый номер это строки, то выражение индекса будет такое

notdel + pn

Если номер отдела и порядковый номер это числа, то выражение индекса будет такое

STR(notdel,5) + STR(pn,2)

Числа 5 и 2 - условные. Сами оцените, какие максимальные значения номеров могут быть. При этом отбрасывать ведущие пробелы нельзя, иначе получим нарушение порядка следования.

прошелмимопример
"Закладываться" на то, что в пределах одной группы данные будут упорядочены по физическому номеру записи, как минимум, не разумно. Тем более, нет никакой гарантии, что порядок следования "порядковых номеров" работников, совпадет с физическим порядком следования записей. Т.е. опять же, нужна сортировка по двум полям.

В данном примере надо добавить сортировку по полю "u"

К. АлександрЯ использовал прямой доступ к таблице и set filter, но мне сказали что это не правильно, правильно через курсоры.
Вот я создал курсор в сорсе таблицы: SELECT pn, notdel, prof, fio, sym1, sym2, sym FROM zpl nofilt ORDER BY notdel, pn INTO CURSOR arEdit
Поскольку разговор пошел "лесом" (вы с прошелмимо говорите о разных вещах, поэтому друг друга не понимате), то попробую вернуться к исходной постановке задачи.

Использование SET FILTER и прямое редактирование таблиц-источников не то, чтобы не правильно, просто это решение, которое очень сильно ограничивает разработчика. Обычно SET FILTER используют как "сиюминутное" решение, лишь бы заткнуть проблему. Если всеръез заниматься некогда.

Чтобы получить бОльший простор для маневра и используемых инструментов действительно, лучше вместо SET FILTER делать выборку из таблицы. Правда, здесь следует оговорится, что в этой выборке должно быть как можно меньше записей. Не следует в результирующую выборку перегонять всю таблицу-источник, как это сделали вы в данном примере. Это просто бессмысленно.

Другими словами, использовать в качестве источника данных выборку (курсор) имеет смысл тогда, когда, во-первых, есть условие WHERE и, во-вторых, по этому условию отсекается бОльшая часть записей. Желательно, чтобы в результирующей выборке оказалось не более нескольких сотен записей.

Grid .

В качестве источника данных Grid может выступать только и исключительно таблица. Или курсор, как временная таблица. По умолчанию, в качестве типа источника данных Grid.RecordSourceType указывается Alias .

Тут следует уточнить, что алиас - это вообще не таблица и не курсор. Это некий псевдоним (идентификатор) рабочей области . Некоего "пространства", где "живет" определенный "набор данных".

В рабочей области может быть открыта как собственно таблица (файл DBF), так и курсор. Т.е. вообще-то, вы могли сделать следующее:


При настройке по умолчанию Grid.RecordSourceType = 1 (Alias) это и будет означать указание в качестве источника данных Grid - курсора. Ведь под именем алиаса "zpl" скрывается как раз курсор.

Остальные значения настройки Grid.RecordSourceType предназначены для того, чтобы указать некие объекты, из которых FoxPro сам, автоматически, сможет сформировать эти самые курсоры. В частности, то, что использовали вы, указав Grid.RecordSourceType = 4 (SQL Statement) означает, что для формирования курсора надо выполнить команду, записанную в свойстве Grid.RecordSource.

Однако лучше все-таки оставить настройку Grid.RecordSourceType в значении по умолчанию и "подсовывать" Grid в качестве источника нужные алиасы.

Откуда вы можете подсунуть эти самые алиасы? Ну, вы можете просто вручную его написать, если будете твердо уверены, что к моменту инициализации Grid этот алиас будет существовать. А откуда возьмется эта уверенность? Ну, от того, как именно вы напишите программу. От вашей дисциплинированности.

Зависимость от вашей дисциплинированности несколько уменьшает использование DataEnvironment. Если таблица включена в DataEnvironment, то при выборе Grid.RecordSource в раскрывающемся списке будут отображены все алиасы, под которыми будут работать эти таблицы. Причем, в режиме "по умолчанию" вам гарантируется тот факт, что соответствующий алиас будет существовать к моменту инициализации Grid.

А можно ли включить в DataEnvironment не таблицу, а некую выборку из нее? Можно. Но не любую выборку, а такую выборку, которая была "вложена" в некий специфический объект FoxPro. Ведь в DataEnvironment вы добавляете некие объекты. Что именно?

Во-первых, это может быть Local View. Это выборка (курсор), но уже "обернутая" в некую "оболочку". С ней можно работать как с обычной таблицей. Создается Local View в контейнере базы данных в окне проекта внутри ветки контейнера базы данных после Tables идут как раз Local View.

Несмотря на всю не любовь прошелмимо к этим объектам, как к устаревшим, я все-таки рекомендовал бы начать обучение именно с них. Они очень удобны именно в качестве инструмента для обучения. Там все просто и наглядно. А вот когда с ними разберетесь, переходите к классам CursorAdapter.

Классы CursorAdapter - это то самое, во-вторых, которое также можно указать в DataEnvironment. Правда специфическим способом. Через пункт меню Builder выпадающего меню. Ну, а о собственно классе CursorAdapter вас уже прошелмимо просветит...