Собственно формулировка темы получилась немного кривоватой.
Похожую проблему где-то видел на форуме, но сейчас немогу найти.

есть месяц и пары чисел (начальные и конечные показания электросчётчика)


Поскольку обработка квитанций после сберкассы идёт вручную, то забить в базу могут в любом порядке.
Никакой ORDER BY тут не катит. Объём маленький всего 40-50 записей на одного абонента за три года(один, редко два, платежа в месяц). Массово всю базу(мильёны записей) сортировать не надо. Только одного абонента, когда он затребовал распечатку своих платежей. Мне нужна любая помощь(подсказка, ссылка) в написании алгоритма — либо на сервере средствами SQL, либо на клиенте в ClientDataSet`ах.

авторвыбрать в first_col, sec_col где first_col = sec_col
Согласен. Об этом думал. Выглядит очень даже логично, но если для каждого следующего first_col есть равный ему предыдущий sec_col. А если его нет - пропустили одну квитанцию (потеряли) при упаковке в сберкассе - распаковке у меня в операционном зале. В самом общем виде пока не дотягиваю.

>Johnmen
Я не спорю, какие-то дополнения должны быть. Но какие? Номер квитанции, который пропечатала сберкасса? Абонент может высыпать кучку квитанций и в каком порядке их обработает кассир неизвестно. Но на два полных оборота за один месяц можно не обращать внимания. Абонент с таким бешеным потреблением энергии это эксклюзив. Его выловим другим способом и поставим более мощный счётчик (другой модели) пусть потребляет - криминала нет. Красота и марафет в этом случае не нужны. Мне важно красоту и понятность навести для основной массы абонентов(большинство пенсионеры) чтобы они меньше тратили времени и быстрее понимали распечатку сравнивая со своими корешками квитанций. Вот корешки-то они сами отсортировали так как надо - можете быть уверены на 100 баллов.

ВАУ!!! vl2000 — родственная душа! Ты из какого Энерго?

Замену счётчика я разрулил и достаточно оптимально с точки зрения скорости БД. Интересует сортировка в пределах одного счётчика и лучше всего на клиенте.

vl2000причем два показания на одну дату не допускаются
Допускаютя! И ничего с этим не сделать. Особенно когда продвинутые абоненты платят через ИнтерНет с пластиковых карт. Тот кто разрабатывал сайт для оплаты предусмотрел только дневной и ночной тарифы и НЕ предусмотрел оплату 40 кВт на человека по базовому тарифу.
Поэтому абоненты в один день делают два платежа
1. 40 кВт на человека по базовому
2. Оставшиеся кВт-ы по экономически обоснованному - ёбтть
А потом это валится мне.

>vl2000
Наверное из НижНовЭнерго7

Оно самое.

Ну скажем, в середине месяца тарифы не меняются — по закону. Иначе население такое устроит, что министру, рискнувшему сменить тариф в середине месяца, придётся расстаться с креслом. А тариф будет отменён.
Абонент оплачивает потребление за конкретный месяц - это он указывает в квитанции. И проблема возникает, когда ...
Старый пример:
Раньше до 300 кВт был один тариф от 301 кВт другой тариф.
Хитрые абоненты, израсходовав в месяц 900 кВт, платили тремя квитанциями по 300 кВт в один день, указывая один и тот же месяц напр. май.
Все три квитанции попав в БД будут расчитаны правильно 300 и от 301 до 900.
Три раза по 300 кВт по маленькому тарифу это меньше чем 300 по маленькому и 600 по большому. Я ему насчитаю правильную задолженность, а он придёт качать права.
Проблема только в визуализации истории этих евойных платежей. Чтобы ему было проще увидеть, где я его ущучил. Если показания будут отсортированы как-то иначе (не логично и не последовательно) он начнёт скандалить, обвинять во всём компьютер и... (...баного Чубайса).
Проблема осложняется только двумя моментами
1. Произошёл оботот(переход) счётчика
2. При забивке в БД потерялась одна квитанция.
Мне по барабану эти осложнения и даже замена счётчика, расчитаю-то я всё-равно правильно. Главное показать (визуализировать).

Допущения типа в один месяц одна квитанция не проходят — это практика. Теория в данном случае никого не интересует. Должно быть так как на практике.