Отправлено: 11.08.13 18:47. Заголовок: Перехожу с Clipper 5.2e на Harbour, список вопросов от "новичка"

Добрый день, уважаемые коллеги.

Большое спасибо за море справочной информации по переходу, но нужно ещё пнуть меня в нужном направлении.

Итак, установил Harbour 3.0 + BCC 5.5.1 ==>> 3.2.0 +minGW скомпилировал и запустил традиционный "Hello, world!"
Дело перешло к проекту, из-за которого собственно и речь. Компилируется что через hbmk2, что самим харбором - без ошибок, всего с парой предупреждений, что меня немало удивило.
Возникли ошибки на этапе линковки:

Скрытый текст

Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland Error: Unresolved external '_HB_FUN_ENVPARAM' referenced from D:\HB\TRADE100.OBJ Error: Unresolved external '_HB_FUN_INKEYTRAP' referenced from D:\HB\TRADE226.OBJ Error: Unresolved external '_HB_FUN_DISKFREE' referenced from D:\HB\TRADE222.OBJ Error: Unresolved external '_HB_FUN_DISKTOTAL' referenced from D:\HB\TRADE222.OBJ Error: Unresolved external '_HB_FUN_BIOSDATE' referenced from D:\HB\TRADE.OBJ Error: Unresolved external '_HB_FUN_FT_ONTICK' referenced from D:\HB\TRADE.OBJ Error: Unresolved external '_HB_FUN_FT_ONIDLE' referenced from D:\HB\TRADE200.OBJ Error: Unresolved external '_HB_FUN_FT_IAMIDLE' referenced from D:\HB\TRADE200.OBJ Error: Unresolved external '_HB_FUN_TRAPANYKEY' referenced from D:\HB\TRADE200.OBJ Error: Unresolved external '_HB_FUN_KEYSEND' referenced from D:\HB\TRADE200.OBJ 1) Так понимаю, это ошибки из-за того, что не находятся некоторые функции из активно используемых CT3/Nanforum Toolkit ? Что делать с ними ? Отказываться ? Или есть заменители ? Error: Unresolved external '_HB_FUN_STACKFREE' referenced from D:\HB\TRADE200.OBJ Error: Unresolved external '_HB_FUN_BLILOCUSE' referenced from D:\HB\TRADE200.OBJ Error: Unresolved external '_HB_FUN_BLILOCAVL' referenced from D:\HB\TRADE200.OBJ Error: Unresolved external '_HB_FUN_BLILOCTOT' referenced from D:\HB\TRADE200.OBJ Error: Unresolved external '_HB_FUN_BLISTCUSE' referenced from D:\HB\TRADE200.OBJ Error: Unresolved external '_HB_FUN_BLISTCAVL' referenced from D:\HB\TRADE200.OBJ Error: Unresolved external '_HB_FUN_BLISTCTOT' referenced from D:\HB\TRADE200.OBJ 2) Это - ошибки из-за вызовов встроенных в Blinker функций, без них легко обойтись в принципе... Error: Unresolved external '_HB_FUN_STRNUM2ARRAY' referenced from D:\HB\TRADE208.OBJ Error: Unresolved external '_HB_FUN_CMJS_EXTRACTPARAMS' referenced from D:\HB\TRADE206.OBJ Error: Unresolved external '_HB_FUN_SELECTSTOCKS' referenced from D:\HB\TRADE220.OBJ Error: Unresolved external '_HB_FUN_APPLYSERTCHAGES' referenced from D:\HB\TRADE221.OBJ Error: Unresolved external '_HB_FUN_APPLYCARGOCHAGES' referenced from D:\HB\TRADE221.OBJ Error: Unresolved external '_HB_FUN_APPLYPRICECHAGES' referenced from D:\HB\TRADE221.OBJ 3) А вот это - самое странное - это мои функции, причем некоторые из них вызываются многократно из других модулей. Например ApplyCargoChanges является STATIC в самом модуле TRADE221 - почему линковщик ее не видит, наряду с парой Apply... других ? SelectStocks активно используется в других модулях - но там линкер почему-то ошибок не видит...

Help, please - что делать и куды бечь ?

 Отправлено: 10.09.13 08:09. Заголовок: Sergy пишет: Загвоз..

