проблемы с сортировкой в таблице

[moshkin]

У меня такая проблема: есть код на VB. В нем сначала данные сортируются а потом выгружаются из отсортированной таблицы в файл. Проблема в том что на одной и той же машине с одим и тем же программным обеспечением данные иногда выгружаются правильно а иногда нет. То есть: правильно это так - 0123456789 - отсортированы по порядку. А неправильно так - 01267834590. То есть чаще всего один большой кусок данных перелазит на другое место. Я его потом руками копирую и все становится нормально. Почему такое может быть? Данных много - файл около 300-400 Мб. Записей в исходной таблице 2-3 миллиона.
Куски кода:
сортировка:
cmd.CommandText = "INSERT INTO Itogi ( numberWho, MinuteCount, CallCount, NumberUnload )" & _
" SELECT temp1.numberwho, Sum(temp1.timespus) AS [Sum-timespus], " & _
"Count(temp1.timespus) AS [Count-timespus], " & KodUnload & _
" AS Выражение1заи From temp1 GROUP BY temp1.numberwho, " & KodUnload & _
" ORDER BY temp1.numberwho"
Set Rst = cmd.Execute()

и выгрузка последовательно всех записей:
Rst.Open "select * from Itogi where itogi.numberunload=" & CLng(a(0)), cn, adOpenDynamic, adLockOptimistic
Do
s = la1 & "," & CStr(Rst!NumberWho) & "," & la2 & "," & rstUnload!DataUnload & "," & Rst!CallCount & "," & Rst!MinuteCount & ":"
Print #1, s
Rst.MoveNext
Loop Until Rst.EOF
Rst.Close

Почему такое происходит?
Такое ощущение что просто комп не успевает иногда отсортировать.
Подскажите пожалуйста.
Спасибо.

[alibek]

Может быть поле numberwho имеет не числовой тип, а строковый?
И еще попробуй поменять adLockOptimistic, на другой (например Pessimistic). А заодно и тип курсора смени на ForwardOnly, быстрее работать будет.

[moshkin]

Да. Поле numberwho имеет текстовый тип - оно сначала было числовым. Но поле содержит номера телефонов а там иногда попадается всякая фигня (то есть полный бред со станции) не говоря уже о номерах 08, 01 и т.п. Мне казалось что разницы нет. Или я не прав? Но ведь иногда работает!
На pessimistic поменяю.
А вот про тип курсора не понял - если не трудно чуть подробнее.
Спасибо.

[alibek]

Ты открываешь курсор, как adOpenDynamic. Это самый "ресурсоемкий" тип, хотя и реализует максимальную функциональность. Если указать adForwardOnly (вроде бы так, точно не помню), то полученный рекордсет можно будет просматривать только сверху вниз, будет доступен только метод MoveNext. Но ты все-равно только его и используешь, поэтому имеет смысл использовать менее функциональный тип рекордсета.
В типе блокировки (который у тебя adLockOptimistic) можно указать adLockReadOnly (или adReadOnly), это также снизит "ресурсоемкость" (ты ведь все-равно не модифицируешь полученный рекордсет).
А вообще у рекордсета есть пара методов, Save и GetString, которые сильно упростят тебе жизнь (не придется делать перебор строк в цикле).

А насчет типа данных ты не прав, это влияет очень сильно.
Попробуй преобразовывать все в число (val(), to_number()), если ошибки будут игнорироваться, это должно помочь.

P.S. Я так понял, что БД - это звонки (в АТС)?
Я бы тогда советовал разбить обработку на два этапа.
В первом проходится процедура и весь брак (глючные звонки) переносит в другую таблицу (например, BAD_CALLS). А для специальных номеров в таблицу можно добавить поле (например, SPECIAL).
После этого выполняется второй этап, сортировку можно усложнить, т.е. сортировать по двум полям, вначале по SPECIAL, потом по numberwho, причем поле numberwho приводится к числовому типу.

P.P.S. А если это номера телефонов, зачем вообще их сортировать?

[moshkin]

- Про курсор понял, спасибо.
- Это действительно БД телефонных звонков. Это делалось для вычисления повременки нашего города. Делалось в спешке , а опыта у меня тогда было еще меньше чем сейчас.
Попробую применить на практике полученные советы и пробовать. А сортируются там только итоги, то есть итоговые результаты должны быть по порядку возрастания номеров.
И еще: что-то мне кажется что если телефонный номер будет очень большой то он не влезет в числовое поле (более 20 символов).
Больше вопросов нет.
Большое спасибо за ответы - понятные и по делу!