Форум » Clipper » Clipper 5.3 не хочет работать с DBFCDX. » Ответить
Clipper 5.3 не хочет работать с DBFCDX.
AlexCh: Народ, помогите утопающему! Раньше писал на 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 то всё нормально линкуется и работает
Ответов - 32, стр:
1 2 All
ALGO: Извиняюсь, здесь уже ранее ответили на первый вопрос. По второму вопросу - в своей системе я также использую как CLIPPER (чаще), так и FOXPRO (реже и завязал с ним, поскольку у FOXPRO убийственный недостаток - максимальная размерность массива 2. Для алгоритмиста это дрова. Если знал бы сразу - вообще бы с FOXом не связывался). Но тем не менее несколько программ уже есть на FOXe. Однако не понимаю, зачем нужны общие индексы? В клиппере я использую NDX, а на FOXe - его долбаные IDX, DBF общие. Работа идет порознь - каждому своё. Или система столь монументальна, что идет непрерывным потоком изменение файлов с двух сторон? Боюсь, что нормального решения нет для разнородных систем, столь тесно работающих друг с другом на уровне индексов. А по поводу глюков по созданию CDX Клиппером единственный совет - это скинуть файл с минимальным тестовым примером без предметной части (прога + DBF + описание глюка (когда и как он проявляется), может кому и удасться докопаться до сути происходящего. По крайней мере у меня интерес возник.
Urri: Ответ на предыдущее письмо. _dbfcdx.lic конечно же прилинковываю, но это не помогает. Для реализации возникшего интереса можно взять первую попавшуюся .DBF и построить по любому индексному выражению .CDX клиппером и фоксом. Размер у индексов будет разным, не говоря уже о содержимом одинаковых якобы индексов. У фокса есть преимущество по сравнению с клиппером: намного быстрее работает с базой, а у меня задача на 400 тыс. абонентов, которых нужно каждый месяц массово пересчитывать. Тут бы фокс помог, а то бегаю по управлению, компьютеры ищу, которые можно на ночь оставить для расчета. Так что такая связка иногда весьма полезна
КСС: ...у меня задача на 400 тыс. абонентов... ...а то бегаю по управлению, компьютеры ищу, которые можно на ночь оставить для расчета. Конечно это не в тему, но при таком количестве абонентов и, стало быть, высокой ответственности, имеет смысл выделить отдельный сервер. Тогда на нём можно запускать сервисные задачи. Моя Клипперная прога, которой уже 13 лет, так и делает.
Andrey: Urri пишет: а у меня задача на 400 тыс. абонентов У меня задача раньше была на 150 тыс. абонентов. Считала целую ночь. Потом пределал алгоритм (долго делал) стала считать за 5 часов. Перешел на хХарбор. Считает 1,5-2 часа примерно. Так что Фокс, что Клиппер - пора переходить на нормальные компиляторы. А если руководство не понимает твоего труда - нужно менять руководство, или забить на работу. Чем раньше поймешь эту истину, тем легче будет жить дальше.
Urri: Смотрел я на хХарбор в начале его творческого пути, но не нашел тогда возможности прицепить к нему 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: Вот блин ! Берешь просто http://www.xharbour.org качаешь оттуда версию и все ! Я на этой версии уже почти год сижу !
ALGO: Провел тест для 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). Несмотря на кажущуюся простоту задачи, времени все же потребовалось немало, однако именно такие объективные сравнительные исследования представляют для меня значительный интерес. Ссылка на файл cdx.rar с тестом http://slil.ru/27376115
Andrey: ALGO пишет: Так что 2-4 часа времени на современной технике (и даже 30 мин.) - это "das ist fantastisсh" в моих понятиях. Проблема скорее всего или в неэкономном алгоритме Это не проблема, и не неэкономный алгоритм. Нормальный, по другому не получиться. Для понятия этого алгоритма нужно представить запись значений 24 сумм прихода денег, 24 дат прихода денег, 24 тарифов, 24 сумм начислений и т.д. в одну запись в базе. Так было еще мной на Клипере написано, и пока еще не переделывал, да и не буду наверно. Я видел как на платформе 1С версии 7.5 реализовали начисление коммунальных платежей, так там у 9.тыс. абонентов начисления делались порядка 5 часов. И ничего, никто не жаловался.
ALGO: Andrey пишет: Я видел как на платформе 1С версии 7.5... 1C прошу не упоминать
полная версия страницы