Sergy пишет:

цитата:

Загвоздка оказалась в команде RUN. Как она может повлиять на SAVESCREEN() - ума не приложу.

Харбор-программа разделяет консоль с внешним приложением (cmd.exe), которое изменяет какие-то параметры консоли.

 Отправлено: 10.09.13 09:07. Заголовок: Sergy Вместо RUN по..

Sergy
Вместо RUN поюзай hb_processrun , WAPI_ShellExecute , EXECANDWAIT

 Отправлено: 10.09.13 13:51. Заголовок: Делаем тест: Local ..

Делаем тест:

#include "hbgtinfo.ch"

proc main

Local i, j, cc

REQUEST HB_CODEPAGE_RU866
REQUEST HB_LANG_RU866
hb_cdpSelect( "RU866" )

cls
//hb_gtinfo(HB_GTI_COMPATBUFFER, .f.)
for i := 0 to 15
cc := ''
for j := 0 to 15
cc += Chr(i*16 + j)
next
@ i, 0 say cc
next
cc := SaveScreen(0,0,15,15)
RestScreen(0,20,15,35,cc)
run('dir >nul')
cc := SaveScreen(0,0,15,15)
RestScreen(0,40,15,55,cc)
wait
retu

На экране видим бяку на месте кодов меньше 32
А теперь фокус-покус: добавляем вызов

hb_gtinfo(HB_GTI_COMPATBUFFER, .f.)

и все исправляется. Только при этом буфер для savescreen/restscreen будет в 2 раза больше.

 Отправлено: 10.09.13 14:14. Заголовок: Ну да: HB_GTI_COMPAT..

Ну да:
HB_GTI_COMPATBUFFER /* Use DOS CGA/EGA/VGA character/attribute buffer in SAVE/REST SCREEN */

 Отправлено: 10.09.13 18:01. Заголовок: Pasha пишет: На экр..

Pasha пишет:

цитата:

На экране видим бяку на месте кодов меньше 32 А теперь фокус-покус: добавляем вызов hb_gtinfo(HB_GTI_COMPATBUFFER, .f.) и все исправляется. Только при этом буфер для savescreen/restscreen будет в 2 раза больше.

Пока остановился на замене #define RUN(x) HB_ProcessRun(x) - SAVESCREEN заработал нормально. Понятно, что под Windows памяти дофига - но жалко же какой смысл ее транжирить...

 Отправлено: 11.09.13 11:04. Заголовок: Sergy пишет: #defin..

Sergy пишет:

цитата:

#define RUN(x) HB_ProcessRun(x)

Так не пойдет - только что наступил на грабли: не выполняются команды shell - dir, copy, ren и тп... При этом не выдаются никакие сообщения об ошибке. Просто игнор и всё.

Нужно вот так: #define RUN(x) HB_ProcessRun("cmd /c "+x)

буффер не портится и команды command shell выполняются.

 Отправлено: 11.09.13 11:11. Заголовок: Sergy пишет: При эт..

Sergy пишет:

цитата:

При этом не выдаются никакие сообщения об ошибке. Просто игнор и всё.

Оно пишется в 3-й параметр этой функции если его указать

Sergy пишет:

цитата:

не выполняются команды shell - dir, copy, ren и тп...

А зачем ? Все это можно делать средствами Harbour

 Отправлено: 11.09.13 12:04. Заголовок: А почему нельзя сох..

А почему нельзя сохранять экран ДО команды RUN ? Так было бы логичнее.

 Отправлено: 11.09.13 13:22. Заголовок: nick_mi пишет: А по..

nick_mi пишет:

цитата:

А почему нельзя сохранять экран ДО команды RUN ? Так было бы логичнее.

Изначально вопрос стоял так: в процессе перехода с Clipper на Harbour были устранены шероховатости и программа была запущена в работу на предприятии. Все возникающие в процессе работы вопросы решались, за исключением непонятки, "портившей" символы с кодом ниже CHR(32) при восстановлении на экран.

После детального изучения вопроса (а версии возникали самые разные - они описаны тут, на пред. страницах) выяснилось, что уже SAVESCREEN возвращает "испорченный" буфер экрана. Пошаговое выполнение программы привело к выяснению причины - ею оказалась команда RUN().

