Здесь затронули старую и больную тему: сортировка в Gride, связанном с базой. Причем в общем случае нужно сортировать не только по Lookup, но и по Calc полям. Насколько мне известно, хорошего компонента нет. Пару лет назад я пытался слелать DBGrid с сортировкой (наверняка многие пытались), сортировка в Gride не совпадает с сортировкой в DataSet, ну то есть DataSet (обычно в виде Query) пришел с сервера с какой-то сортировкой, накрутили Lookup и Calc поля, а затем в клиентском приложении сортируем как хотим.

Проблема оказалась в следующем: при движении по гриду вверх и вниз в DataSet вместо обычных Next() и Prior(), приходится делать Locate причем в общем случае не известно по каким полям. Хорошо если просматриваеися первичный ключ или уникальный индекс, однако запрос может быть построен таким образом, что никакой уникальности не видно даже при хорошей структуре базы, т.е. либо слишком сложный SELECT, либо в SELECT не включены поля первичного ключа или уникального индекса. Делать Lacate по всем хранимым полям тоже не всегда полезно, т.к. могут быть повторяющиеся записи. Одним словом не получилось.

Идея об отключении от DataSet, т.е. при перемещении по гриду не перемещяться по датасет тоже не очень хороша, т.к. при корректировке все проблемы останутся.

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

2 123456789098
То, что жизнь тяжела - это я полностью согласен.
А вот то, что ничего путного нельзя сделать не согласен. В Вашем сообщении основной проблемой являлось быстродействие (на паре милионов строк). Естественно если при хранении данных пользоваться плоской таблицей и традиционными методами сортировки, то так и получится. Однако если пользоваться сбалансированным деревом, то кол-во операций при изменении одной записи (если это изменение привело к изменения порядка записей) пропорционально двоичному логарифму N, где N - кол-во записей. Двоичный логарифм от 2 000 000 равен 21. Такое перестроение дерева будет меньше секунды. Правда переодически нужно балонсировать дерево, чтобы отдельные ветви сильно не удлиннялись, это относительно медленно, в наихудшем случае порядка N, однако при большем дереве очень редко.
Насчет изменения пары тысяч. Если изменять по одной записи, то время перекидывания листа дерева распределится на каждую операцию и не будет заментно. Если это какая либо контекстная замена на клиенте, то будет медленно. Однако контекстную замену чаще белают на сервере (UPDATE ...) c переоткрытием DataSet.
Для реализации всего выше сказанного видимо надо переопределять Query, DataSet, DataSource и DBGrid. Так что правильно сказано, что жизнь тяжела.