Clipper 5.3 не хочет работать с DBFCDX

Clipper 5.3 не хочет работать с индексом DBFCDX.

Раньше писал на Clipper Summer 87. 
Нужно на Clipper 5.3 создать индексный файл CDX, но не могу даже собрать exe-шник.
В начале программы вставил:
REQUEST DBFCDX
rddSetDefault( "DBFCDX" )
Линкую как в примере:
BLINKER FILE $(objs) OUTPUT $@ lib dbfcdx.lib

При сборке выдает ошибку :
BLINKER : 1115 : DBFCDX.LIB(CL53INIT) : '_DBFCDX' : unresolved external

Заменил BLINKER. 
Стал пробовать собирать BLINKERом 6.0
то же самое.

Что интересно, если вместо DBFCDX подключать к примеру DBFNDX, т.е.
в программе
REQUEST DBFNDX
rddSetDefault( "DBFNDX" )
а затем
BLINKER FILE $(objs) OUTPUT $@ lib dbfndx.lib
то всё нормально линкуется и работает 


По второму вопросу - в своей системе я также использую как CLIPPER (чаще), так и FOXPRO (реже и завязал с ним, поскольку у FOXPRO убийственный недостаток - максимальная размерность массива 2. Для алгоритмиста это дрова. Если знал бы сразу - вообще бы с FOXом не связывался). Но тем не менее несколько программ уже есть на FOXe. Однако не понимаю, зачем нужны общие индексы? В клиппере я использую NDX, а на FOXe - его долбаные IDX, DBF общие. Работа идет порознь - каждому своё. Или система столь монументальна, что идет непрерывным потоком изменение файлов с двух сторон? Боюсь, что нормального решения нет для разнородных систем, столь тесно работающих друг с другом на уровне индексов.
А по поводу глюков по созданию CDX Клиппером единственный совет - это скинуть файл с минимальным тестовым примером без предметной части (прога + DBF + описание глюка (когда и как он проявляется), может кому и удасться докопаться до сути происходящего.
По крайней мере у меня интерес возник.

Ответ на предыдущее письмо. _dbfcdx.lic конечно же прилинковываю, но это не помогает.

Для реализации возникшего интереса можно взять первую попавшуюся .DBF и построить по любому индексному выражению .CDX клиппером и фоксом.
Размер у индексов будет разным, не говоря уже о содержимом одинаковых якобы индексов.

У фокса есть преимущество по сравнению с клиппером: намного быстрее работает с базой, а у меня задача на 400 тыс. абонентов, которых нужно каждый месяц массово пересчитывать. Тут бы фокс помог, а то бегаю по управлению, компьютеры ищу, которые можно на ночь оставить для расчета. Так что такая связка иногда весьма полезнаКСС: ...у меня задача на 400 тыс. абонентов... ...а то бегаю по управлению, компьютеры ищу, которые можно на ночь оставить для расчета. Конечно это не в тему, но при таком количестве абонентов и, стало быть, высокой ответственности, имеет смысл выделить отдельный сервер. Тогда на нём можно запускать сервисные задачи. Моя Клипперная прога, которой уже 13 лет, так и делает.

Andrey: Urri пишет: а у меня задача на 400 тыс. абонентов У меня задача раньше была на 150 тыс. абонентов. Считала целую ночь. Потом пределал алгоритм (долго делал) стала считать за 5 часов. Перешел на хХарбор. Считает 1,5-2 часа примерно. Так что Фокс, что Клиппер - пора переходить на нормальные компиляторы. А если руководство не понимает твоего труда - нужно менять руководство, или забить на работу. Чем раньше поймешь эту истину, тем легче будет жить дальше.

Смотрел я на хХарбор в начале его творческого пути, но не нашел тогда возможности прицепить к нему ADS, без которого сейчас себе не мыслю работы для своих больших по размеру баз (корректность индексов и транзакции дорого стоят). Если знаешь как подружить с ADS - подскажи пожалста и дай ссылку где взять стабильно работающий хХарбор. Я постараюсь поднять на нем расчетную часть - может полегчает.

На нормальный компилятор переходить, говоришь? Это при том, что 60% машин (из 300) такие, что половину из них w98 с трудом тянут, а другая половина - w95 только поддерживает с 14" мониторами и разрешением 640*480... Что, на VBasic-4? А руководство сейчас трудно поменять - кругом кризис однако, работодатели программистов сейчас не жалуют. Или у вас в регионе по-другому?Pasha: Поддержка Ads в харборе есть. Харбор с Ads подружился даже раньше, чем с DBFCDX, т.е. рабочмй rdd для Ads был готов, когда DBFCDX был еще глючный

Andrey: Urri пишет: что половину из них w98 с трудом тянут, а другая половина - w95 только поддерживает с 14" мониторами и разрешением 640*480... Что, на VBasic-4? Так хХарбор даже на w98 - 95 работать НАМНОГО стабильней и быстрей будет. Я тоже очень сомневался раньше, а сейчас просто думаю почему мне никто раньше его (хХарбор) не показал !!! Задача из Клипера в хХарбор переноситься просто компиляцией, но могут быть заморочки, но небольшие. Проблемы будут, подскажем. Я уже систем 5 своих и 3 чужих пренес !!! Чужие даже легче пошли, за неделю делал !

Urri: Уважаемые (вместе с модератором Pasha)! Вы не дразнитесь, а ссылку дайте на стабильный релиз хХарбора и rdd для ADS и где что можно почитать. Пожалста. Очень нужно

Andrey: Вот блин ! Берешь просто xharbour качаешь оттуда версию и все ! Я на этой версии уже почти год сижу !

Провел тест для clipper 5.3, Blinker 1.0 и FoxPro 8.
Имеются два одинаковых файла testclp.dbf и testfox.dbf
с полями NAME, NAME1 - C(10), NUMBER, NUMBER1, SUMMACLP, SUMMAFOX - N(10).
Специальная программа fill.exe <кол-во записей> заполняет оба эти файла таким образом:
NAME=A000000001, NUMBER1=1 для 1-й записи,
NAME=A000000002, NUMBER1=2 для 2-й записи и т.д.
Поля NAME1 и NUMBER1 заполняются аналогично, но в обратной оследовательности, т.е. указанные значения будут иметь последняя и предпоследняя записи и т.д. Поля SUMMAFOX и SUMMACLP программой fill.exe не заполняются.
Далее имеются две аналогичные программы на CLIPPER (testclp.exe) и на FoxPro (testfox.exe). Для testclp.exe (clipper) задача следующая:
а) проиндексировать файл testclp.dbf по полю NAME (tag FLD)
и по полю NAME1 (tag FLD1), создав при этом "свой" индекс testclp.cdx;
б) пройтись по файлу testfox.dbf и, пользуясь созданным в а) индексным файлом, для каждой строки из testfox.dbf по значению NAME отыскать строку в файле testclp.dbf, у которой такое же поле NAME и прибавить поле NUMBER из этого файла к полю SUMMACLP из testfox.dbf; затем по этому же значению NAME отыскать еще одну строку в файле testclp.dbf, у которой такое же поле NAME1 и вычесть из поля SUMMACLP testfox.dbf.
в) пройтись по файлу testclp.dbf и, пользуясь индексным файлом testfox.cdx, созданным другой программой (testfox.exe - FoxPro),
для каждой строки из testclp.dbf по значению NAME отыскать строку
в файле testfox.dbf, у которой такое же поле NAME и прибавить поле NUMBER
из этого файла к полю SUMMACLP из testclp.dbf; затем по этому же значению NAME
отыскать строку в файле testfox.dbf, у которой такое же поле NAME1 и
вычесть из поля SUMMACLP testclp.dbf.
Для testfox.exe (FoxPro) аналогичная задача:
а) проиндексировать файл testfox.dbf по полю NAME (tag FLD)
и по полю NAME1 (tag FLD1), создав при этом "свой" индекс testfox.cdx;
б) пройтись по файлу testclp.dbf и, пользуясь созданным в а) индексным файлом, для каждой строки из testclp.dbf по значению NAME отыскать строку в файле testfox.dbf, у которой такое же поле NAME и прибавить поле NUMBER из этого файла к полю SUMMAFOX из testclp.dbf; затем по этому же значению NAME отыскать строку в файле testfox.dbf, у которой такое же поле NAME1 и вычесть из поля SUMMAFOX testclp.dbf.
в) пройтись по файлу testfox.dbf и, пользуясь индексным файлом testclp.cdx, созданным другой программой (testclp.exe - Clipper),
для каждой строки из testfox.dbf по значению NAME отыскать строку
в файле testclp.dbf, у которой такое же поле NAME и прибавить поле NUMBER
из этого файла к полю SUMMAFOX из testfox.dbf; затем по этому же значению NAME
отыскать строку в файле testclp.dbf, у которой такое же поле NAME1 и
вычесть из поля SUMMAFOX testfox.dbf.
Таким образом, при правильной работе обе программы должны к каждому полю каждого файла прибавить и вычесть одно и то же число (хотя и расположенные в разных записях), и в результате при правильной работе системы должны остаться нулевые значения в полях SUMMACLP и SUMMAFOX в обоих файлах.
Тест проводился для 100000 и 400000 записей, и не смотря на разный размер индексных файлов, дал правильный результат. Единственное что - при добавлении записей один из индексных файлов ("чужой") остается неправильным, поэтому при первом запуске каждая из программ выполняет только работу со "своим" индексом, и не выплняет с "чужим". После запуска второй программы оказываются правильно проиндексированными оба файла и обе программы начинают работать без сбоев (аналогично при уменьшении кол-ва записей, но при этом FoxPro вылетает в error на чужом индексе, и мне пришлось применить обработчик ON ERROR... Но это из-за того, что изменение кол-ва записей производится fill.exe без открытия обоих индексов, а также из-за того, что каждая из программ не переиндексирует чужой индекс (т.е. эта
проблема искусственно создана - иначе и не должно быть). Если разрешить FoxPro выполнить переиндексацию чужого индекса - тогда нормальная работа восстанавливается. Далее "совершенствовать" систему обработок ошибок я не стал, чтобы обе программы не сильно отличались друг от друга.
Итог следующий:
1) У меня сначала был Clipper 5.3 без патча (и я на нем уже давно работаю). Он действительно давал сбои: начиная где-то с 40000 записей, иногда работал нормально, иногда зависал, иногда вылетал с ошибкой (типа программа выполнила недопустимую операцию) в начале программы при попытке проиндексировать "свой" CDX. Как советуют здесь на форуме, сделал патч до 5.3b - всё заработало нормально. Но и до патча глюки были не в том смысле, что не понимались индексы FoxPro - без переиндексирования (когда оба индеса создавались FoxPro) обработка нормально выполнялась, CLIPPER валился на создании "своих" индексов.
2) для современных CУБД 400000 записей - не очень много. Как
видно из результатов теста, обработка всего файла со случайным поиском
занимает 2-3 минуты максимум даже на несколько устаревших компьютерах. Так что 2-4 часа времени на современной технике (и даже 30 мин.) - это "das ist fantastisсh" в моих понятиях. Проблема скорее всего или в неэкономном алгоритме, или в узких местах типа пропускной способности сети (из-за повального увлечения архитектурой клиент-сервер, к чему я отрица- тельно отношусь - но это оффтоп). 3) Как видно из результатов теста, время на создание индекса незначительно по сравнению с общим временем работы, так что лучше всего перед началом обра- ботки файлов индексы создавать заново, не доверяя ранее созданным "чужим" и "своим"индесам (если только они не используются в этот момент другими программами).
Каждая из программ в случае нормальной обработки файлов сообщает время (в сек.), потребовавшееся для:
- создания "своего" индекса (пyнкт а);
- обработки файла по "своему" индексу (пункт б);
- обработки файла по "чужому" индексу (пункт в);
- общее время работы (сюда добавляется еще время на заполение полей
SUMMAFOX и SUMMACLP нулевыми значениями в обоих файлах).
Прилагается архив:
info.doc - результаты эксперимента по времени выполнения.
fill.prg - текст вспомогательной программы на clipper для заполнения файлов.
calc.prg - текст clipper-программы.
program1.prg - текст FoxPro-программы.
makefill.bat - создает fill.exe (немного подкорректировать придется)
makecalc.bat - создает testclp.exe (тоже самое).
proj1.pjx - файл проекта на FoxPro.
testfox.dbf и testclp.dbf - файлы с данными (созданные в DBU).
testclp.cdx - индексный файл, создаваемый CLIPPERом.
testfox.cdx - инрексный файл, создаваемый FoxPro.
fill.exe - программа для заполнения файлов.
testclp.exe - программа на CLIPPERе.
testfox.exe - программа на FoxPro.
Для testfox.exe потребуется runtime environment (от VFP6
скорее всего не подойдет, так что придется использовать текст из program1.prg
и возможно тоже подкорректировать).
Для сокращения объема архива файлы dbf содержат по 10 записей, для проведения реальных испытаний следует число записей увеличить.
Если в наличии CLIPPER 5.2, то также придется подкорректирвоать fill.prg и саlc.prg.
Тесты для CLIPPER'87, CLIPPER 5.2 и VFP6 попробую выполнить несколько позже, поскольку c этими версиями не работаю и сейчас в рабочем состоянии их нет
(а также перекрестные тесты типа CLIPPER 5.2 <-> VFP8 и CLIPPER 5.3 <-> VFP6).
Несмотря на кажущуюся простоту задачи, времени все же потребовалось немало, однако именно такие объективные сравнительные исследования представляют для меня значительный интерес.Andrey: ALGO пишет: Так что 2-4 часа времени на современной технике (и даже 30 мин.) - это "das ist fantastisсh" в моих понятиях. Проблема скорее всего или в неэкономном алгоритме Это не проблема, и не неэкономный алгоритм. Нормальный, по другому не получиться. Для понятия этого алгоритма нужно представить запись значений 24 сумм прихода денег, 24 дат прихода денег, 24 тарифов, 24 сумм начислений и т.д. в одну запись в базе. Так было еще мной на Клипере написано, и пока еще не переделывал, да и не буду наверно. Я видел как на платформе 1С версии 7.5 реализовали начисление коммунальных платежей, так там у 9.тыс. абонентов начисления делались порядка 5 часов. И ничего, никто не жаловался.