Понятно, что анализировать сотни/тысячи строк кода и выяснять, где идет RUN(), а потом SAVESCREEN() вряд-ли имеет смысл и решение с #define кажется мне на сегодня вполне достаточным.

 Отправлено: 11.09.13 13:26. Заголовок: Dima пишет: А зачем..

Dima пишет:

цитата:

А зачем ? Все это можно делать средствами Harbour

Безусловно. Но речь идет о запуске тысяч строк кода Clipper под Harbour, а не его переделке "с учетом возможностей".

А в Clipper, к примеру, невозможно было работать нормально с каталогами/файлами, не соответствующими формату 8.3.
Да и в Harbour сейчас проще записать RUN("del local\*.dbf >nul") чем городить такой огород:
dim:=DIRECTORY(cPath,"*.dbf") ; AEVAL(dim,{|x| cPath+x[F_NAME]...}).

 Отправлено: 16.09.13 12:37. Заголовок: Решил поднять старую..

Решил поднять старую тему: http://clipper.borda.ru/?1-20-0-00000475-000-0-0-1208757116

Речь в ней идет о DIRTYREAD/TURBOREAD/DBOI_READLOCK

Подскажите плиз - к каким все-таки результатам приводит включение этого "ускорителя" ?

Общая ситуация такая: есть куча пользователей, которые что-то пишут в таблицу с продажами.
Есть пара пользователей, которые на основании таблицы продаж в READONLY режиме хотят построить отчет.

Вот тут я немного не понял, чем все кончилось, а тема закрыта: если я у этой пары пользователей ("читателей") включу dbOrderInfo(DBOI_READLOCK,,, .t.) - что, помимо ускорения выборки, произойдет? Если в таблице за время построения отчета появятся какие-то записи - "читателям" по барабану: отчеты обычно строятся за прошлые периоды, изменение которых юзерам запрещено программно.

Будут ли ошибки у "читателей" таблицы? Или у "писателей" в неё?

Спасибо.

 Отправлено: 16.09.13 13:46. Заголовок: Отчеты за прошлые периоды

Если технология - файл-серверная и
данные за прошлые периоды не изменяются, зачем нагружать доступ ко всей базе "грязным" чтением ?
Можно сверить текущую базу с предыдущей локальной выборкой( копией ) и строить отчеты
по локальной копии продаж, не нагружая рабочую базу.
Создание файла локальной копии происходит гораздо быстрее и менее напряжно, чем подготовка отчетов по общей базе,
и в общем случае, затраты ресурсов и времени на создание локальной копии окупаются.
Заодно - получается точная фиксация "точки отсечения" - на какой момент фиксировано состояние продаж.
if local_file_not_exist or local_file_is_old ;use .. shared readonly; copy to (local_file) for ..; close ..

 Отправлено: 16.09.13 14:13. Заголовок: Sergy пишет: Вот ту..

Sergy пишет:

цитата:

Вот тут я немного не понял, чем все кончилось, а тема закрыта: если я у этой пары пользователей ("читателей") включу dbOrderInfo(DBOI_READLOCK,,, .t.) - что, помимо ускорения выборки, произойдет? Если в таблице за время построения отчета появятся какие-то записи - "читателям" по барабану: отчеты обычно строятся за прошлые периоды, изменение которых юзерам запрещено программно. Будут ли ошибки у "читателей" таблицы? Или у "писателей" в неё?

DBOI_READLOCK касается только выборки по управляющему индексу.
Если этот параметр включен, то на время включения другие клиенты не смогут ничего ни прочитать, ни записать в рабочую область, т.к. индекс блокируется для чтения. Внешне это будет выглядеть как "зависание" клиента. Поэтому использовать эту опцию надо аккуратно, и на очень непродолжительное время. Можно сделать тест:

dbOrderInfo(DBOI_READLOCK,,, .t.)
wait

и попробовать с другого клиента выдась go top/skip, и посмотреть, что получится. Ничего хорошего, естественно.
Это все проблемы файл-сервера. Для клиент-сервера вроде ads/letodb такой проблемы нет в принципе.

 Отправлено: 16.09.13 23:03. Заголовок: petr707, Pasha Мысл..

