crt_ind.exe -l f:\database\b02 4
! Естественно! Не забудьте полученными файлами заменить настоящий индекс, т.е. f:\database\b0200004.* до того, как будет сделана первая коррекция данных :-)
На базе телефонов г.Киева (больше 1млн. записей) по полю "номер телефона" процес построения занял меньше 8 минут (БД находился на сетевом диске). Про то, как быстро это делает "Кронос" я промолчу... (но больше 8 часов). Если же перетянуть банк в "Кронос Плюс", то построение этого индекса проходит
за 11 мин. 30 сек (при этом БД был на локальном диске). (Все тесты проводились на Celeron 416 (83*5), 64 Mb (локальный диск быстрее сети)).
Ограничения:
Это самая первая работающая версия программы, поэтому существует ряд ограничений на ее использование.
1. Программа не умеет устанавливать признак наличия индекса по требуемому полю (если он вообще где-то устанавливается), так что, созданные индексы "Кронос" видеть не должен (как на самом деле я не проверял). Советую с помощью "Кроноса" в описании индексных массивов поставить "+" на наличии индекса, а построение не запускать, а сделать это с помощью программы. Если индекс был, а Вы хотите
его обновить - то в самый раз запустить программу, а созданными файлами заменить существующие.
2. В файл данных "Кроноса" *.dat в первые 512 байт записывается какая-то "отбалдовая" информация, суть которой понять я пока не могу, да вроде и не надо. В заново построенном индексе ненулевые только с 1 по 17 байты. Если Вы не хотите лишний раз рисковать, то расскажите мне, что там лежит, или
скопируйте эти 16 байт из Вашего индексного файла в созданный программой. Я пока не обнаружил, на что это может влиять. Все и так работает.
3. В связи с тем, что сортировка ведется в dbf-файле, длину поля пришлось ограничивать. Мне лень пока задавать дополнительный вопрос из программы, о "Максимальной длине индекса", а в случае отказа смотреть в описания баз, да еще и ограничиваться длиной 250 (как это сделано в "Кроносе"), так что
в этой версии максимальная длина индекса 25 символов. Кроме того, поле, по которому строится индекс должно быть НЕ ЦИФРОВЫМ, или значения поля во всех записях должны иметь одинаковую длину. Это связано только с тем, что сортировка цифровых полей ведется после выравнивания по правому краю,
а текстовых по левому. Собственно, переписав программу sort.exe, можно добиться того, что в поле NAME будут находиться значения, выровненные по правому краю и дополненные лидирующими нулями, тогда, после сортировки этих значений, индекс создастся правильно и для числового поля.
4. Не строится индекс "по словам" т.к. для этого, все же, не мешало бы заглянуть в описание структуры, на предмет неиндексируемых символов, а это я пока не сделал.
5. Возможно, главное ограничение! Все версии "Кроноса", которые я видел, имеют одинаковую процедуру шифрования данных. Шифрование проводится с помощью таблицы подстановок, зашитой в одном из системных файлов "Кроноса". Вполне возможно, что у Вас эта таблица отличается от той, которая у меня, тогда действия программы будут непредсказуемы... :-) Ести Вы знаете, о чем идет
речь, то легко сможете достать свою таблицу (там 2по256байт), найти в программе мою и провести обмен :-) И все у Вас заработает...
6. Программа тестировалась не банке данных, в который понагрузилась куча всего из разных dbf, посливалась, поисправлялась, поудалялась. После чего поиск "OT ТФ01 01 ОЗ" (т.е. одинаковые значения по номеру телефона) просто регулярно валился во внутренний отладчик. После перестроения индексов все летает наура, но я не пробовал после этого корректировать что-либо ;-) - пробуйте сами, должно работать...
7. Да, и еще. В программе умышленно отсутствует интерфейс с пользователем и автоматическая замена индексных файлов при перестроении. Лучше, чтобы эту процедуру выполняли только те, кто в состоянии разобраться с этим read.me.
Возможно, программа нарушает чьи-то авторские права (на что?), но если это так, попробуйте меня в этом убедить. (Доступ к банку без пароля? - в следующих версиях исправлю...) Будем считать, что делал ее я для себя :-), ковырянием исключительно в данных, а не в коде "Кроноса". Если кто в этот код заглядывал, - то, думаю, поддержит меня во мнении, что там черт ногу сломит... Видимо это вызвано утсутствием (у меня?) декомпилятора с Advanced Revelation?
Все предложения принимаются, обдумываются, м.б.внедряются...
Мой E-Mail sergey@srg.cscd.lviv.ua - но во Львове я сейчас редко бываю,
все больше в Киеве, так что лучше писать на sedinkin@mail.ru