petr707, Pasha Мысли понятны. С letodb скоро разберусь. И загрузку локально для справочников я провожу всегда, практически с первого дня написания программы. Для большой кучи отчетов (в начале месяца, например) есть функция "работать локально" - через 5-7 минут ожидания (пока вся база скопом копируется в локальную папку) - программа работает с ней, как ни в чем не бывало, но в READONLY - чтобы никто не навыписывал по забывчивости накладных.

А вот если юзеру нужно всего один-два отчета, не окажется ли процесс "копирование всей таблицы продаж + локальная индексация" длительнее, чем просто чтение нужного периода по индексу ? Т.е. овчинка не будет стоить выделки... Думал, что DBOI_READLOCK поможет ускорить чтение по индексу.

Спасибо.

 Отправлено: 17.09.13 02:16. Заголовок: Уже перешел на Харбо..

Уже перешел на Харбор ! Поздравляю !
Sergy пишет:

цитата:

А вот если юзеру нужно всего один-два отчета, не окажется ли процесс "копирование всей таблицы продаж + локальная индексация" длительнее, чем просто чтение нужного периода по индексу ?

Для различных выборов из баз, делай условную индексацию по уже сформированным индексам.
Отчеты будут строиться влет, даже не успеешь заметить...
Здесь на форуме обсуждалось это, и не раз.

 Отправлено: 17.09.13 06:33. Заголовок: все можно проверить..и нужно проверять

для каждой задачи можно проверить и выбрать подходящую схему..
set order to 0; copy to () for...; index on ...
может оказаться быстрее чем
index on ...; copy to () for...;

 Отправлено: 17.09.13 08:33. Заголовок: Sergy пишет: Думал,..

Sergy пишет:

цитата:

Думал, что DBOI_READLOCK поможет ускорить чтение по индексу.

Сергей, я подзабыл эти вещи, и неправильно написал: DBOI_READLOCK блокирует выборку на запись с других клиентов, а не на чтение. А так да, когда я использовал DBFCDX, установка DBOI_READLOCK меня реально выручала. В сетевом окружении скорость выборки возрастала многократно.
Что же касается остальных вариантов, то надо иметь в виду: все эти приемы: динамическое построение индекса, или индекса с условием, или копирование таблицы с set order to 0 для больших таблиц неприемлемы, поскольку предполагают цикл по всем записям, что быстрым быть не может. Надо применять обычное решение: иметь правильный набор индексов для возможных выборок, и использовать их. Для файл-сервера DBOI_READLOCK реально помогает. Проблем из-за его использования у меня не было. Только, как я отмечал, его надо использовать аккуратно.

 Отправлено: 17.09.13 10:08. Заголовок: Pasha пишет: DBOI_R..

Pasha пишет:

цитата:

DBOI_READLOCK блокирует выборку на запись с других клиентов, а не на чтение.

Требуется уточнение: блокирует именно те записи, по которым идет чтение или целиком запись в индексный файл ?

Тк первый вариант для меня подходит, а второй - нет.

 Отправлено: 17.09.13 10:15. Заголовок: Andrey пишет: Для р..

Andrey пишет:

цитата:

Для различных выборов из баз, делай условную индексацию по уже сформированным индексам.

Не очень знаком с условной индексацией, если честно... Направьте плиз на путь истинный.

Вот допустим, у меня есть таблица продаж:
date D8 // дата продажи
stk1 N5 // продавец
stk2 N5 // покупатель
code C10 // код товара
num N10 // кол-во
price N10.2 // цена

И два индекса:
1) по CODE (чтобы быстро находить нужный товар в куче продаж)
2) по DATE (чтобы быстро найти нужный период для отчета)

Для построения отчета использую таблицу продаж только со вторым индексом в режиме READONLY
Как условная индексация может тут помочь ?

 Отправлено: 17.09.13 10:31. Заголовок: Sergy пишет: Требуе..

Sergy пишет:

цитата:

Требуется уточнение: блокирует именно те записи, по которым идет чтение или целиком запись в индексный файл ?

Блокирует весь индекс, то есть любое изменение. Причем ошибка не возникает, клиент просто ждет, пока другой клиент не отпустит индекс.