Форум » Для флейма » Помогите протестировать первую xHarbour систему » Ответить

Помогите протестировать первую xHarbour систему

AndreyZh: Уважаемые профи! Наконец перевёл систему на xHarbour (терминальный режим). Если не сложно помогите найти ошибки в её работе (сам уже тестил). Если есть желание, то с удовольствием приму критику в любом виде и отвечу на все вопросы. Система содержит исходный код (+ база очень крупной оптовки за 4 месяца) и варианты Clipper (нужна настройка ОС) и xHarbour (Win32) программ. Для установки скачать в любой каталог и распаковать архив. Все виды паролей - 11. Для создания индексов clipper (s_repair.bat), harbour (srepharb.bat). Справка F1 в любом режиме, инструкции в каталоге document. Для принудительного запуска st.bat (clip)/sth.bat (harb). По системе печати, если интересно - отдельно. Состав комплекса: 1. Оперативная программа. ls.exe (clip)/hls.exe (harb) 2. Администратор и бухгалтерия. la.exe (clip)/hla.exe (harb) 3. Аналитический контур. ldust.exe (clip)/hld.exe (harb) Буду очень благодарен за найденные ошибки и критику в любой форме! Скачка с учётом исправлений всех замечаний на 04.04.2010 (5.92) http://get.freesoft.ru/?id=108083

Ответов - 182, стр: 1 2 3 4 5 6 7 8 9 10 All

SkyNET: При попытке запуска любого clipper варианта выдаёт ошибку всех баз (после индексации и перезапуска): Окно на полном экране занимает меньше половины экрана: Один раз полностью упала программа, вот отчёт: error.logerror.log

Andrey: SkyNET пишет: Окно на полном экране занимает меньше половины экрана: Наверно нужно было бы ограничить экран программы ! Оператором SETMODE(25,80) или другими координатами, которые используете...

Andrey: Для терминала GTWVT- можно подбирать различные шрифты под различное расширение экрана 800х600, 1024х768 и т.д. ! Он лучше GTWIN ! Делал себе настройку шрифтов в программу, но так и не доделал... Если интересно, то исходники здесь : http://slil.ru/28903762


Dima: AndreyZh Что бы не падало с Dos Error 4 , пробни такой трюк SetHandleCount(200)

PSP: 1. DOS Error 4. 2. Выполнение программы легко прерывается нажатием Alt-C (в своих прогах я эту возможность отключаю).

AndreyZh: Огромное спасибо всем за реакцию! Хотя часть замечаний не является ошибками. SkyNET При попытке запуска любого clipper варианта выдаёт ошибку всех баз (после индексации и перезапуска): Одним из "плюсов" Harbour, как обратил внимание - не нужно настраивать ОС. В случает Clipper есть небольшой геморойчик. В данном случае нужно прописать в файлы: 1. win/system32/autoexec.nt (set clipper=f:220) 2. win/system32/config.nt (files=220) Но есть и другие настройки для Clipper - подробнее можно посмотреть учебник http://www.zhsoft.nm.ru/hand_set/hand_set.htm (если у Вас FireFox, то лучше через главную страницу - не любит он NewMail.ru)/ Окно на полном экране занимает меньше половины экрана: А это уже Harbour... Вызываете свойства окна Windows/вкладка расположение/ставите высоту строки 25.... Far до версии 2.0 тоже имел данный глюк. Остальные вопросы изучу и обязательно отвечу!

Dima: AndreyZh пишет: 1. win/system32/autoexec.nt (set clipper=f:220) Не помню как в Clipper 5.1 , но в 5.2e этого делать не нужно , достаточно править config.nt

AndreyZh: Andrey Спасибо! Наверно нужно было бы ограничить экран программы ! Оператором SETMODE(25,80) или другими координатами, которые используете... В принципе ответил - win настройка терминального окна. Для терминала GTWVT- можно подбирать различные шрифты под различное расширение экрана 800х600, 1024х768 и т.д. ! Он лучше GTWIN ! Делал себе настройку шрифтов в программу, но так и не доделал... Обязательно буду разбираться с данными терминальными библиотеками, т.к. они позволяют сделать мышинный интерфейс. Что по размеру окон, то в дистрибутиве (не который привёл здесь) имеются шрифты, позволяющие раскрывать окна практически на полный экран при всех разрешениях экрана. В принципе в дистрибутиве есть "система печати" и его можно скачать (9 mb) http://www.zhsoft.nm.ru/demo/distrib.exe SkyNET Один раз полностью упала программа, вот отчёт: В принципе это была самая сложная проблема "брошенные рабочие области", приводил пример: sele 0 DbSetOrder(1) // Сделует вылет по 9001 ошибке. Но "Called from : PLOADROUND(791)" вылезал - видно не до конца.... Спасибо. Сейчас проверю!

AndreyZh: Что бы не падало с Dos Error 4 , пробни такой трюк SetHandleCount(200) В xHarbour нет такого гемора - это чисто шутки Clipper. Не помню как в Clipper 5.1 , но в 5.2e этого делать не нужно , достаточно править config.nt У меня есть програмки под 5.2, такая же штука. Кроме правки autoexec.nt можно проблему обойти настройкой батника, т.е. делать вызовы программы, например: ls //f:220 Но об этом всегда забывали админы.... Еще одна "любимая" dos ошибка 5 - не дают полного доступа к сетевому диску... PSP 2. Выполнение программы легко прерывается нажатием Alt-C (в своих прогах я эту возможность отключаю). Есть такая возможность, но преднамеренно оставляю эту возможность и даже говорю об этом пользователям, т.к. при этом не рушатся индексы. Иначе будут закрывать "крестиком", что порождает море проблем.

AndreyZh: Исправил "отчетную программу" http://get.freesoft.ru/?id=108067 Шрифты, позволяющие работать почти на полном экране - актуально для Vista/7, т.к. не имеющие полноэкранного режима http://get.freesoft.ru/?id=108068

PSP: AndreyZh пишет: Иначе будут закрывать "крестиком", что порождает море проблем. Крест можно отключить. Поищите по форуму.

AndreyZh: Andrey Делал себе настройку шрифтов в программу, но так и не доделал... Если интересно, то исходники здесь : Занятные возможности (некоторым надоело однообразие) - решается настройками Tame версии от 5.0... Но интересно - какое еще практическое применение Вашей программы/библиотеки? Мне кажется, что это может усложнить жизнь (мне) Попытался "погонять" тестовый пример, но мне не удалось поменять ни одной из настроек.

PSP: AndreyZh пишет: но преднамеренно оставляю эту возможность и даже говорю об этом пользователям, т.к. при этом не рушатся индексы Еще как рушатся... :) Только что прервал работу hls.exe в момент сосздания индекса. При следующем запуске:

AndreyZh: PSP Еще как рушатся... :) Только что прервал работу hls.exe в момент сосздания индекса. При следующем запуске: С этим вопросом хотелось бы сильно разобраться!!! Clipper... Лишь после 8 попытки мне удалось получить "визуально" испорченый файл! При этом вход в программу происходил без сообщений об ошибках, прога работала нормально... Ситуация порчи индекса (информации) проявилась при проверки логики la/проверки/логика, после операции ремонта всё восстановилось. xHarbour... Все попытки прервать работы (4 шт) сразу приводили к порче индексного файла и выдачей приведённого Вами сообщения. После ремонта srepharb всё восстанавливалось, в т.ч. не было ошибок! Гуру Harbour пожалуйста проясните данный вопрос - в чём проблема? В принципе программа должна обрабатывать ошибки открытия файлов не допуская системных сообщений???? ++++ В принципе породил данное разрушение, запустив ремонт при параллельно, работающей программе!!! - Это ЖП

AndreyZh: ++++ В принципе породил данное разрушение, запустив ремонт при параллельно, работающей программе!!! - Это ЖП "Мёртвому - припарка". Использовав обработчик ошибок даю соощение о разрушении файлов и рекомендацию произвести ремонт (переиндексацию). Вопрос - насколько надёжны индексы *.NTX в xHarbour?

PSP: AndreyZh пишет: удалось получить "визуально" испорченый файл! При этом вход в программу происходил без сообщений об ошибках, прога работала нормально... Имхо, это - не есть хорошо. Индекс испорчен, но никто об этом не знает... Я думаю, что правильнее так: выдачей приведённого Вами сообщения. По-крайней мере, пользователь будет сразу знать, что с базой что-то не то... И я все-таки думаю, что нельзя пользователям разрешать внезапное прервание работы программы.

AndreyZh: И я все-таки думаю, что нельзя пользователям разрешать внезапное прервание работы программы. Есть ли в xHarbour средство блокирования закрытия окна Windows (блок крестика)?

Dima: AndreyZh пишет: Есть ли в xHarbour средство блокирования закрытия окна Windows (блок крестика)? PSP пишет: Крест можно отключить. Поищите по форуму.

PSP: AndreyZh пишет: Есть ли в xHarbour средство блокирования закрытия окна Windows (блок крестика)? При использовании терминала gtwin можно пользоваться WinAPI: SetConsoleTitle( cTitle ) hWnd := FindWindow( cTitle ) DeleteCloseButton( hWnd ) #PRAGMA BEGINDUMP #include "hbapi.h" #include "windows.h" HB_FUNC( SETCONSOLETITLE ) { hb_retl( SetConsoleTitle( hb_parc( 1 ) ) ) ; } HB_FUNC( FINDWINDOW ) { hb_retnl( (LONG)FindWindow( NULL, hb_parc( 1 ) ) ) ; } HB_FUNC( DELETECLOSEBUTTON ) { DeleteMenu(GetSystemMenu( (HWND)hb_parnl( 1 ), FALSE), SC_CLOSE, MF_BYCOMMAND ) ; DrawMenuBar( (HWND)hb_parnl( 1 ) ) ; } #pragma ENDDUMP для терминала gtWVT есть функция GTInfo(). Она в том числе умеет и "крест гасить". ЗЫ: я пользуюсь Harbour-ом. Про xHarbour точно не подскажу, надеюсь, что на этом уровне все также.

Петр: PSP пишет: При использовании терминала gtwin можно пользоваться WinAPIЗЫ: я пользуюсь Harbour-ом В Harbour можно использовать стандартный вызов hb_gtInfo( HB_GTI_CLOSABLE, .f. ) и для gtWIN если его пересобрать с HB_GTWIN_USE_UNDOC_WINAPI set HB_USER_CFLAGS=%HB_USER_CFLAGS% -DHB_GTWIN_USE_UNDOC_WINAPI

AndreyZh: Добрый вечер! 1. Спасибо за советы! Но по "крестику" мало, что понял - наверное "не дорос". Можно ли его блокировать, собирая как у меня в xHarbour - стандартным (упрощенным) образом? 2. Переделал всё с учётом Ваших замечаний, добавив шрифты и настройки Win под Dos (5.92 mb) http://get.freesoft.ru/?id=108083 3. "Нарыл" еще несовместимостей: - Нет функции Random. Есть hb_random, hb_randomInt, но они глючат - Нет функции создания файла Hb_create. Хотя компилятор на её отсутствие не ругается. Спасибо за помощь!

Dima: AndreyZh пишет: 1. Спасибо за советы! Но по "крестику" мало, что понял - наверное "не дорос" В своей проге где нить в самом начале напиши Local hWnd SetConsoleTitle( "Blabla" ) hWnd := FindWindow( "Blabla" ) DeleteCloseButton( hWnd ) * вместо Blabla напиши то что тебе нужно Там же где то вставь код [pre] #PRAGMA BEGINDUMP #include "hbapi.h" #include "windows.h" HB_FUNC( SETCONSOLETITLE ) { hb_retl( SetConsoleTitle( hb_parc( 1 ) ) ) ; } HB_FUNC( FINDWINDOW ) { hb_retnl( (LONG)FindWindow( NULL, hb_parc( 1 ) ) ) ; } HB_FUNC( DELETECLOSEBUTTON ) { DeleteMenu(GetSystemMenu( (HWND)hb_parnl( 1 ), FALSE), SC_CLOSE, MF_BYCOMMAND ) ; DrawMenuBar( (HWND)hb_parnl( 1 ) ) ; } #pragma ENDDUMP [/pre] AndreyZh пишет: - Нет функции Random. Есть hb_random, hb_randomInt, но они глючат Что значит глючат ? Параметры этих функций смотрел ? AndreyZh пишет: Нет функции создания файла Hb_create О DbCreate речь ?

AndreyZh: В своей проге где нить в самом начале напиши Сейчас проверю... Уже несложно, т.к. отделил "различия" кода на Clipper и xHarbour. Что это? Вставка исходника на C в код программы? (Задача весьма актуальна) Что значит глючат ? Параметры этих функций смотрел ? А як же! Глюк выражается в вылете программы, даже ErrorBlock не ловит. Например на коде: nRand:=HB_Random(1,99999) // Отловлено обрамлением паузой wait О DbCreate речь ? Да. Посоветовали (Andrey) http://clipper.borda.ru/?1-4-0-00000527-000-60-0 использовать Да есть она. HB_FTempCreate() Смотри документацию, т.е. xHarbour Language Reference Guide 1.1 Ерунда - последовал Вашему совету (написал сам).

Dima: AndreyZh пишет: Что это? Вставка исходника на C в код программы? (Задача весьма актуальна) Ну да :) Вот готовый примерчиг ;) [pre] Proc main Local hWnd SetConsoleTitle( "Blabla" ) hWnd := FindWindow( "Blabla" ) DeleteCloseButton( hWnd ) wait // а крестик и не доступен ;) return #PRAGMA BEGINDUMP #include "hbapi.h" #include "windows.h" HB_FUNC( SETCONSOLETITLE ) { hb_retl( SetConsoleTitle( hb_parc( 1 ) ) ) ; } HB_FUNC( FINDWINDOW ) { hb_retnl( (LONG)FindWindow( NULL, hb_parc( 1 ) ) ) ; } HB_FUNC( DELETECLOSEBUTTON ) { DeleteMenu(GetSystemMenu( (HWND)hb_parnl( 1 ), FALSE), SC_CLOSE, MF_BYCOMMAND ) ; DrawMenuBar( (HWND)hb_parnl( 1 ) ) ; } #pragma ENDDUMP [/pre]

Dima: Dima пишет: hWnd := FindWindow( "Blabla" ) Для надежности можно сделать так Do While ( hWnd:= FindWindow( "Blabla" ) ) == 0 Enddo

Dima: AndreyZh пишет: Например на коде: nRand:=HB_Random(1,99999) у мну номано сработал код.

AndreyZh: Dima По примерам с "крестиком" при компиляции ругается unresolved external _FindWindows

AndreyZh: у мну номано сработал код Малость не до конца описал текст: proc a() loca nRand, cfile nRand := hb_random(1,99999) wait str(nrand) // РАБОТАЕТ whil .t. nRand := hb_random(1,99999) // УЖЕ ВЫЛЕТАЕТ cfile := alltrim( str(nRand) )+".txt" if !File(cfile) EXIT endi endd retu

Dima: AndreyZh пишет: nRand := hb_random(1,99999) // УЖЕ ВЫЛЕТАЕТ У меня работает НОРМ. А что пишет когда вылетает ? По ходу можно обойтись без рандом , например так ? seconds() // вместо hb_random или более извращенно ? hb_md5(str(seconds())) // вместо hb_random

AndreyZh: А что пишет когда вылетает ? В том то и проблема, что молчит гад и даже обработчик шибок не реагирует. Но это сейчас не важно - решил проблемы другим способом.

Dima: AndreyZh пишет: что молчит гад error.log не пробовал смотреть ? Xharbour или Harbour ?

Dima: AndreyZh пишет: Но это сейчас не важно Думаю важно. Не может вылетать на ровном месте. Возможно в чем то другом причина. Ради прикола запустил в цикле до 1 лимона nRand := hb_random(1,99999) // УЖЕ ВЫЛЕТАЕТ Сработало как часы.

AndreyZh: Думаю важно. Не может вылетать на ровном месте. Возможно в чем то другом причина. Ради прикола запустил в цикле до 1 лимона nRand := hb_random(1,99999) // УЖЕ ВЫЛЕТАЕТ Сработало как часы. Создал аналогичный блок и так же сработало без ошибок.... К сожалению, что было уже затёр, но если Вы скачали первый тестовый пример, то вылет на функции zTemp модуля xharbour.prg

AndreyZh: error.log не пробовал смотреть ? Как ни странно, но файл не создавался. Xharbour или Harbour ? xHarbour

Dima: AndreyZh пишет: xHarbour версия (сборка) ?

AndreyZh: версия (сборка) ? 1.2.1 от декабря 2009

Dima: AndreyZh пишет: 1.2.1 от декабря 2009 Самопал или где то брал готовую ? Проверил на xHarbour Compiler build 1.2.1 (SimpLex) (Rev. 6693) xHarbour Compiler build 1.1.0 (SimpLex) (Rev. 6225) Твой пример работает без проблем в том числе и в цикле до 1 лимона.

Петр: Да ничего там не вылетает. За всю историю своего флейма (с учетом топика про ламеров) AndreyZh так и не привел ни ОДНОГО примера с ошибкой [x]Harbour. Флейм он и есть флейм.

PSP: Петр пишет: В Harbour можно использовать стандартный вызов hb_gtInfo( HB_GTI_CLOSABLE, .f. ) и для gtWIN если его пересобрать с HB_GTWIN_USE_UNDOC_WINAPI set HB_USER_CFLAGS=%HB_USER_CFLAGS% -DHB_GTWIN_USE_UNDOC_WINAPI Буду знать. Спасибо!

PSP: AndreyZh пишет: По примерам с "крестиком" при компиляции ругается unresolved external _FindWindows В оригинале - FindWindow. (be attentive...)

Dima: PSP пишет: AndreyZh пишет: цитата: По примерам с "крестиком" при компиляции ругается unresolved external _FindWindows В оригинале - FindWindow. (be attentive...) Мдя...

AndreyZh: Петр Да ничего там не вылетает. За всю историю своего флейма (с учетом топика про ламеров) AndreyZh так и не привел ни ОДНОГО примера с ошибкой [x]Harbour. Флейм он и есть флейм. А это вообще при чём? Нет желания помогать - обойдусь! Но хотя бы прочитали сообщение прежде чем "наезжать"! Напомню Вам, а лучше другим, кто желает изучить данную перспективную систему (по материалам моих вопросов): 1. Ошибка функций Upper/Lower исправлена лишь в версии xHarbour декабря 2009 2. Выявили (постоянные вопросы на импортных форумах) источник 9001 внутренней ошибки - порождающий пример: DbSelectArea(0) DbSetIndex(1) 3. Выявил "глюки" препроцессора (описываю только сейчас): #xcommand FOR <i>:=<s> TO <n> DO <*statement*> => FOR <i>:=<s> TO <n> ; <statement> ; END #xcommand IF <cond> THEN <*statement*> => IF <cond> ; <statement>; ENDIF Блок порождает ошибки компиляции, а иногда только вылет при выполнении (clipper обрабатывает): IF <условие> THEN SELE <алиас>; SKIP; LOOP 4. До конца не решена проблема замены TempFile() и многое другое... Думаю мне и многим другим спецам это интересно! Dima Спасибо за советы! Подскажите пожалуйста, что не так с "работой с окнами Win" - сообщение компилятора описал. Тему random давайте опустим - проблему решил, а обсуждение превращается в ....

AndreyZh: Пример с "крестиком" давайте приведу свой код: Вызов: [pre2]PROC Main( cPar ) LOCA nSel:=1, cTxt:="", nI:=1, nSelWork:=1, dD:=Date(), aArr:={}, nSell:=0, nC:=0, lRep:=FALSE // sOp:="9990" #include "cfg.ch" // Глобальные системные установки пакета и конфигурация по df. cnProgramm := "ОперативПр" // Вставка моего заголовка и блокирование закрытия окна pWind("Программа оперативного учёта")[/pre2] Кусок модуля (извините не могу скрывать текст): [pre2] * -------------------------------------------------------------------------- * Замена заголовка окна Win и вставка исходника на С PROC pWind(cTxt) LOCA hW SetConsoleTitle(Alltrim(cTxt)) hW := FindWindows(Alltrim(cTxt)) DeleteCloseButton(hW) RETU * --------------------------------------------------------------------------- * Вставляю сишный код #PRAGMA BEGINDUMP #include "hbapi.h" #include "windows.h" HB_FUNC(SETCONSOLETITLE) { hb_retl( SetConsoleTitle( hb_parc(1) ) ); } HB_FUNC(FINDWINDOWS) { hb_retnl( (LONG) FindWindows(NULL,hb_parc(1)) ); } HB_FUNC(DELETECLOSEBUTTON) { DeleteMenu( GetSystemMenu((HWND) hb_parnl(1), FALSE), SC_CLOSE, MF_BYCOMMAND ) ; DrawMenuBar( (HWND) hb_parnl(1) ) ; } #PRAGMA ENDDUMP[/pre2]

Dima: AndreyZh пишет: 1. Ошибка функций Upper/Lower исправлена лишь в версии xHarbour декабря 2009 Не вижу проблемы AndreyZh пишет: 2. Выявили (постоянные вопросы на импортных форумах) источник 9001 внутренней ошибки - порождающий пример: DbSelectArea(0) DbSetIndex(1) И вообще всех с праздником , лично я пошел бай

Dima: AndreyZh пишет: pWind("Программа оперативного учёта") По ходу кирилица не катит ! На англицком пишите.

PSP: AndreyZh пишет: hb_retnl( (LONG) FindWindows(NULL,hb_parc(1)) ); В WinAPI не функции FindWindows. Есть FindWindow. Dima пишет: По ходу кирилица не катит ! Угу. Сейчас проверить не могу, но с русскими буквами можно попробывать HB_OEMtoANSI().

AndreyZh: По ходу кирилица не катит ! На англицком пишите. Та же самая ошибка при компиляции unresolved external _FindWindows

PSP: AndreyZh пишет: Та же самая ошибка при компиляции unresolved external _FindWindows Вы ответы читаете? :)

Dima: PSP пишет: Вы ответы читаете? :) Похоже что нет

AndreyZh: PSP Спасибо всё заработало, в том числе с кириллицей! Причём всё подсказывали правильно - я неправильно переписал

Dima: PSP пишет: Угу. Сейчас проверить не могу, но с русскими буквами можно попробывать HB_OEMtoANSI(). Работает однако. PS я бай ;)

Петр: AndreyZh пишет: А это вообще при чём? Нет желания помогать - обойдусь! Но хотя бы прочитали сообщение прежде чем "наезжать"! Очень хороший способ помочь себе, а также, возможно, другим - написать маленький (по возможности) самодостаточный пример, который приводит к возникновению ошибки. На всякий случай уточняю - это не пример DbSelectArea(0) DbSetIndex(1) Ваши сообщения я читаю, но иногда вы так туманно изъясняетесь, что не одному мне становится непонятно, о чем это вы Нет функции создания файла Hb_create. О DbCreate речь ? Да. Посоветовали (Andrey) http://clipper.borda.ru/?1-4-0-00000527-000-60-0 использовать Да есть она. HB_FTempCreate() Смотри документацию, т.е. xHarbour Language Reference Guide 1.1 Ерунда - последовал Вашему совету (написал сам).

Andrey: AndreyZh пишет: цитата: Окно на полном экране занимает меньше половины экрана: А это уже Harbour... Вызываете свойства окна Windows/вкладка расположение/ставите высоту строки 25.... Это каждый пользователь сам будет делать ? Круто ! Я бы хотел посмотреть на бухгалтеров (в возрасте), как они это будут делать ... Почему то ни у одной GUI Windows программы - пользователь не настраивает эти параметры ! На Харборе под терминалкой можно сразу настроить этот параметр и не мучить пользователя !

AndreyZh: Петр Забыл еще об одной ОЧЕНЬ ВАЖНОЙ, выявленной особенности. Индексы NTX у xHarbour и Clipper НЕСОВМЕСТИМЫ, следовательно невозможно совмествное использование индексированных БД системами на разных языках. Почему то ни у одной GUI Windows программы - пользователь не настраивает эти параметры ! Уже приводил пример Far версии до 2.0 (где они это исправили)... На Харборе под терминалкой можно сразу настроить этот параметр и не мучить пользователя ! Подскажите, плиз как это сделать! P.S. Ответьте пожалуйста на личное послание.

Andrey: AndreyZh пишет: следовательно невозможно совмествное использование индексированных БД системами на разных языках. Да выкинь уже Клипер нафиг, нечего держаться за него ! AndreyZh пишет: Подскажите, плиз как это сделать! Писал ранее ! SETMODE(24,80) AndreyZh пишет: Ответьте пожалуйста на личное послание. Здесь на форуме, я не нашел как отвечать на личное послание ! Отвечаю здесь: могу только сопровождать в установке и консультациях, куда и что зайти. Я не владею бухгалтерскими навыками, да и уже возраст не тот чтоб заморачиваться с этим.

AndreyZh: Писал ранее ! SETMODE(24,80) Попробую. Здесь на форуме, я не нашел как отвечать на личное послание Почта в профиле реальная?

Петр: AndreyZh пишет: Забыл еще об одной ОЧЕНЬ ВАЖНОЙ, выявленной особенности. Индексы NTX у xHarbour и Clipper НЕСОВМЕСТИМЫ, следовательно невозможно совместное использование индексированных БД системами на разных языках. Они даже более несовместимы, чем вы себе представляете. К примеру, в [x]Harbour можно создавать мультитеговые NTX индексы c помощью rddInfo( RDDI_MULTITAG, .t., "DBFNTX" ) Еще dbf от [x]Harbour могут содержать поля не совместимые с Clipper: AUTOINC (+), ROWVERSION (^), TIME (T), DAYTIME (@), MODTIME (=) Еще есть несовместимости по блокировкам. Препроцессор в xHarbour, как вы подметили, не совсем Clipper compatible. Отчасти это из-за введения новых опреаторов HAS, IS, LIKE, отчасти из-за того, что в самом Clipper PP содержатся ошибки. И т.д., и т.п. Привыкайте к новым реалиям, или переходите на другой xBase продукт.

Andrey: AndreyZh пишет: Почта в профиле реальная? Да.

AndreyZh: Писал ранее! SETMODE(24,80) Проверил на моей модификации Dbu от 5.2 - работает.. Спасибо! Петр Конечно мой ответ напоминает флуд, но ещё раз прошу - не хотите реально помочь, тогда и не нужно делать сообщения... Они даже более несовместимы, чем вы себе представляете. К примеру, в [x]Harbour можно создавать мультитеговые NTX индексы c помощью rddInfo( RDDI_MULTITAG, .t., "DBFNTX" ) Еще dbf от [x]Harbour могут содержать поля не совместимые с Clipper: AUTOINC (+), ROWVERSION (^), TIME (T), DAYTIME (@), MODTIME (=) Мне пока интересна поддержка средств Clipper, а не расширенные возможности xHarbour. Всё это может быть в будущем! Еще есть несовместимости по блокировкам. Здесь обсуждение не со мной, а с Филатовым. "Его ответ: Индексные файлы xHarbour и Clipper несовместимы и ЗАПРЕЩЕНО их одновременное использование." Это так, но возможно совместное использование баз данных (см. описание ниже). Мне же нужна или абсолютная совместимость или ничего! Препроцессор в xHarbour, как вы подметили, не совсем Clipper compatible. Отчасти это из-за введения новых опреаторов HAS, IS, LIKE, отчасти из-за того, что в самом Clipper PP содержатся ошибки. Повторюсь! Мне нужна поддержка xHarbour средств, которые я использовал в Clipper и расширенные возможности xHarb пока не парят. Если и препроцессор Clipper 5.01 и содержал ошибки, то они мной давно "обойдены". Привыкайте к новым реалиям, или переходите на другой xBase продукт. Хамить не надо! Да? Куда и зачем мне переходить позвольте решение принимать самому на основании глубокого изучения альтернатив, серьёзного тестирования средств разработки, надёжности инструмента, перспективных пожеланий пользователей....

Andrey: AndreyZh пишет: Хамить не надо! Да никто и не хамит ! Дельный совет ! Или хватит возгласов насчет "не совместимости" с Клипером !!! Я тоже советую выкинуть Клипер и сосредоточиться на хХарборе. Я уже писал ранее, после перехода на хХарбор, я МЕНЬШЕ стал тратить время на сопровождение пользователей ! Т.к. программа на хХарборе НАМНОГО СТАБИЛЬНЕЙ работает, чем на Клипере !!!

Dima: Andrey пишет: Дельный совет ! +1

Петр: AndreyZh пишет: но ещё раз прошу - не хотите реально помочь, тогда и не нужно делать сообщения... Не все зависит от моих "хотелок". Дело в том, что иногда вы пишете информацию, которая не является полной или корректной, иногда откровенные глупости (хочется надеяться, что по незнанию). Все это могут читать и другие новички, и у них может сложиться неправильное мнение. А я все таки модератор Может вас просто забанить, тем самым дав время документацию почитать?

Dima: Петр пишет: А я все таки модератор Боюсь что уже нет

Петр: Спасибо Dima и что мне теперь с эти делать

Dima: Петр пишет: и что мне теперь с эти делать Виртуально пожать руку Pasha и поздравить его тоже с назначением

Петр: Dima пишет: Виртуально пожать руку Pasha и поздравить его тоже с назначением Ок

AndreyZh: Добрый день! Сегодня начал первые тесты у клиентов и был неприятно удивлён! Напомню, что неоднократно тестировал xHarbour приложения, сравнивая по скорости с clipper 5.01 аналогами и на моём ПК (XP Prof, AMD Atlon 3200, 2Gb, SATA 160Gb) вне зависимости от наличия фоновых приложений скорость у xHarbour на ВСЕХ операциях получалась в 2-3 раза выше (в основном БД была меньше 100Mb). Пока установил в 3 фирмах (во всех конфигурациях теста скорость xHarbour, как и 5-8 лет назад на 10-30% НИЖЕ): 1. фирма. Не выделенный сервер, все ПК (XP Prof, примерно класса Celer 2400/512Mb/120Gb). Harbour хуже, как в локальном, так и по сети. БД 300Mb. 2. фирма. Выделенный Windows Server 2005 (крутой). Оперативные режимы и отчёты xHarbour тормознее на 40%. БД 170Mb. 3. фирма. Не выделенный XP Prof (2 ядерный пень), рабочие станции дохлые под Win 98. xHarbour с рабочих станций медленнее на 10-20%. БД 730Mb. Везде фоном были запущенны различные офисные программы 1С, офис, Paint, Browse. Вопросы: 1. Какие версии? Какая может быть причина? Почему у меня скорость xHarbour получалась в 2-3 раза быстрее, чем у Clipper. 2. Кто нибудь сравнивал быстродействие по сети аналогичных программ на Harbour и Clipper с одинаковым типом индексных файлов и большим размером баз данных? Какие результаты? После обеда ещё потестю в паре фирм с очень хорошей техникой, но зоопарком ОС от Win2000-Seven. Но уже "сомневаюсь". Очень надеюсь на Ваши ответы, прогнозы и рекомендации по настройке ОС (пока не смены формата БД).

Pasha: Так в чем заключается проблема ? Раньше тест xHb был быстрее, чем сейчас ? Первое предположение - раньше Вы тестировали на релизе годичной давности, а сейчас собрали на текущей версии. Проверьте это предположение. А конкретно можно что-то сказать, если Вы покажете свой тест.

gfilatov2002: AndreyZh пишет: Очень надеюсь на Ваши ответы, прогнозы и рекомендации по настройке ОС Попробуй разобраться с предназначением/использовать для работы следующую функцию из ядра xHarbour: /* * * Operating system functions for Win32 * * Program to check and set Windows Registry settings * for safe networking - all versions of Windows to XP SP2 * * * Also includes check for buggy VREDIR.VXD under Win95 * and if the correct patch file is found - run it. */ #include "directry.ch" FUNCTION OS_NETREGOK( lSetIt, lDoVista ) LOCAL rVal:= .T., cKeySrv, cKeyWks IF lSetIt == NIL lSetIt:= .F. ENDIF IF lDoVista == NIL lDoVista:= .T. ENDIF IF !lDoVista .AND. OS_ISWINVISTA_OR_LATER() // 06/12/09 changed from OS_ISWINVISTA() * ELSEIF OS_ISWIN9X() rVal:= QueryRegistry( 0,"System\CurrentControlSet\Services\VxD\VREDIR","DiscardCacheOnOpen",1, lSetIt ) ELSE cKeySrv:="System\CurrentControlSet\Services\LanmanServer\Parameters" cKeyWks:="System\CurrentControlSet\Services\LanmanWorkStation\Parameters" lSetIt:= lSetIt .AND. ( OS_ISWINNT() .OR. OS_ISUSERANADMIN() ) // 06/12/09 Only Try to set registry if Admin authority for Win2000 or later // Server settings rVal:= rVal .AND. QueryRegistry( 0, cKeySrv, "CachedOpenLimit", 0, lSetIt ) rVal:= rVal .AND. QueryRegistry( 0, cKeySrv, "EnableOpLocks", 0, lSetIt) // Q124916 rVal:= rVal .AND. QueryRegistry( 0, cKeySrv, "EnableOpLockForceClose", 1, lSetIt) rVal:= rVal .AND. QueryRegistry( 0, cKeySrv, "SharingViolationDelay", 0, lSetIt) rVal:= rVal .AND. QueryRegistry( 0, cKeySrv, "SharingViolationRetries", 0, lSetIt) IF OS_ISWINVISTA_OR_LATER() // // 06/12/09 If SMB2 is enabled then turning off oplocks does not work so SMB2 is required to be turned off on Server rVal:= rVal .AND. QueryRegistry( 0, cKeySrv,"SMB2",0, lSetIt ) ENDIF // Workstation settings rVal:= rVal .AND. QueryRegistry( 0, cKeyWks, "UseOpportunisticLocking", 0, lSetIt) rVal:= rVal .AND. QueryRegistry( 0, cKeyWks, "EnableOpLocks", 0, lSetIt) rVal:= rVal .AND. QueryRegistry( 0, cKeyWks, "EnableOpLockForceClose", 1, lSetIt) rVal:= rVal .AND. QueryRegistry( 0, cKeyWks, "UtilizeNtCaching", 0, lSetIt) rVal:= rVal .AND. QueryRegistry( 0, cKeyWks, "UseLockReadUnlock", 0, lSetIt) IF OS_ISWIN2000_OR_LATER() rVal:= rVal .AND. QueryRegistry( 0, "System\CurrentControlSet\Services\MRXSmb\Parameters","OpLocksDisabled",1, lSetIt ) ENDIF ENDIF RETURN( rVal ) Дополнительно рекомендуется изучить эту ссылку.

Andrey: AndreyZh пишет: Какие версии? Какая может быть причина? Почему у меня скорость xHarbour получалась в 2-3 раза быстрее, чем у Clipper. Все зависит от ваших исходников, т.е. как вы работаете с БАЗОЙ .... Если используете оператор SET FILTER, то в Клипере он быстрей чем на Харборе, из-за его реализации (там присутствует оптимизация по фильтру). Я уже писал об этом. А так как вы тестировали на локальной машине, то и исходники свои не оптимизировали на сеть. Мне пришлось перелопачивать свои исходники и переделывать выборку по базам.... AndreyZh пишет: Кто нибудь сравнивал быстродействие по сети аналогичных программ на Harbour и Clipper с одинаковым типом индексных файлов и большим размером баз данных? Какие результаты? Да я сравнивал. Базы по 300-400 полей. Объем от 60-200 Мб. Выборка из базы (условная индексация) 0.2-10 сек. Если нужно обработать группу записей, то делай выборку (условный индекс) обрабатывай, потом закрывай индекс. Для сети - отказывайся от SET FILTER (под Харбором он медленный ! Читай выше...) и переделывай свой алгоритм обработок. Харбор все равно быстрей чем Клипер даже по сети. У меня задача на 50000 абонентов на Клипере считалась 5-6 часов, а на Харборе тот же самый алгорим считал за 2 часа. Я сам на переделку угробил тоже много времени, но зато сейчас хоть легче стало. Сейчас пытаюсь построить работу с базами так, чтоб можно было перейти на LetoDB.... И буду иметь у себя в задаче СРАЗУ: 1) локальный вариант, 2) сетевой (Файл-Сервер), 3) Терминальный и 4) сетевой (Клиент-Сервер)

Dima: gfilatov2002 пишет: Дополнительно рекомендуется изучить эту ссылку. AndreyZh пишет: Увы - даже с русским языком плохо, с англицких ещё хуже

Dima: Andrey пишет: Если используете оператор SET FILTER, то в Клипере он быстрей чем на Харборе, из-за его реализации (там присутствует оптимизация по фильтру). Я уже писал об этом. У него RDD NTX , о какой оптимизации речь (может я чего пропустил) ?

Andrey: Dima пишет: У него RDD NTX , о какой оптимизации речь (может я чего пропустил) ? Это тогда я пропустил.... Я про свой опыт написал. И еще это относится к Клиперу 5.3 !

AndreyZh: Добрый день! Спасибо за ответы - вечером буду серьёзно думать! Сейчас с админом будет тестить с "крайней" на сегодня конторе, но на первый взляд ситуация аналогична всем предыдущим. Справочно set filter и другие "тормозные" операции не использую, в нескольких режимах есть loca for <> whil <> на десяток записей. Но не в этом суть вопросов. Абсолютно понятно, что оптимизировав алгоритмы, использовав другой формат баз и индесов я получу существенное ускорение, но не о перспективе вопрос. Есть программа (ранее просто массированный ввод и извлечение информации, сейчас перевёл основную систему на xHarbour). Код и механизмы работы с dbf + ntx абсолютно идентичны с сборке на clipper и xHarbour. Тесты дома на базах до 100 mb давали двойное преимущество по скорости программ xHarbour - у клиентов на их сетях, ПК, ОС и базах размера больше 200 mb программа на xHarbour стала (пусть иногда немного) проигрывывать clipper программе.

Andrey: AndreyZh пишет: нескольких режимах есть loca for <> whil <> на десяток записей Переделать на конструкцию: индексный файл + SEEK а уж потом whil <> .... Скорость возрастет !

AndreyZh: Добрый вечер! Я в печали по поведению xHarbour, в моей задаче... Пока о моей задаче в целом (результаты, уже финальных тестов по скорости). Тесты проводились корректно (в начале первый прогон, затем прогон для снятия данных). 1. Локальный ПК. Сложный отчёт. База 90Mb. Замечу, что большое количество записей в некоторых таблицах большой роли не играет (дома перепроверил на фирме с другой спецификой операций): Clipper.. - 1' 35" xHarbour - 40" 2. Рабочая станция, база на сервере, копий проги на других ПК не запущено. База 90Mb, другой (более лёгкий отчёт): Clipper... - 48" xHarbour - 34" 3. Рабочая станция, база на сервере, ЗАПУЩЕНЫ КОПИИ ПРОГИ на других ПК. База 90Mb, другой (более лёгкий отчёт): Clipper... - 3' 12" xHarbour - 8' 24" 4. Локальный ПК. Сложный отчёт. База 560Mb: Clipper.. - 3' 18" xHarbour - 4' 52" 5. Рабочая станция, база на сервере, копий проги на других ПК не запущено. База 560Mb, другой (более лёгкий отчёт): Clipper... - 1' 30" xHarbour - 2' 15" 6. Рабочая станция, база на сервере, ЗАПУЩЕНЫ КОПИИ ПРОГИ на других ПК. База 90Mb, другой (более лёгкий отчёт): Clipper... - 5' 30" xHarbour - более 10 минут. Попытки админа поиграть параметрами сети не привели к коррекции результатов. Из этого делаю вывод, что при малом объеме данных xHarbour более продуктивно использует Ram и различные кэш являясь при этом более медленной системой.

AndreyZh: Попробую ответить на Ваши пожелания. Andrey Переделать на конструкцию: индексный файл + SEEK а уж потом whil <> .... Скорость возрастет ! А як же? Конечно такая конструкция loca for <> whil <> используется при наличии "основного" ключевого поля, при этом условия For плавающее, т.е. индекс нельзя предусмотреть. Dima У него RDD NTX , о какой оптимизации речь (может я чего пропустил) ? Наверное давно активно работали с Clipper 5.01? В него только начали вносить "элементы" технологии RDD для работы с базами/индексами fox, dBase, paradox, а с NTX clipper машина работает напрямую... Полностью на RDD перешли только с 5.2, что резко снизило (на 20-30%) скорость работы, в том числе с индексами NTX (это одна из причин моего отказа от перехода (по основной системе) на "свежии" версии, хотя на другой и сделал переход, т.ч. статистика достаточная).

AndreyZh: Dima gfilatov2002 Техническую документацию понимаю Всё, что описано Григорием уже давно пройденный в исследованиях этап... Andrey Да я сравнивал. Базы по 300-400 полей. Объем от 60-200 Мб. Выборка из базы (условная индексация) 0.2-10 сек. Если нужно обработать группу записей, то делай выборку (условный индекс) обрабатывай, потом закрывай индекс. Не стояла задача оптимизации по скорости - она более чем достаточна.. Просто xHarbour меня сильно соблазнил, тем, что не меняя "ничего" можно резко (в 2 раза повысить скорость приложения). Но этот опыт лишний раз меня убедил, что сравнения систем (баз данных и т.д.) нужно проводить на "пограничных" состояниях и переделывай свой алгоритм обработок Это и является основным способом радикальных ускорений конкретных режимов. Для примера <4. Локальный ПК. Сложный отчёт. База 560Mb: Clipper.. - 3' 18" xHarbour - 4' 52"> годовой анализ рентабельности товаров в зависимости от сезонности. Отчёт "стырил" с навороченной конфы 1С - для сравнимой фирмы (18 8.1 MS Sql) она проводила данный анализ за несколько часов Pasha Так в чем заключается проблема ? Раньше тест xHb был быстрее, чем сейчас ? Нет - выявилась "яма" в скоростных возможностях xHarbour! Здесь облом! Начинается этап пользовательских тестов на устойчивость данных при массированном вводе информации с 3-8 рабочих мест...

Dima: AndreyZh А слабо показать на самодостаточном живом примере что Xharbour работает уступает по скорости Clipper ? AndreyZh пишет: выявилась "яма" в скоростных возможностях xHarbour! Может быть "яма" в ваших алгоритмах ?

Pasha: 1. Я все-таки советую обратить внимание на Harbour. По части совместимости с clipper он сейчас мало в чем уступает, а по некоторым моментам превосходит xHarbour. А по скорости Harbour сейчас превосходит xHarbour в среднем в 2 раза. Об это пишут и разработчики xHb, да я и сам проводил эти тесты. 2. Надо использовать трюк в функции fsCommit в модуле rtl\filesys.c. Об этом здесь многократно писалось. 3. Для совместно открытых файлов используйте блокировку индекса на чтение dbOrderInfo(DBOI_READLOCK,,, .t.) Этот дает выигрыш в производительности в разы.

Петр: AndreyZh пишет: Просто xHarbour меня сильно соблазнил, тем, что не меняя "ничего" можно резко (в 2 раза повысить скорость приложения). Но этот опыт лишний раз меня убедил, что сравнения систем (баз данных и т.д.) нужно проводить на "пограничных" состояниях Это вы конечно исходили из ложных предпосылок. Если виртуальная машина работает в 2 раза быстрее, то это совсем не значит, что доступ к диску происходит в 2 раза быстрее или сетевые операции в 2 раза быстрее начинают выполнятся. Узкие места все равно остаются. Теперь по сравнению систем. xHarbour приложение у вас является 32 разрядным win приложением и выполняется, как и положено любому нативному Windows приложению. Clipper приложение выполняется под NTVDM. Для чистоты эксперимента возьмите сборку xHarbour для DOS (есть такие) и сравните. Pasha пишет: А по скорости Harbour сейчас превосходит xHarbour в среднем в 2 раза. Это да, но работа в сети сильно нивелирует разницу в скорости виртуальных машин. И в сухом остатке можно рассчитывать на 6-10%. Но если писать серверную часть, то конечно, как написал Miguel Angel Marchuet: "the result is impressive".

AndreyZh: Dima А слабо показать на самодостаточном живом примере что Xharbour работает уступает по скорости Clipper Я как бы просто описал результаты тестов - суть есть некий критический объем БД, которую программа должна обрабатывать, превышая который xHarbour (dbf + ntx) начинает работать медленнее, чем clipper 5.01 (dbf + ntx) и всё. У меня "растройство", а Вы ещё издеваетесь При желании сами сгенерируйте набор связанных таблиц объёмом более 300Mb и попробуйте... Может быть "яма" в ваших алгоритмах ? В тестах не сравнивались скорости алгоритмов обработки данных, а сравнивалась скорость обработки данных программами на Clipper 5.01 и xHarbour (сборка 12.2009) по единообразным алгоритмам. Если же Вы сомневаетесь в моём профессионализме разработчика - дайте мне свою небольшую программу и я её ускорю в пару раз. Pasha Я все-таки советую обратить внимание на Harbour. По части совместимости с clipper он сейчас мало в чем уступает, а по некоторым моментам превосходит xHarbour. А по скорости Harbour сейчас превосходит xHarbour в среднем в 2 раза. Об это пишут и разработчики xHb, да я и сам проводил эти тесты. Вполне возможно! Но первой мне попалась инструкция для новичков от Верченко Андрея, по этому и использовался xHarbour, да и казалось, что продукт от коммерческих разработчиков должен быть более тщательно проработан. Если Вас не затруднит перекомпилируйте систему из моей ссылки в первом сообщении (все исходники, bat) приложены и я с удовольствием (и на пользу дела) проведу повторное тестирование на скорость, а так же в дальнейшем на надёжность системы на Harbour. 2. Надо использовать трюк в функции fsCommit в модуле rtl\filesys.c. Об этом здесь многократно писалось. 3. Для совместно открытых файлов используйте блокировку индекса на чтение dbOrderInfo(DBOI_READLOCK,,, .t.) Этот дает выигрыш в производительности в разы. Все рекомендации очень полезны (и будут мной задействованы в будущем). Но сейчас была другая задача.

Петр: AndreyZh пишет: Если же Вы сомневаетесь в моём профессионализме разработчика - дайте мне свою небольшую программу и я её ускорю в пару раз. Вопрос был не ко мне и у меня нет никаких сомнений в вашем професионализме, но попробуйте оптимизировать сл. фрагмент кода [pre2] crVall := AllTrim(Upper(nameVal)) &crVall := IF(Upper(Left(crVall,1))=='C', AllTrim(zVal),; IF(Upper(Left(crVall,1))=='N', Val(zVal),; IF(Upper(Left(crVall,1))=='D', Ctod(AllTrim(zVal)),; IF(Upper(Left(crVall,1))=='L', ".T." $ Upper(zVal),"")))) [/pre2]

Dima: Петр даже знаю какой будет ответ от AndreyZh ............. PS Тем не менее с удовольствием посмотрю на его оптимизированный код. И я по ходу совсем не прикалываюсь !!!!!!!!!!! Это к Топикстартеру относится.

Andrey: Pasha пишет: 2. Надо использовать трюк в функции fsCommit в модуле rtl\filesys.c. Об этом здесь многократно писалось. А можно еще раз написать про это ? А то делаешь поиск по сайту здесь, а поиск "косячит", т.е. не дает результата.... Заранее спасибо ! Pasha пишет: 3. Для совместно открытых файлов используйте блокировку индекса на чтение dbOrderInfo(DBOI_READLOCK,,, .t.) Дайте пожалуйста пример небольшой... Хотя бы конструкцию... Я хочу на своей большой системе попробовать... Заранее спасибо !

Dima: Andrey пишет: А можно еще раз написать про это ? http://clipper.borda.ru/?1-4-0-00000477-000-10001-0-1257415410

Pasha: 2. В модуле rtl\filesys.c в начале fsCommit надо вставить 4 строки, так: HB_EXPORT void hb_fsCommit( FHANDLE hFileHandle ) { HB_THREAD_STUB HB_TRACE(HB_TR_DEBUG, ("hb_fsCommit(%p)", hFileHandle)); /* Working hb_fsCommit() on Windows. Personally I'm not a fun of this because it deeply interact with internal OS buffering scheme. in source/rtl/filesys.c add at the beginning of function hb_fsCommit() (line: 2467 just before HB_STACK_UNLOCK) */ #if defined(HB_OS_WIN_32) hb_fsSetIOError( TRUE, 0 ); return; #endif 3. Выборки из файла можно выполнять так: dbOrderInfo(DBOI_READLOCK,,, .t.) dbSeek(..) while ... if ... endif skip enddo dbOrderInfo(DBOI_READLOCK,,, .f.) Это блокировка индекса на чтение. Она выполняется всегда при любой навигавии по таблице, т.е. в операциях seek/skip/goto Если выборка состоит из 100 строк, то блокировка/разблокировка будет выполняться 100 раз, и выборка будет тормозить. Если блокировку сделать перед выборкой, то выборка будет выполняться быстро. Но злоупотреблять READLOCK не стоит, поскольку на время блокировки эти данные недоступны для чтения с других станций.

AndreyZh: Доброго дня! Вопрос был не ко мне и у меня нет никаких сомнений в вашем професионализме, но попробуйте оптимизировать сл. фрагмент кода Смотрю на код... Что похожее есть у меня в программе... Если это "наезд", то пошукайте код еще и такое найдёте... Иногда, добавляя возможности в систему натыкаюсь на блоки написанные еще в 1992 году (см. funcanzh.prg) - они работают, так зачем их трогать? В приведённом примере есть несколько "некрасивостей", но вне зависимости от этого у меня схожий блок выполняется единожды при запуске программы и занимает по времени 0.001 секунды и как проверить его оптимальность не знаю? даже знаю какой будет ответ от AndreyZh ............. Мне это очень интересно? Какой следует ожидать от меня ответ? Ладно - это флуд, обед заканчивается, краткая инфа: Под тест попала самая худшая аппратная конфигурация (сервер celer 1700 (без кэш)/128Mb/IDE 80Gb, раб.станции ещё хуже - всё под win 98). Это конечно "мрак" но всех устраивала работа dos программы. Радует, что xHarbour вариант вообще запустился, но в силу жутких тормозов девушки категорически отказались от дальнейшего тестирования. Примечание. В winXP кириллица отражалась как заголовок окна, а под win 98 НЕТ. Не "кидайте в меня", но где-то около 150 ПК продолжает работать под win 98 и несколько win 95 (и я не мог заставить руководство избавиться от этого "мусора").

Pasha: AndreyZh пишет: Под тест попала самая худшая аппратная конфигурация (сервер celer 1700 (без кэш)/128Mb/IDE 80Gb, раб.станции ещё хуже Нормальный компьютер ещё хуже - всё под win 98 Под win98 тормозит терминал gtwin. Используйте gtwvt

AndreyZh: Добрый вечер. УВЫ!!! С прискорбием сообщаю, что система на Clipper 5.01 пересобранная на xHarbour провалила тест на надёжность. Тестирование проводилось на стабильно работающей мощной технике (рабочие станции XP Prof/Home Celer от 2400/RAM от 512/SATA от 160, выделенный сервер 4 ядерный Xeon/RAID 10/RAM 4Gb, сеть 100mb/1Gb). Существующая программа показывает стабильную работу (до 1 разрушения индексов в 6 месяцев) при весьма большой нагрузке до 10 операторов на запись + 50 КПК в двух системах мобильной торговли + 8 точек внешних автоматических заказов). Все процессы записи завершаются функциями (что гарантирует (у clipper) её успешность): DbUnlockAll() DbCommitAll() Суть теста - 5 операторов одновременно вводят по 10 накладных + ввод 30 фин.документов + с 5 рабочих мест построение отчётов. Данная нагрузка не порушила данные, но операторы заметили глюк - после завершения массированной записи документов на одном (физически разные ПК) рабочем месте программа не могла в течении 3 минут произвести сохранения (были блокированны ресурсы) хотя формально блокировки были сняты.. Потом "просыпаясь" данные всё таки сохранялись. То есть и как при тесте скорости, так и здесь возникает ощущение, что xHarbour виртуальная машина работает с неким КЭШ, который создаёт иллюзию скорости на малом объёме данных, а при его "переполнении" (выгрузки на физический носитель) включаются "тормоза". Затем начался "садизм" - обычная практика пользователей. При этом НИКТО НЕ ПРОИЗВОДИЛ ввод данных в базу. Делалось закрытие программ "крестиком" и перезагрузкой ПК (на 3 рабочих местах). Система на Clipper спокойно к этому относится, т.к. до этого все данные "выдавлены после записи на физический носитель". Возникли проблемы: 1. Процессы оставили часть файлов заблокированными. 2. После корректного завершения программы с остальных рабочих мест система стала резко тормозить даже при запуске на сервере. 3. После принудительного закрытия блокированных файлов средствами MS WinServer 2008 была проведена проверка "логической целостности", обнаружившая разрушение данных. 4. Просмотр файлов средствами DBU показал физическое разрушение Dbf файлов (не тех, которые принудительно закрывали). РЕЗЮМЕ. Перевод существующей, тщательно отработанной системы на Clipper посредством компилятора xHarbour не обеспечивает: 1. Ускорения работы системы на БОЛЬШИХ базах; 2. Стабильность и устойчивость системы скорее всего снизится. РЕШЕНИЕ. При острой необходимости перевода существующей Clipper системы на (x)Harbour её необходимо радикально переделывать и желательно под SQL Server, например ADS, MS SQL Express, FireBird, MySql... P.S. У меня осталось два вида тестирования (на завта), просто любопытство на будущее: 1. Проверка работоспособности на Win95; 2. Проверка ситуации с Win 98 (просто плохая совместимость с данной системой или Win98 в качестве сервера) на конторе, где сервер (выделенный MS Windows Server 2003 и большинство рабочих станций на Win 98).

Dima: AndreyZh пишет: Система на Clipper спокойно к этому относится А чем линковали ? Rtlink , Blinker и тд ? Real Mode или Protected ?

AndreyZh: А чем линковали ? Rtlink , Blinker и тд ? Real Mode или Protected ? Rtlink / Real Mode

Dima: Интересно а как обстоят дела у Юрия ? http://clipper.borda.ru/?1-4-60-00000430-000-0-0 У него и юзеров поболее будет и базы побольше. Ни кто не в курсе ?

Петр: AndreyZh пишет: Смотрю на код... Что похожее есть у меня в программе... Если это "наезд" Это ваш код и это не наезд В приведённом примере есть несколько "некрасивостей", но вне зависимости от этого у меня схожий блок выполняется единожды при запуске программы и занимает по времени 0.001 секунды и как проверить его оптимальность не знаю? этот код я взял из request.ch. На счет единажды не уверен. Визуально и путем профилирования. РЕЗЮМЕ. Перевод существующей, тщательно отработанной системы на Clipper посредством компилятора xHarbour не обеспечивает: 1. Ускорения работы системы на БОЛЬШИХ базах; 2. Стабильность и устойчивость системы скорее всего снизится. Механический перевод - да. Потому, что я уже говорил [x]Harbour приложение - это в вашем случае 32 разрядное Win приложение, которое работает абсолютно как все остальные приложения Windows, т.е. использует дисковый кэш, системный стек TCP/IP по определенным правилам принятым в Windows. И на самом деле DbCommitAll() для Windows никак не указ и не гарантия сброса информации на диск. Руссинович М. Внутреннее устройство Microsoft Windows на ночь помогут вам. AndreyZh пишет: РЕШЕНИЕ. При острой необходимости перевода существующей Clipper системы на (x)Harbour её необходимо радикально переделывать и желательно под SQL Server, например ADS, MS SQL Express, FireBird, MySql... Вы MS SQL Express или хотя бы MySql for Win на Celeron 1700, не выделенный сервер когда нибудь пробовали? Или рабочий SQL сервер кнопочкой reset перезагружать

AndreyZh: Петр Что же Вы такой недобрый? этот код я взял из request.ch. На счет единажды не уверен. Визуально и путем профилирования "Чья туфля - моя туфля". И используется не единожды - то же верно. В системе запросов на 3-6 отчётах (из 300) для закачки "сохранённых параметров отчёты". Максимально (50 строк) - 0.5 секунды (уговорили). Создано где-то в 2006 году (виноват - забыл, да и не жаловался никто), а теперь используя "автоматом". Потому, что я уже говорил [x]Harbour приложение - это в вашем случае 32 разрядное Win приложение, которое работает абсолютно как все остальные приложения Windows, т.е. использует дисковый кэш, системный стек TCP/IP по определенным правилам принятым в Windows. Где же вы раньше были - может бы и не мучился сам с переводом системы, да и не мучил других. А "задним умом" все мы сильны! И на самом деле DbCommitAll() для Windows никак не указ и не гарантия сброса информации на диск. Да??? Для Clipper получается указ, а остальные "что рыжие"? Руссинович М. Внутреннее устройство Microsoft Windows на ночь помогут вам. А что сон после прочтения более крепкий? Или наоборот не усну, а то и на работы можно опоздать. Вообще-то у меня самого около 80Gb технической литературы, к которой обращаюсь "по мере необходимости", а вообще "голова - не мусорный ящик". Вы MS SQL Express или хотя бы MySql for Win на Celeron 1700, не выделенный сервер когда нибудь пробовали? Нет! А зачем мне это надо? Люди нормальные ПК за 10-16 т.р. купить не могут/нехотят, а Вы о сервере за 148 т.р. говорите. Или рабочий SQL сервер кнопочкой reset перезагружать Я нет, а операторы пробовали --- очень хороший аргумент для руководства был "о бессмыслености смены файл-серверной архитектуры и моего программного обеспечения" == стоимость восстановления сервера и информации равнялась моей 6 месячной зарплаты в данной фирме.

Dima: Амнистия в связи с Всемирным днем космонавтики AndreyZh Продолжаем , но без наездов на участников форума !

AndreyZh: Добрый вечер! AndreyZh Продолжаем , но без наездов на участников форума ! Очень хотелось бы уяснить "устав монастыря" или юмор на форуме запрещён? Или кто-то "более равный перед законом"? Ну ладно - это ночной бред.... Раннее были опубликованы предварительные результаты тестирования с первичной реакцией пользователей. В течении прошедшей недели около 200 users (14 фирм) должны были её "мучить". Соответственно окончательные результаты и выводы будут к концу этой недели, когда их всех объеду, выслушаю их мнение и проверю тщательность тестирования (по внутренним журналам), а так же целостность данных по подсистеме "анализа логической целостности". На досуге почитал описалки http://www.otc.pl/download/default.aspx?l=2 халявные RDD к mySQL для clipper .AND. (x) Harbour - может это "решение всех проблем"? Интересно, а кто-нибудь реально работает с RDD к SQL Server?

Сергей Р: AndreyZh пишет: Да??? Для Clipper получается указ, а остальные "что рыжие"? Для MS-Dos - указ, для Windows - нет.

AndreyZh: Сергей Р & Петр Очень бы хотелось уяснить проблему, а главное пути её разрешения (программным, а не организационным путём). Работаем под Windows.Имеем код: sele <Область> fillock() *** Изменяем поля, в том числе индексные DbUnlock() DbCommit() После последней операции программу на Clipper 5.01 исполняющуюся на рабочей станции (не сервере) могу "закрывать" любым способом, в том числе RESET и данным ничего не будет - десятком лет проверено мной и пользователями. Но некорректное прерывание программы на xHarbour порождает разрушение, по меньшей мере индексов (проверено на тесте). 1. Так ли это (по опыту других)? 2. Как бороться программным путём? По тестам программы на xHarbour... 1. Пользователи посредством "строгости" xHarbour наткнулись на мою очень серьёзную ошибку - в одном месте (удаление отгрузки) "забыл" закрывать таблицу, которая многократно открывалась/закрывалась во всех режимах. xHarbour при повторной попытке открытия открытого файла вылетал по ошибке выполнения. Clipper честно продолжал "размножать" одноименные алиасы, пока предел открытых областей не превышал максимум, после чего программа в любом (произвольном) месте "вылетала" без сообщений. Режим редкий, следовательно случаи вылетов так же практически не встречались. 2. Жалуются на более медленную работу проги на xHarbour в сравнении с Clipper... Особенно это "бросается в глаза" при одновременной сетевой работе... Деградация скорости на порядок. Программа и базы находятся на сервере. 3. Мне очень не понравилась реакция - "если системы похожи, то зачем городить огород".

Andrey: AndreyZh пишет: Жалуются на более медленную работу проги на xHarbour в сравнении с Clipper... Особенно это "бросается в глаза" при одновременной сетевой работе... Деградация скорости на порядок. Программа и базы находятся на сервере. хХарбор в сети чуть медленней чем Клипер ! Это я на своих программах выявил ! Я тесты приводил здесь на форуме ! У меня разница получалась на 10-15 сек. по выборке из 30 000 записей. После переделки алгоритма разница составила 2-5 сек. От ваших "стенаний" скорость не увеличиться. Я думаю даже после перевода на Harbour ! Драйвер же одинаков везде ! Резуме: переделывайте работу с базой !!!

Петр: AndreyZh я думаю, что вам будет интересно почитать сл. сообщение On Wed, 01 Apr 2009, Massimo Belgrano wrote: Привет, > Will be intresting this discussion on fivetech forum? > http://forums.fivetechsupport.com/viewtopic.php?f=3&t=15076 Нет, > > Speedtest CLIPPER vs. xHarbour - COMMIT > Is CLIPPER still faster in database management? Нет, > I am testing the COMMIT statement. > With Clipper the operation takes 9 sec. with xHarbour 77 sec > function main() > local I:=0 > msginfo("Start " + str( seconds() )) > use clientes new > for I := 1 to 1000 > append blank > clientes->nombre := str(recno()) > commit > next > msginfo("End " + str( seconds()) ) > return nil In the past at least five times I was answering for similar questions. I hope this is the last time. What commit() does is quite well documented in Clipper. I suggest to read also COMIX documentation and check what cmxSys( 1002 ) does. I think it's a basic information which should be well known by anyone who is working with Clipper. В прошлом по крайней мере пять раз я отвечал на подобные вопросы. Я надеюсь - это последний раз. Поскольку функция dbcommit() очень хорошо докуметирована в Clipper. Я советую почитать также документацию COMIX и проверить, что же делает cmxSys( 1002 ) Я думаю эта базовая информация должна быть хорошо известна любому, кто работал с Clipper dbCommit() make two things: 1. write application memory buffers to file. 2. send to OS request to flush disk buffers releated to open file. The 1-st action is executed also by any other rdd operation which may cause record reloading or may need to synchronize modifications, f.e. unlock. You can simulate it in many different ways, f.e. by skip(0). 1-й действие выполняется также любой другой RDD операцией, которая может привести к перегрузке записи или может требовать синхронизировать изменения, например unlock. Вы можете смоделировать его в самых разных формах, например вызвав skip(0). The 2-nd action is unique to dbcommit and it's not necessary for any synchronizations in simultaneous/concurrent/network access. The whole job here is sending information to Operating System which is automatically redirected if necessary by OS to File Server that we ask to flush OS or FS disk I/O write buffers physically to disk. OS / FS can ignore our request, can execute it immediately or can only mark that it should be done in some nearest future. It's in practice out of programmer control and does not have to be. 2-го действие является уникальным для dbcommit, и оно не является необходимым для любой операции синхронизации при simultaneous/concurrent/network доступе. В целом работа здесь заключается в передачи информации операционной системе, которая автоматически перенаправляется в случае необходимости операционной системой на файл-сервер, о том, что мы просим, чтобы OS или FS сбросила I/O буфер записи на диск физически. OS/FS может игнорировать нашу просьбу, может выполнить ее немедленно или может только пометить, что такая операция должна быть сделана в некотором ближайшем будущем. Это (такое поведение OS/FS) на практике находится вне контроля программиста и не должно быть. В [x]Harbour можете запретить эту часть dbCommit() используя: set( _SET_HARDCOMMIT, .F. ) В COMIX: cmxSys( 1002, .f. ) As I said it does not cause any interactions to concurrent access. Try to add set( _SET_HARDCOMMIT, .F. ) to above code and check the results. Then write a message to your OS / network client / file server authors and ask why COMMIT request executed from DOS application makes sth different then executed from real Windows application. Of course if you need such information. Probably DOS emulation layer buffers few commit requests in some short time period, f.e. 1 sec. and then send them as one. But I only guess. Anyhow it's not Harbour problem. Harbour only sends commit request for open file handle to the OS and this is single function call inside each user dbCommit() if _SET_HARDCOMMIT is not disabled. All time overhead if any is out of Harbour code. Попробуйте добавить set( _SET_HARDCOMMIT, .F. ) в код и проверьте результат. Тогда можете написать сообщение автору вашей ОС/сетевого клиента/файл сервера и спросить, почему запрос COMMIT, выполненный ДОС приложением делает что-то отличное, чем при выполнении из реального Windows приложения. Конечно, если вам нужна эта информация. Возможно ДОС эмулятор буферизирует несколько запросов вызова сброса за некоторый короткий период, например за 1 сек. и тогда отправляет как один вызов. Но здесь можно только догадываться. В независимости - это не проблема Harbour. Harbour только посылает запрос на сброс для открытого указателя на файл к ОС и эта функция вызывается внутри каждого использования dbCommit(), если только _SET_HARDCOMMIT не запрещен. Все время свыше (разница получаемая при выполнении программ на Clipper и [x]Harbour) получается вне Harbour кода. Best regards, Przemek --------------- P.S. Przemek - Przemyslaw Czerpak, главный разработчик проекта Harbour. Фактически автор DBFCDX/NTX RDD (и не только) в том виде, в котором они существуют сейчас в [х]Harbour P.S.S. перевод мой и довольно вольный

Петр: AndreyZh пишет: 1. Так ли это (по опыту других)? Очень даже может быть. Хотя, по сообщениям которые мне доводилось читать, в Linux такое встречается реже. 2. Как бороться программным путём? Бороться нужно всеми доступными методами, в т.ч. и расписки брать с пользователей, кровью написанные Что же касается программного пути. Перейдите к использованию gtwvt (двойная выгода - в Win9x шустрее работает и "крестиком" управлять сможете), обрабатывайте использование Ctrl-C. Не открывайте без нужды по 100-200 таблиц одновременно.

Петр: AndreyZh пишет: xHarbour при повторной попытке открытия открытого файла вылетал по ошибке выполнения. Clipper честно продолжал Я бы вместо "честно" написал "тупо". Деградация скорости на порядок. На порядок - это в 10 раз? Верится с трудом.. 3. Мне очень не понравилась реакция - "если системы похожи, то зачем городить огород". Это так девочки прореагировали ? Ну так объясните им, что так надо, так принято. У [x]Harbour множество достоинств, только используйте их. С моей точки зрения, вы сами себя загоняете в угол оставляя расширения на потом. Теперь и немедленно!

Pasha: Клипперовский dbCommit вызывает функцию 68h 21-го прерывания ("FFLUSH" - COMMIT FILE), а харборовский - функцию FlushFileBuffers(), которая предназначена для тех же целей. Почему они так разному обрабатываются в windows - надо копать. Как выполняется FlushFileBuffers - можно почитать, к примеру, здесь: http://support.microsoft.com/kb/332023 А как ntvdm выполняет commit file - непонятно. Требования по производительности и надежности в данном случае взаимоисключающие.

Pasha: простой тест: use test2 new nSec := Seconds() for ser := 1 to 30000 dbappend() commit next ? Seconds() - nSec wait не показал преимущества в производительности клиппера и харбора Время выполнения теста примерно одинаково

AndreyZh: Всем доброго дня! Спасибо за множество конструктивных замечаний! - Сейчас буду с ними разбираться... Но для затравки "сегодняшний шок от Гавани": AndreyZh - реальная моя ошибка... Выявлено на Win XP Пользователи посредством "строгости" xHarbour наткнулись на мою очень серьёзную ошибку - в одном месте (удаление отгрузки) "забыл" закрывать таблицу, которая многократно открывалась/закрывалась во всех режимах. xHarbour при повторной попытке открытия открытого файла вылетал по ошибке выполнения. Clipper честно продолжал "размножать" одноименные алиасы, пока предел открытых областей не превышал максимум, после чего программа в любом (произвольном) месте "вылетала" без сообщений. Режим редкий, следовательно случаи вылетов так же практически не встречались. Петр Я бы вместо "честно" написал "тупо". Захотел девушкам показать данную ошибку - они работают под Win 98... xHarbour честно/тупо начала размножать не вылетая по ошибке... Проверить это под разными ОС можно в тестовом примере из ссылки - "Оперативная программа/накладные/отгрузка" идём в конец и пытаемся удалить несколько накладных - клавиша Delete. Получается, что поведение программы (реакция на ошибки) xHarbour зависит от операционной системы? === Я поражён! 2. Под Windows 95 систему так и не удалось запустить. Используемая конфигурация ПК - PI/Ram 8mb/HDD 120mb. Пожалуйста не смейтесь - это бывший мой и его продал фирме 8 лет назад. А они не хотят выбрасывать, т.к. он единственно беглючный. Петр На порядок - это в 10 раз? Верится с трудом.. Прочитав это утром - перепроверил! В зависимости от типа операции деградация скорости в 7-12 раз. Напомню тестовое окружение (легко сами можете перепроверить - базы и ПО приложено в ссылке): 1. Программа и база расположены на сервере. 2. Без фоновых приложений на сервере и рабочей станции запускаем приложение, например HLD с рабочей станции (время на "моих" БД во время теста). 3. Строим отчёт - "операторские/остатки на текущий момент". Время построения 15 секунд. 4. С другой рабочей станции запускаю любую программу, например HLA. Вхожу и ничего не делаю. 5. На первой станции запускаю тотже отчёт. Время построений 2 минуты 40 секунд, т.е. в 10.6 раз медленнее. 6. Справедливости ради. Запускаю приложения еще на 3 рабочих станциях. Время построения отчёта 3 минуты 20 секунд, т.е. остальные станции уже не оказываю большого влияния. БОЛЕЕ ТОГО (сервак очень мощный) запуск в качестве фона сложных отчётов на на других станциях практически не влияет на время построения тестового отчёта. Andrey Резуме: переделывайте работу с базой!!! ВСЕХ ПОЛЬЗОВАТЕЛЕЙ СКОРОСТЬ РАБОТЫ УСТРАИВАЕТ!!!! И активно обсуждаемый вопрос звучит о снижении скорости xHarbour дубликата системы на Clipper 5.01R Dbf+Ntx при превышении размера совокупных таблиц и индексов выше некоторого предела (примерно 200mb). А что Ваши пользователи строят отчёты по сети??? Если да (или кому-то интересно) есть более реальная альтернатива! Петр Не открывайте без нужды по 100-200 таблиц одновременно В плане борьбы с ограничениями на число открытых файлов (ограничение на число пользователей) на сервере (в частности Windows 98 - 1024 файла) система держит постоянно открытыми 31Dbf + 62Ntx и открывает при необходимости еще до 4 таблиц Dbf.

AndreyZh: Петр Очень интересное обсуждение - нужно будет еще раз внимательно пересмотреть код моей системы, но КАЖЕТСЯ на тормоза COMMIT уже нарывался и посему процедуры обновления информации у меня построенны по стандартизованному алгоритму: 1. Запоминаю/обновляю изменения в переменных памяти или временной таблице на локальном диске; 2. Блокирую необходимый набор таблиц или записей; 3. Сброс инфы из времянок в рабочии таблицы... Старался добиваться, что бы общее время транзакции не превышало пары секунд. При этом системы контролирует логику изменяемых данных. 4. DbUnlockAll(); DbCommitAll() При построении отчётов COMMIT не используется, следоватено тема форума мало меня беспокоит. Но огромная просьба - опишите (повторите для малограмотных) механизм DbCommitAll() из обсуждения, а главное рекомендации по оптимизации для xHarbour... Просто плохо понял цитаты вырванные из контекста. Pasha 1. Я все-таки советую обратить внимание на Harbour. По части совместимости с clipper он сейчас мало в чем уступает, а по некоторым моментам превосходит xHarbour. А по скорости Harbour сейчас превосходит xHarbour в среднем в 2 раза. Об это пишут и разработчики xHb, да я и сам проводил эти тесты. Может быть! Но с моим уровнем знаний нереально легко переключать м/у Harbour-ами, если не сложно перекомпилируйте мою систему - исходники все есть и настроены на Clipper/xHarbour и с удовольствием проведу тестирование системы, в том числе у пользователей. Так же возможно попытаюсь разобраться с Harbour. Причины: - miniGui 100% настроена на Harbour, а с xHarbour не все библиотеки (самые важные, например PDD для меня НЕТ) не собираются под xHarbour. - под xHarbour + BCC + Tasm32 не собираются 40% (самых интересных) примеров. - большинство "полезных" расширений создаются только под Harbour и так далее. Pasha Клипперовский dbCommit вызывает функцию 68h 21-го прерывания ("FFLUSH" - COMMIT FILE), а харборовский - функцию FlushFileBuffers(), которая предназначена для тех же целей. Почему они так разному обрабатываются в windows - надо копать. Это по вопросу "разрушения БД при некорректном прерывании программы на рабочей станции"? Мой вопрос. Система как бы разблокировала таблицы и сбросила содержимое буфера памяти. Что нужно еще сделать (кроме способа (работает) закрыть все Dbf) что бы данные система не реагировали на "reset" на рабочей станции?

Pasha: AndreyZh пишет: Но для затравки "сегодняшний шок от Гавани": цитата: AndreyZh - реальная моя ошибка... Выявлено на Win XP Пользователи посредством "строгости" xHarbour наткнулись на мою очень серьёзную ошибку - в одном месте (удаление отгрузки) "забыл" закрывать таблицу, которая многократно открывалась/закрывалась во всех режимах. xHarbour при повторной попытке открытия открытого файла вылетал по ошибке выполнения. Clipper честно продолжал "размножать" одноименные алиасы, пока предел открытых областей не превышал максимум, после чего программа в любом (произвольном) месте "вылетала" без сообщений. Режим редкий, следовательно случаи вылетов так же практически не встречались. Петр Я бы вместо "честно" написал "тупо". Захотел девушкам показать данную ошибку - они работают под Win 98... xHarbour честно/тупо начала размножать не вылетая по ошибке... Проверить это под разными ОС можно в тестовом примере из ссылки - "Оперативная программа/накладные/отгрузка" идём в конец и пытаемся удалить несколько накладных - клавиша Delete. Получается, что поведение программы (реакция на ошибки) xHarbour зависит от операционной системы? === Я поражён! Вы путаете разные вещи. Это не харбор по разному открывает файлы в win9x и winnt. Это windows по разному выполняет одинаковую операцию открытия файла. win9x и winnt - это все-таки разные ОС. Меня когда-то удивило, что функция SetConsoleTitle - установка заголовка окна консоли - по разному выполняется в этих ОС, параметр надо передавать в разных кодировках. Это эе касается и открытия файлов. Вы никогда не замечали, что файл, открытый в режиме разделения, win98 не позволяет открывать монопольно другому приложению, а winnt - позволяет ? Вот в соседней ветке у кого-то не работал поиск файла, а потом выяснилось, что это специфика ОС, в линукс в имени файла регистр имеет значение. И в Вашем случае именно ОС работает по разному, а не харбор.

Pasha: AndreyZh пишет: То есть и как при тесте скорости, так и здесь возникает ощущение, что xHarbour виртуальная машина работает с неким КЭШ, который создаёт иллюзию скорости на малом объёме данных, а при его "переполнении" (выгрузки на физический носитель) включаются "тормоза". Это при работе клиппера можно гадать, как выполняется та или иная операция. А для харбора это точно известно. По Коммит - Вы можете глянуть в dbfntx1.c функию hb_ntxFlush. Сначала вызывается GOCOLD, по которой выполняется вызовы WriteFile для файлов dbf, ntx, dbt, то есть, данные из буфера харбора сбрасываются в буфер ОС. Затем, если установлен HARDCOMMIT, вызывается FlushFileBuffers, по которому ОС должна записать свой кэш на диск. Чтобы она это гарантированно сделала - надо разбираться уже с настройками ОС. Почитайте ту страничку с сайта MS. Надо разбираться с настройками и рабочей станции, и файл-сервера.

Andrey: AndreyZh пишет: 1. Программа и база расположены на сервере. По моему программу располагать на сервере - это АБСУРД ! Программа же свой файл "свопинга" выгружает на сервер !!! Это дополнительный фактор ТОРМОЗА для сети. Я еще на клипере делал клиентское место программы на локальном диске пользователя, чтоб файл-свопинга и временные файлы, настройки всякие были у пользователя... А обновление программы делал автоматом, запуском небольшой программки (с рюшечками) ! Она лезла на сервер, сравнивала дату ехе-ника СЕРВЕРА с датой ехе-ника ЛОКАЛЬНОЙ и если ехе-ник новый, то копировала на Локальную станцию. А потом запуск уже обновленного ехе-ника. А размер файла-свопинга у Клипера и Харбора различаются.

Dima: Andrey пишет: Программа же свой файл "свопинга" выгружает на сервер !!! Уверен в этом ? я сомневаюсь.

Andrey: AndreyZh пишет: А что Ваши пользователи строят отчёты по сети??? Если да (или кому-то интересно) есть более реальная альтернатива! Строят конечно. Только и на Клипере отчеты долго строились.... У меня нет быстрых отчетов... Выборка у меня по сети при БОЛЬШОЙ нагрузке (20-25 раб.станций) происходит за 5-30 сек. Заполнение карточки (записи) быстрое, юзера не жалуются. Делаю блокировку записи (или ввод новой) и ввожу сразу в запись, потом освобождаю эту запись. Все быстро... Единственно что отличает от вашей ситуации, что я разных зверей Win9x извел везде как паразитов. Установил везде где можно ХР и 2000, остальных на склад и все !!! Указал причину - СТАРЬЕ и все !!! Некогда мне заниматься шаманством, еще не хватало MS-DOS 6.0 установить ....

AndreyZh: По моему программу располагать на сервере - это АБСУРД ! "Я так и знал" - программу и БД располагаю на всегда на сервере, т.к. это (из практики) более надёжная архитектура (теоритическое обоснование привести не могу), но когда еще были "ненадёжные сети" данная конструкция резко увеличивала надёжность, например, где индексы ломались ежедневно, стали "ломаться" раз в месяц... Но временные файлы самой программы, свопы Clipper отправляю на локальный диск, что действительно увеличивает быстродействие. Оверлеи, переменные памяти и некоторый КЭШ Clipper машина располагает в RAM, используя до 32mb памяти, что вполне достаточно. Строят конечно. Только и на Клипере отчеты долго строились.... У меня нет быстрых отчетов... У меня только отчёты "оперативной программы" строят по сети и то не всегда. Врятли это "открытие", но опишу технику. На рабочей станции создаётся "отчётный каталог", содержащий "дубликат" серверной БД. Загрузка данных в него делает батник - примерно такой: attrib ls.exe -r // Снятие атрибута "только чтение" - важное требование для сети. attrib ldust.exe -r // Снятие атрибута "только чтение" - важное требование для сети. copy x:\lack\ls.cfg *.cfg // Копия конфигурации copy x:\lack\ls.exe *.exe // Копия программы copy x:\lack\ldust.exe *.exe // Копия программы * Запуск процедуры переиндексации, если интенсивная работа с БД. Что в результате ("нафига козе боян"): 1. Вариант. Отчёт "акт сверки" по сети строится 15 минут. 2. Вариан. Закачка и переиндексация - 5 минут, + построение акта - 1 минута. Выборка у меня по сети при БОЛЬШОЙ нагрузке (20-25 раб.станций) происходит за 5-30 сек. Выборка чего? Дайте пример? Примечание Меня всегда умиляет приведение цифр по количеству "рабочих станций в сети" - это вообще не показатель!!! Более полезна инфа о количестве одновременно, работающих на запись операторов или объем (число записей) наиболее часто изменяемой оперативной таблицы и её структура индексов. Приведу пример (мой любимый тестер): Количество ПК в гетерогенной сети более 90 + 50 КПК + 10 клиентов автозаказа. НО одновременно пишут не более 10 операторов + (2 серверов КПК + 1 канал автозаказов это сеансы на сервере). Заполнение карточки (записи) быстрое, юзера не жалуются. Делаю блокировку записи (или ввод новой) и ввожу сразу в запись, потом освобождаю эту запись. Все быстро... Можно поподробнее... 1. А то ведь можно понять (нормальная ситуация) - опер заблокировал ресурс и пошел курить, а вместе с ними и вся организация. 2. Заполнении карточки? Сохранение - миллисекунды??! У меня чуть сложнее... Пример - "сохранение отгрузочной накладной" (по каждой позиции). 1. Изменение оперативных остатков. 2. Добавление шапки и детализации документа. 3. Запись в таблицу истории операции (самая "слабая" таблица). 4. Коррекция долгов клиентов. 5. Фиксация операции в журнале и файле статистики. 6. Возможно добавление счета фактуры и финансового документа. Время сохранения накладной из 2000 позиций с рабочей станции сети примерно 10 секунд... Это много? Надысь обсуждали 1С 8.1 MsSql - время "проведения" такой накладной (аналогичная операция) около 3 минут. Единственно что отличает от вашей ситуации, что я разных зверей Win9x извел везде как паразитов. Установил везде где можно ХР и 2000, остальных на склад и все !!! Указал причину - СТАРЬЕ и все !!! Главная причина "моего зоопарка" - частный бизнес, кто-то может позволить лицензии и новую технику, а кто-то нет и увы не имею возможности диктовать на что боссу тратить деньги. Некогда мне заниматься шаманством, еще не хватало MS-DOS 6.0 установить .... Список реально используемых ОС (к счастью ими и железом по большей части занимаются админы): Windows 95/98, 2000, XP (Home&Porf), Vista, Seven, Server 2003/2005/2008; Linux (знаю только об Alt); Пара "халявщиков" PocketPC; Пара "экстремалов" MacOS.

Andrey: AndreyZh пишет: Выборка чего? Дайте пример? БД-Договоров приватизации жилья. Кол-во записей: 40 000. Объем базы: 110 Мб. Кол-во полей: 300. Поиск по адресу: код города + код улицы + номер дома + номер квартиры + DELETED()=.F. 1) Локальный вариант - 0.5 сек 2) Сетевой вариант - 5-30 сек в зависимости от кол-ва работающих станций в сети. (25 мах) Сервер 2х ядерник, Win2003, локальные станции XP БД-Оплаты абонентов. Кол-во записей: 65 800. Объем базы: 230 Мб. Кол-во полей: 375. Поиск: код договора + DELETED()=.F. 1) Локальный вариант - 1.5 сек 2) Сетевой вариант - 3-10 сек в зависимости от кол-ва работающих станций в сети. (5 мах) Сервер 1-но ядерник, Win2000, локальные станции XP и 2000 Выборка - это построение "условного индекса" по уже проиндексированному полю.

Andrey: AndreyZh пишет: Можно поподробнее... 1. А то ведь можно понять (нормальная ситуация) - опер заблокировал ресурс и пошел курить, а вместе с ними и вся организация. 2. Заполнении карточки? Сохранение - миллисекунды??! Блокировка справочника в программе разрешена на 20 сек. Дальше, если клавиши не нажимаются - разблокировка (авт. закрытие справочника) . Заполнение записи в Tbrowse (GET ) 20 сек. - дальше , если клавиши не нажимаются - авт. закрытие GET'a. Пример такого Tbrowsa для сети взят с журнала Nantacket еще в далеком 1996 году. Так что у меня опер НЕ МОЖЕТ заблокировать ресурс (запись). Заполнение карточки или Tbrowsa (2 режима, на выбор пользователя) происходит в текущий момент, т.е. запись блокируется и после заполнения каждого поля происходит сброс в базу - типа: IF ( RecLock( LOCK_RETRY ) ) // Возникает ожидание до тех пор пока // запись заблокирована редактированием IF ( DoGet( oBrowse, cStatColGet, { | oGet | EditIt( oGet ) } ) ) IF Vxodit( cIndexTo, cFilterTo ) UpdateSemaphore( nHandle, oBrowse, .T. ) ELSE UpdateSemaphore( nHandle, oBrowse ) ENDIF IF ( oBrowse:colPos == LEN( aPoleRus ) + 1 ) ; KEYBOARD Chr( K_CTRL_HOME ) ELSE ; KEYBOARD Chr( K_RIGHT ) ENDIF IF aPoleRus[ nL2, N_TOTAL ] oColumn := oBrowse:getColumn( oBrowse:colPos ) oColumn:footing := EVAL( aBlock[ nL2 ] ) ENDIF ENDIF RESTSCREEN( MAXROW(), 0, MAXROW(), MAXCOL(), cScr ) DBCOMMIT() DBUNLOCK() ENDIF Скорость записи поля в базу - миллисикунды, я даже и не проверял на скорость... При вылете из программы (свет вырубили или еще раньше Клипер вылетал часто) все данные сохраняются в базе, опер продолжал корректировать эту-же запись.

AndreyZh: Добрый вечер! Andrey ИМХО, главное, что всё удовлетворяет пользователей. По своему опыту, если интересно Clipper стабильно и довольно быстро работает на оперативных (постоянное массированное изменение информации) таблицах до 1.000.000 записей, редко изменяемые (не замечал проблем на 10 млн.) и размере индесных файлов до 20mb. Что касается механизма блокировки и обновления информации когда нибудь, при желании пофлудим. По поводу тестов: 1. Народ "шланговал", посему не могу опираться на них. 2. Исправлены серьёзные проблемы обнаруженные SkyNET и одной умной девушкой. 3. Учёл некоторые разумные советы гуру форума. 4. К понедельнику выложу (на сайте?) свежий вариант системы. По поводу моих "претензий" к xHarbour. Наверное прав активно помогающий мне админ "поведение системы на xHarbour сильно зависит от расположения звёзд на небе": 1. Windows 95. При наличии 40mb на диске (удалил 20mb) система заработала. 2. Windows 98. - медленный интерфейс. Сменю драйвер терминала, а там посмотрим; - "игнорирование ошибки повторного открытия БД с одним алиасом". Сегодня в другой конторе "нормально" вылетало по ошибке, как и положено, что по сети, что на локальном диске. 3. Сравнение по скорости. Нашёл почти наибольшую базу (в 3 раза большую, чем на тесте, где обнаружились "тормоза" системы на xHarbour, в сравнении с Clipper вариантом)... Прога на xHarbour на моём ПК работает на 30-100% быстрее клипперовской системы Админ обещал разобраться, какие настройки (программы) Win включают тормоза у xHarbour. Спасибо за помощь!!! Пошел работать и учить матчасть.

Dima: AndreyZh пишет: DbUnlockAll() DbCommitAll() Andrey пишет: DBCOMMIT() DBUNLOCK() хммм...

Петр: Dima пишет: хммм... Я, кстати, тоже это приметил. Но подумал может быть просто здесь напутал. А оказывается и в программе [pre2] #define UNLOCK_COMMIT DbUnlockAll(); DbCommitAll() #define UN_COMM DbUnlock(); DbCommit() [/pre2]

AndreyZh: Млин! Andrey и AndreyZh разные люди! Отвечаю только за себя! При освобождении ресурсов использую "свои" команды предпроцессора UNLOCK_COMMIT (после изменения группы таблиц) и UN_COMM (при изменении одной) - последовательность: DbUnlock* DbCommit* из соображений - сначала освободить ресурсы для других пользователей, а только затем сброс буфера памяти - процедура, которая может занимать несколько секунд при массированном изменении информации.

Andrey: Dima пишет: Andrey пишет: цитата: DBCOMMIT() DBUNLOCK() хммм... А что не так ?

Dima: AndreyZh пишет: Млин! Andrey и AndreyZh разные люди! Это и понятно . Не ошибся я. Я веду к тому что у Андрея порядок верный у Вас нет. ЗЫ При желании можно найти в инете дискуссии на эту тему relcom.comp.dbms.clipper fido.clipper

Dima: Andrey пишет: А что не так ? У тебя все правильно !

Andrey: Dima пишет: У тебя все правильно ! Так я же с журнала Nantacket списывал, да так и осталось .... Уже подумал, по новому нужно делать....

Dima: Andrey пишет: Так я же с журнала Nantacket списывал, да так и осталось ....

AndreyZh: Заинтриговало! А что не так? Доски BBC уже лет десять не смотрел, да и найти инфу крайне сложно!

Dima: AndreyZh Выкладываю как есть текст от 18 октября 1999 года от andvit , Newsgroups: relcom.comp.dbms.clipper Без правок и своих комментариев. Свои выводы каждый делает сам. Привет! Как я уже упоминал у меня тоже были проблемы с индексами, которые я решил под НТ (не 100% конечно но достаточно для стабильной работы). Начать наверное нужно с самого клиппера. Я использую 5.2е + blinker 4.1 protected mode + несколько библиотек от разных компаний (six, ctp, esc) Все кто использует 5.3 думаю там свои хитрости есть хотя все ниже сказанное может пригодиться Переиндексировать можно и нужно если есть свободное время и юзеров нет это никогда не мешает. Замечено что после переиндексации все шуршит намного быстрее. Рекомендую настоятельно как минимум делать это в понедельник рано утром. Наш сервер после выходных всегда спит и думает медленно. 1. Если уж совсем плохо с индексами поискать на дежа по ключевым словам nt+clipper+locking. Там помнится кто-то написал по научному что нужно подправить на сервере нт и на клиенте связанное с кешем из за чего могут портиться индексы. Толково написано. 2. НЕ ДОПУСКАТЬ юзеров - менеджеров - директоров и прочих начальников заходить на базу с помощью dbu, dbx (особенно важно при six!), brow и делать там исправления даже самые маленькие. Опять же замечено - это помагает на 99%. Потому как мемо поля при редактировании dbx запросто летят а если есть unique индекс при ручном редактировании может НЕ ОБНОВИТЬСЯ - жди в скором времени проблему. 3. К сожалению не доверять полностью brow - имеет маленькие но ошибки (связанные с relations) что особенно неприятно при глобальной замене. 4. В программе естественно ВЕЗДЕ И ВСЮДУ при ВСЕХ редактированиях делать rlock. Лучше пользоваться модифицированной версией которая имеет параметр в секундах ждать если рекорд кем-то занята или сервер просто "задумался". После редактирования делать DbCommit() и DbUnLock() Как ни странно именно в такой последовательности. Я читал где-то дискуссию почему так а не наоборот можно поискать наверное на той же деже. Я везде поменял (перед этим всегда почему-то использовал DbUnLock а уже потом DbCommit) 5. Для тех кто делает backup. Желательно чтобы в это время юзеры не держали базы данных. С этим есть много проблем. 6. Гоните подальше любителей делать репорты под виндовс. У нас были (и есть) деятели которые напрямую цепляются к базам из R&R, Access'a и т.д. Это к хорошему не приведет. 7. Выкидывайте юзера после 15 минут бездействия! Нечего ему держать базы открытыми. Сделать это можно просто. В цикле где inkey() поставить таймер. Очень помогает!!! 8. Теперь не совсем связанное с индексами но полезное при работе на клиппере. Я все базы данных храню на сервере, а exe-файл на клиенте. Т.е. используется на полную мощь машина клиента на которой уже и так накуплено куча мемори, быстрый хард и т.д. Конечно есть advantage который делает все на сервере но я доволен и такой схемой. Нетворк она и для того создана чтобы иногда перегонять какие-то быйты туда сюда. На клиенте создается директория в которой 4 файла - r.bat, r.exe, check.exe, kbqui.com (помните такую программку длиной 6 байт - устанавливает скорость работы клавиатуры на МАКСИМУМ speed и browse летает !)- так что не надо покупать пентиум 500). В r.bat - 3 строки собственно kbqui, check.exe, r.exe. Что делает check.exe. Она просто сверяет дату и время файлов r.exe на клиенте и на сервере. И если на сервере файл свежее просто копирует его на клиент. Это дает вам возможность обновлять ваш сервер хоть 24 часа БЕЗБОЛЕЗНЕННО для юзеров. Никаких переинсталляций и апгрейдов! Кого интересует конкретно код, пишите вышлю. Это экономит много времени. Опять же только для админа когда он запускает программу можно просто прикрутить переиндексацию всех индексов предварительно закрыв директорию на сервере для старта юзеров. Кстати проверять разрушены ли индексы можно написать простенькую программку которая последовательно открывает все базы с индексами и делает count на кадлый индекс. Если вылетает значит индекс разрушен. Еще одна вещь. Создайте базу где будет имена всех юзеров. Как только кто-то запускает программу находим его запись и БЛОКИРУЕМ ее. Теперь в любой момент можем знать кто в онлайне Просто идем по базе и смотрим если рекорд заблокирована, значит юзер живой еще :) Если даже случится что он вылетет по ошибке запись автоматически разблокируется. Кстати полезно при этом создать error.dbf в которую писать кто когда и где вылетел. Сразу можно подправить, кинуть на сервер и все имеют апдейт при след.запуске! 9. Да и конечно потратьте время и посмотрите на свою нетворк. Что за нетворк, какая скорость, есть ли full-duplex на клиенте, погоняйте файлы туда сюда на предмет скорости. Я когда этим занялся был просто в шоке. Вместо 10Мбит работает еле-еле на 2Мбит, все драйвера установлены по умолчанию т.е. на самую медленную скорость (лишь бы работало) С этим точно могут возникнуть проблемы. Я не могу технически подробно объяснить но такое впечатление что если машина тормозит то на сервере может быть что угодно от потери информации до порчи (кеш опять!) Я думаю даже в самом худшем случае у всех карточки как минимум 10Мбит. Делим на 8. ~1.2 megabyte per second. Теоретически. Практически примем за 1 мег. Копируем файл с сервера на клиент мегабайт 20-30 Засекаем время. Если 20-40 секунд - прекрасно. Если 2-4 минуты - печально. Тут собака и зарыта. Я поисправлял всех своих клиентов (переставил драйвера иптимизировал ) они счастливы правда нетворк суппорт орали сильно. Конечно в каждой ситуации свои проблемы. Но по своему опыту скажу. Нт + 95 можно все таки использовать с клиппером очень даже эффективно и так сразу переходить на другую опер. систему? Не знаю. С протектед моде пришла стабильность. У меня ОЧЕНЬ большая программа (больше 100 000 строк, около 150 баз и все работает)Я сам хотел бы попробовать под линукс. Но пока к сожалению клиенты сидят на 95 + нт. Плюс есть другие программы где миллионы записей и работает вроде все. Если кому что интересно пишите, помогу советом. Виктор

AndreyZh: Dima Конечно спасибо за текст - интересно было вспомнить "основы"! Но за ответом какая последовательность более "правильная" текст отсылает "подальше"! Кроме того в тексте рассуждения по поводу техники, ОС, менталитете пользователей 199х года. Сейчас всё не так! 1. Техника в тысячи раз мощнее 2. ОС семейства NT/Server/Linux 3. Сети 100mb, а скоро приступаем к тесту 1Gb подсети для операторов Кроме этого уже отмечал, что ничего не значит: 1. размер таблицы в mb/gb. Пример нужно было конвертировать табличку, где было 10000 записей * 120 полей * каждое c 255 (размер не помню), у меня она расположена в 10 значащих полях по 5-50 знаков. 2. количество таблиц в базе данных - всё зависит от проектирования и ЗАДАЧИ. Помню в "детстве" на каждого работника заводилась своя таблица, где за год набиралось по 500-5000 записей и работников было теоритически более 10 000 человек (система подотчётных лиц). НУ И ЧТО? Хотя бы примерно скажите в чём мой порядок "неправильный"? - Он реально даёт повышение быстродействия при интенсивной работе с базой!

Dima: AndreyZh Cмотрите ответ Паши в теме http://clipper.borda.ru/?1-0-0-00000441-000-0-0-1234869089 в плане порядка dbcommit() и dbunlock() Так же если Вы все таки читаете ответы в этой теме то посмотрите последний ответ от Петра и Андрея , на мой взгляд все очевидно.

AndreyZh: Пашу сейчас почитаю, а в остальном? Петр: Я, кстати, тоже это приметил. Но подумал может быть просто здесь напутал. А оказывается и в программе Andrey: Так я же с журнала Nantacket списывал, да так и осталось .... Уже подумал, по новому нужно делать.... Да и у Павла "очень обстоятельное разьяснение": редактирование/удаление: if RecLock() read или delete dbCommit() dbUnlock() endif

Dima: AndreyZh пишет: Да и у Павла "очень обстоятельное разьяснение" Просто показана идея. Что снова не так ?

AndreyZh: Просто показана идея. Что снова не так ? Таки тута обсуждение, что первично "курица или яйца", правда непонятко "с какой стороны посмотреть", а именно как более правильно и почему (свои аргументы привёл - мне изменить всю систему просто сменить одну команду препроцессора)? I. DbUnlock*; DbCommit* или II. DbCommit*; DbUnlock*

Dima: AndreyZh пишет: II. DbCommit*; DbUnlock* Именно.

AndreyZh: Именно. Аргументу В СТУДИЮ!!! А что бы мне не быть голословным даю статистику за 3 дня (количество операций детализаций*15) и даже НИ одной жалобы на "тормоза"

Петр: AndreyZh пишет: Аргументу В СТУДИЮ!!! А что бы мне не быть голословным даю статистику за 3 дня (количество операций детализаций*15) и даже НИ одной жалобы на "тормоза" При работе в сети вы должны находить баланс между скоростью и целосностью данных. А также почитайте Clipper Guide To insure data integrity, COMMIT should be issued before an UNLOCK operation или xHarbour Language Reference Guide It is recommended to call COMMIT before UNLOCK.

AndreyZh: Петр При работе в сети вы должны находить баланс между скоростью и целосностью данных. А также почитайте Clipper Guide To insure data integrity, COMMIT should be issued before an UNLOCK operation или xHarbour Language Reference Guide It is recommended to call COMMIT before UNLOCK. AndreyZh Но за ответом какая последовательность более "правильная" текст отсылает "подальше"! Кроме того в тексте рассуждения по поводу техники, ОС, менталитете пользователей 199х года. Сейчас всё не так! 1. Техника в тысячи раз мощнее 2. ОС семейства NT/Server/Linux 3. Сети 100mb, а скоро приступаем к тесту 1Gb подсети для операторов "Учение Ленина правильное потому, что оно верное" что первично "курица или яйца", правда непонятко "с какой стороны посмотреть", а именно как более правильно и почему (свои аргументы привёл - мне изменить всю систему просто сменить одну команду препроцессора???

Pasha: AndreyZh пишет: что первично "курица или яйца", правда непонятко "с какой стороны посмотреть", а именно как более правильно и почему (свои аргументы привёл - мне изменить всю систему просто сменить одну команду препроцессора??? Обьяснение такой последовательности самое простое. Между unlock и commit другой клиент может успеть выполнить rlock - commit. Чтобы этого не произошло, надо сначала сбросить свои данные, и только затем разблокировать запись

AndreyZh: Pasha Между unlock и commit другой клиент может успеть выполнить rlock - commit. Чтобы этого не произошло, надо сначала сбросить свои данные, и только затем разблокировать запись Спасибо! Какое-то объяснение... Теоритически (практически нереальная ситуация в сфере clipper программ) с каким последствиям это сможет привести? При корректно работающей техники и ОС данные не будут разрушаться даже, если не буду вообще использовать DbCommit! Или я не прав (приведите пример "фатального" кода)? А если прав, то моя конструкция обеспечивает лучшее быстродействие (объяснения выше) при ОДИНАКОВОЙ стабильности! Помогите пожалуйста (более актуально на сейчас): Решил собрать с другим терминалом (не gtWin), со всей прогой не пулучилось начал "на мышах" - подключил библиотеки gtWin, gtWVT (далее эксперементально подключал vtgui, библиотеку на которую ссылался Andrey в своём примере wvtgui нигде не нашёл). Если не пытаюсь задействовать gtWVT то прога работает, а даже при попытке HB_GT_WVT_DEFAULT ругается через Win окошко, что нет gui (Честное слово - перед обращением к залу прочитал всю документацию и исходники на англицком языке) Что и как нужно подключать в xHarbour, что задействовать терминал gtWVT, который якобы быстрее в Win 98, да и имеет функцию gtInfo управления терминальным окном?

AndreyZh: Вопрос по терминалам снимается - нашёл проблему методом "тыка", а именно вместо подключения библиотеки gtWin подключил gtWVT. Они не живут вместе?

Pasha: AndreyZh пишет: Они не живут вместе? Живут. Можно линковать программу с несколькими терминалами: указать request на все, которые нужны, default - на предпочитаемый терминал, и линкеру дать все библиотеки терминалов. Есть еще опция при запуске программы, которая прямо активирует нужный терминал: myapp.exe //gtwin или myapp.exe //gtwvt

AndreyZh: Pasha Живут. Можно линковать программу с несколькими терминалами: указать request на все, которые нужны, default - на предпочитаемый терминал, и линкеру дать все библиотеки терминалов. Пробовал - не получалось. Пример: Файл *.bc: LIBFILES = lang.lib vm.lib rtl.lib rdd.lib macro.lib pp.lib dbfntx.lib dbfcdx.lib dbffpt.lib common.lib GTWIN.LIB gtwvt.lib gtgui.lib codepage.lib ct.lib tip.lib pcrepos.lib hsx.lib hbsix.lib zlib.lib Текст в исходнике: REQUEST HB_GT_WVT REQUEST HB_GT_WIN REQUEST HB_GT_WVT_DEFAULT Больше ничего... Получал Win сообщение об отсутствии gui

Pasha: Укажите линкеру опцию -aa

AndreyZh: Укажите линкеру опцию -aa Спасибо! Уважаемые господа! 1. Исправил все найденные раннее ошибки. 2. Собрал с терминалом GTWVT. 3. Подготовил новую тестовую базу - мелкооптовая торговая точка или розничный магазин on-line торговли (любыми товарами). Если не сложно помогите найти ошибки в программах (все пароли 11). Для установки скачать и в любой каталог (c:\harbdist - будут работать все приложенные ярлыки (они же описание программ)), ничего настраивать не нужно. Скачка 2.66mb http://www.zhsoft.nm.ru/demo/USLand.exe

Dima: [IMHO] Сломал все глаза от такого интерфейса. По 10 бальной шкале моя оценка 2. Впрочем на вкус и цвет....... Скрин одной из моих прог ;) Прайс лист

AndreyZh: Впрочем на вкус и цвет....... Золотые слова, впрочем у БЭСТ 3/4 интерфес аналогичен (у меня он был разработан раньше в 1990 году) и следует принципу "максимум информации и инструментов на единицу площади экрана). Для примера все программы комплекса: При этом оператор/аналитик видит всю необходимую ему инфу не углубляясь без нужды в подформы, управление системой для новичков осуществляется клавишами Insert,Tab,Delete,F1,F2,F3,Esc,Enter - все остальные возможности можно вызвать по меню, являющейся справочной системой или нажатием клавиш.

Andrey: Dima пишет: Скрин одной из моих прог ;) Покажи пожалуйста как реализовал вывод картинки и перерисовку экрана ?

Dima: Andrey пишет: как реализовал вывод картинки Wvt_DrawImage( 1,0,23,79, "blabla.jpg" ) Andrey пишет: и перерисовку экрана Не очень понял вопрос. А вообще Wvt_saveScreen , Wvt_RestScreen , хотя это и не совсем верно.

Dima: AndreyZh пишет: Золотые слова, впрочем у БЭСТ 3/4 интерфес аналогичен (у меня он был разработан раньше в 1990 году) и следует принципу "максимум информации и инструментов на единицу площади экрана) Я конечно понимаю что критику Вы не очень уважаете , но у Вас по моему просто перебор с максимумом информации в менюшках. Это не меню а газета какая то. Писец..... Молчу уже про убогий браузер. Впрочем ладно..........Просто хотел дать добрый совет.

AndreyZh: Доброе утро! Пока не поехал на огород... Dima Если есть желание покритиковать саму систему - интерфейс, функционал, механизмы хранения и обработки информации, то может бы заведу отдельную тему. Всё-таки здесь интересны "несовместимости" и ошибки в её работе. Я конечно понимаю что критику Вы не очень уважаете Непонятно от куда такие выводы? Если замечание сделано "в любой форме", оно полезно и имеет целью помочь в решении проблемы, то, можете обратить внимание - ему очень благодарен. Если же оно ввиде просто оскорблений брошенных в воздух, то это воспринимается не более как попытка "засрать эфир". у Вас по моему просто перебор с максимумом информации в менюшках НЕ ПОНЯЛ. Если это о меню вызова отчётов, то их сотни и вынужден давать подробные пояснения в наименовании пунктов меню, если о меню в оперативных режимах, то количество слов в п.п. минимально необходимое для описания выполняемого действия??? Молчу уже про убогий браузер Это интересно. Можно подробнее определение или описание механизмов "правильного браузера" - его реализую в какой-нибудь подзадаче и проверю (протестю) на пользователях (им же с этим работать).

AndreyZh: Добрый вечер! Уважаемые реальные и "виртуальные" пользователи моей системы "нарыли" серию ошибок и несовместимостей, которые конечно "с чей-то матерью" исправил. Думаю Вам будет интересно (xHarbour версия от 12.2009). Clipper 5.01R+CT2 без проблем "хавает": 1. При сохранении файлов. Русские имена файлов и каталогов преобразуются в "абракадабру". Лечение - имя (символьные переменные) преобразовывать функцией HB_OEMTOANSI. 2. На клавише F3 висит вызов справочников - вызывается функция, в которой по имени переменной вызывается соответствующий справочник. При нажатии вне команды GET системы возвращают "пустое" имя -- Clipper программа его игнорирует, xHarb пытается вызвать "первый в списке" справочник. Лечение - проверять имя на "пустоту". 3. Поведение xHarb в некоторых случаях зависит от последовательности вызова функция, хотя логически она не должна иметь значения. Например: hb_gtInfo(GTI_FONTWIDTH, 15) hb_gtInfo(GTI_FONTSIZE, 32) Другой порядок приводит к сбоям (спасибо местным гуру, а то бы считал, что ф-ция gtInfo не рабочая). ЭКСПЕРИМЕНТИРУЙТЕ!!! 4. Несовместима функция memoedit. Мой вариант приводил к "зависанию" системы. Спасибо за подсказку обработки функции пользователя: #include "Inkey.ch" #include "Memoedit.ch" [pre2]FUNCTION myfunc() LOCAL nKey := LastKey() LOCAL nRet := ME_DEFAULT // Критичная добавка DO CASE CASE nKey IN { K_ALT_W, K_CTRL_W, K_ESC } nRet := ME_IGNORE // Критичная добавка // ignore default termination keys CASE nKey == K_F2 nRet := K_ALT_W // Save with F2 CASE nKey == K_ALT_C nRet := K_ESC // Cancel with Alt+C ENDCASE // RETURN nRet [/pre2] 5. Грубая ошибка xHarbour машины (отошлите, если интересно разработчикам). Имеем обычную форму ввода, где на последнем вопросе задаётся символ разделитель дробной части: local getlist:={}, bbb:=spac(50), ccc:=" " .... @ 1,1 say aaa get bbb @ 1,2 say sss get ccc read .... преобразовывается файл ... ФОРМА ЗАПРОСА ВЫВОДА НА УСТРОЙСТВО ------------------------ Если ссс - это символ точки, запятой, тире, .... то форма запроса переходит в бесконечный цикл xHarbour пихает всегда Chr(15) -- при других знаках всё работает корректно (~=/\| и т.д.). Лечение: После READ сразу набор команд if readkey()==K_CTRL_O KEYB Chr(K_ENTER) WAIT " " LOOP // Переход снова на форму ввода устройства вывода endif ---------------------------------------------- Вообще спасибо "местным" профи - в темах можно найти ответы на множество проблем. Система исправлена и выложена со всей документацией (4.01 mb) http://www.zhsoft.nm.ru/demo/USLand.exe Все надеюсь на помощь профи в поиске ошибок

Pasha: AndreyZh пишет: Имеем обычную форму ввода, где на последнем вопросе задаётся символ разделитель дробной части: local getlist:={}, bbb:=spac(50), ccc:=" " .... @ 1,1 say aaa get bbb @ 1,2 say sss get ccc read .... преобразовывается файл ... ФОРМА ЗАПРОСА ВЫВОДА НА УСТРОЙСТВО ------------------------ Если ссс - это символ точки, запятой, тире, .... то форма запроса переходит в бесконечный цикл xHarbour пихает всегда Chr(15) -- при других знаках всё работает корректно (~=/\| и т.д.). А можно уточнить, что имеется в виду: "преобразовывается файл, ФОРМА ЗАПРОСА ВЫВОДА НА УСТРОЙСТВО" А еще лучше привести фрагмент программы

AndreyZh: Pasha А еще лучше привести фрагмент программы Добрый день! Прошу прощение за длинный текст, т.к. подход универсальный: [pre] * Пример пострения отчёта STAT PROC pObFins() LOCA cOldCol:=SetColor(), .... LOCA cOff:=" " ----- @ 1,1 SAY "Пожалуйста вв. дату начала ........ конца ........ периода" @ 6,1 SAY "Разделитель чисел для экспорта в MsOffice или ничего ." @6,58 GET cOff // Если отлично от пустого, то заменяется разделитель точка на введённый знак в обычном текстовом файле READ ------ cTxt := zTemp(cdTemp,"TXT",32) // Создаётся текстовый файл, который ниже заполняется ------ IF !Empty(cOff) // Экспорт в офис ? "Оборотная ведомость по "+IF(nCash=1,"кассе",IF(nCash=2,"банку","деньгам"))+" с "+Dtoc(dBeg)+" по "+Dtoc(dEnd) ? " Подпериод времени Ост. на начало Приход Расход Ост.на конец " DO WHIL !Eof() ------- Заполнения файла из временной таблицы IF dMove > dD // Перешли в другой подпериод. Отражаем итоги. ? IF(nPer==0,Left(Cmonth(dT)+Spac(17),17)+Str(Year(dT),4),Dtoc(dT)+" - "+Dtoc(dD))+" "+zStr(nBeg,14,2,cOff)+" "+zStr(np,12,2,cOff)+" "+zStr(nr,12,2,cOff)+" "+zStr(nBeg+np-nr,14,2,cOff) ++nStr ENDI DbSkip() ENDD // Отражаю данные по последнему периоду и общие итоги. ? IF(nPer==0,Left(Cmonth(dT)+Spac(17),17)+Str(Year(dT),4),Dtoc(dT)+" - "+Dtoc(dD))+" "+zStr(nBeg,14,2,cOff)+" "+zStr(np,12,2,cOff)+" "+zStr(nr,12,2,cOff)+" "+zStr(nBeg+np-nr,14,2,cOff) ? Chr(12) ELSE // Печатаемый формат ENDI ----- // Демонстрирую отчет и восстанавливаю состояние среды. pFileOutDevice(cTxt) // Место появления глюка pCloseErase("TEMP",{cDbf,cNtx,cTxt}) pinStat(sOp,0) RETU [/pre] И сама функция(ии) вывода на устройства - довольно большая [pre] * ---------------------------------------------------------------------------- * Вывод на принтер/файл/монитор содержимого файла переданного как параметр. * 02.2004 Добавил паралельный вывод отчетов отправляемых в файл. * 12.2004 Преобразование в MsExcel через систему печати ХБК * 09.2006 Конвертация в Ms Word формат. * 06.2007 При выводе в файл разрешено отражать имя с основанием из-за OpenOff * 03.2008 Удалил вывод отчетов в дублированный каталог -- никто не использует * 06.2010 xHarbour русские буквы переводит в странной кодировке. Делаю преобразование. PROC pFileOutDevice( cFile, nLen, nW, cdbfm ) FIEL compr, filen, begStr, endStr, qtyCopy LOCA nDev := 1 // Устройство вывода 1-принтер,2-файл,3-экран,4-ХБК,5-Excel через ХБК,6-Принтер через редактор LOCA nBeg := 1 // Начальная страница LOCA nEnd := 9999 // Конечная страница. LOCA nQty := 1 // Количество экземпляров. LOCA cOldCol:=SetColor(), nSel:=Select(), cStr:="", aDbf:={}, cF:="" LOCA nSize:=FileSize(cFile), cString:="", GetList:={} LOCA nI:=0, cSt:="" LOCA axbk:={{"compr", "L", 1, 0},; // Посылка в программу ХБК {"filen", "C", 70, 0},; {"begStr", "N", 10, 0},; {"endStr", "N", 10, 0},; {"qtyCopy", "N", 10, 0}} PRIV cNameFile:="", cOutFile:="" DEFAULT nLen TO 80 DEFAULT nW TO 6 DEFAULT cdbfm TO "" MEMV->cNameFile := AllTrim(cFile) fSwopen(16,17,7,60,cOther,4) DO WHIL TRUE // Из ЭФ читаем параметры печати. @ 5,0 SAY Chr(199)+Repl("─",59)+Chr(182) COLO PosRepl(cOther,Repl(" ",AT("/",cOther)-2)+"N",1) @ 1,2 SAY "Для печати отчета/документа пожалуйста укажите устройство" @ 2,2 SAY "1-Принтер,2-Файл,3-Экр,4-ХБК,5-ExcХБК,6-Редактор,7-Word ." @ 3,2 SAY "начальную и конечную страницы из документа" @ 4,2 SAY "а также количество экземпляров печати документа " @2,58 GET nDev PICT "9" VALI nDev>=1 .AND. nDev<=7 @3,12 GET nBeg WHEN nDev==1.OR.nDev==4 PICT "9999" VALI nBeg>=1 @3,30 GET nEnd WHEN nDev==1.OR.nDev==4 PICT "9999" VALI nBeg<=nEnd @4,56 GET nQty WHEN nDev==1.OR.nDev==4 PICT "999" VALI nQty>=1 READ ************* Смотреть как Lack будет реагировать на данный обработчик глюка. //*** Обработка глюка xHarb когда посылает код 15, если .,- в формате экспорта в офис IF ReadKey() == K_CTRL_O KEYB Chr(K_ENTER) WAIT "" LOOP ENDI // Если отказ, то выход из режима печати. IF LastKey() == K_ESC THEN EXIT DO CASE CASE nDev == 1 // Принтер. Печатаем по одной строке с проверкой статуса принтера. @ 6,1 SAY Padc("Выводим документ/отчет/справку..",58) pPrFile( cFile, nBeg, nEnd, nQty, nLen, nW ) @ 6,1 CLEA TO 6,59 CASE nDev == 2 // Файл. cOutFile := Spac(12) @ 6,2 SAY "Введите имя файла (можно с расширением) " GET cOutFile VALI lOutFile(zConv(cOutFile)) READ // Преобразование имени файла для минимизации ошибок cF := AllTrim(cOutFile) IF At(".",cF) > 0 // Файл с расширением cF := Left(Alltrim(Token(cF,".",1)),8)+"."+Right(Alltrim(Token(cF,".",2)),3) ELSE // Расширение REP по умолчанию cF := AllTrim(Left(cF,8))+".REP" ENDI IF LastKey() <> K_ESC COPY FILE (MEMV->cNameFile) TO (cDreport+AllTrim(zConv(cF))) ENDI @ 6,1 CLEA TO 6,58 CASE nDev == 3 // Экран. Используем программу просмотра файлов неогр.длины IF !lLookFile( cFile, 0, 0, 24, 79, cColor ) ErrMess("Системная ошибка... Попробуйте еще раз..",cError) ENDI CASE nDev == 4 // Система "хочу быть крутым!" // Анализ на наличие системы на компьютере. IF cPathXBK <> NIL // Имеется настройка ХБК IF !Empty(cPathXBK) // Имеется настройка ХБК IF File(cPathXBK+"LS_WORKS.DBF") // Сист. ХБК запущена // Ожидание, пока ХБК не удалит предыдущую посылку - не напечатает документ. IF lFileXbm(cPathXBK+"XBM.DBF") // Можно печатать документ. DbCreate(cPathXBK+"XBM.DBF",axbk) LanUse(cPathXBK,"XBM",NO_INDEX,"TXBM",SHAR_MODE,-1,NEW_SEL) FilLock(-1) DbAppend() compr := (nLen == 132) filen := IF(At(":",cFile)>=1,Alltrim(cFile),DiskName()+":\"+CurDir(DiskName())+"\"+AllTrim(cFile)) begStr := nBeg endStr := nEnd qtyCopy := nQty DbCloseArea() DbSelectArea(nSel) // Ручное управления для блокирования коллизий @ 6,1 SAY Padc("После ПОЛНОГО окончания печати нажмите Esc",58) Inkey(0) /**** Делаю для торопыг дополнительную паузу. Если нажать Esc, то файл печати сотрется и ХБК выдаст диагностическую ошибку */ WHIL TRUE Inkey(0.3) IF File(cPathXBK+"XBM.DBF") IF Fyn("Предыдущая печать не окончена! Прервать ее?",cError) THEN EXIT ELSE EXIT ENDI END @ 6,1 CLEA TO 6,58 ELSE ErrMess("Не получилось. Попробуйте еще раз!",cError) ENDI ELSE ErrMess("Система ХБК не запущена на компьютере или не верен маршрут к ней!",cError) ENDI ELSE ErrMess("Каталог системы ХБК не определен!",cError) ENDI ELSE ErrMess("Каталог системы ХБК не определен!",cError) ENDI CASE nDev == 5 // Система "хочу быть крутым!" преобразует БД в таблицу Excel cOutFile := Spac(8) @ 6,2 SAY "Введите имя файла латинскими буквами " GET cOutFile VALI !Empty(cOutFile) READ IF LastKey() <> K_ESC IF !Empty(cdbfm) cOutFile := Upper(AllTrim(zConv(cOutFile)))+".mse" // Анализ на наличие системы ХБК на компьютере. IF cPathXBK <> NIL // Имеется настройка ХБК IF !Empty(cPathXBK) // Имеется настройка ХБК IF File(cPathXBK+"LS_WORKS.DBF") // Сист. ХБК запущена // Пауза. Пока ХБК не обработает предыдущий одноименный файл. WHIL File(cPathXBK+cOutFile) Inkey(0.1) @ 6,1 SAY Padc("Для убыстрения на Windows 9x переключитесь на ХБК.",45) END SELE (cdbfm) COPY TO (cPathXBK+cOutFile) @ 6,1 SAY Padc("Файл "+AllTrim(cOutFile)+" записан..",58) ELSE ErrMess("Система ХБК не запущена на компьютере!",cError) ENDI ELSE ErrMess("Каталог системы ХБК не определен!",cError) ENDI ELSE ErrMess("Каталог системы ХБК не определен!",cError) ENDI ELSE ErrMess("Отчет пока не преобразуется в таблицу Excel!",cError) ENDI ENDI @ 6,1 CLEA TO 6,58 CASE nDev == 6 // Редактор. IF nSize <= 64000 cString := MemoRead(cFile) // Читаю файл в строку fswOpen(0,0,24,79,cMainc,13) @ 0,0 SAY REPL("─",9)+REPL("┼─────────",7) @24,0 SAY "При желании можно отредактировать документ, запрос на печать появится после Esc" @ 1,0 CLEA TO 22,79 DispBox( 23, 0, 23, 79, 2 ) cString := MemoEdit(cString,1,0,22,79,TRUE,"FMEdit",232) MemoWrit( cFile, cString ) fDeact(cOther) /* Старый блок работы с редактором cString := MemoRead(cFile) fswOpen(0,0,24,79,cMainc,13) @ 0,0 SAY REPL("─",9)+REPL("┼─────────",7) @24,0 SAY "При желании можно отредактировать документ, запрос на печать появится после Esc" @ 1,0 CLEA TO 22,79 DispBox( 23, 0, 23, 79, 2 ) MemoWrit( cFile, MemoEdit(cString,1,0,22,79,TRUE,"FMEdit",232) ) fDeact(cOther) */ ELSE ErrMess("Отчет слишком большой для редактирования!",cError) ENDI CASE nDev == 7 // Формат Ms Word посредством системы ХБК. cOutFile := Spac(8) @ 6,2 SAY "Введите имя файла латинскими буквами без точек " GET cOutFile VALI !Empty(cOutFile) READ IF LastKey() <> K_ESC // Блокирую ситуацию указать расширение в имени файла cOutFile := Upper(AllTrim(Left(AllTrim( cNoSpecSimb(cOutFile) ),8)))+".wrd" cOutFile := zConv(cOutFile) // Анализ на наличие системы ХБК на компьютере. IF cPathXBK <> NIL // Имеется настройка ХБК IF !Empty(cPathXBK) // Имеется настройка ХБК IF File(cPathXBK+"LS_WORKS.DBF") // Сист. ХБК запущена // Пауза. Пока ХБК не обработает предыдущий одноименный файл. WHIL File(cPathXBK+cOutFile) Inkey(0.1) @ 6,1 SAY Padc("Для убыстрения вывода переключитесь на ХБК.",58) END COPY FILE (MEMV->cNameFile) TO (cPathXBK+cOutFile) @ 6,1 SAY Padc("Файл "+AllTrim(cOutFile)+" записан..",58) ELSE ErrMess("Система ХБК не запущена на компьютере!",cError) ENDI ELSE ErrMess("Каталог системы ХБК не определен!",cError) ENDI ELSE ErrMess("Каталог системы ХБК не определен!",cError) ENDI ENDI @ 6,1 CLEA TO 6,58 ENDC ENDD fDeact(cOldCol) * fErase(cNameFile) RETU * --------------------------------------------------------------------------- * Вывод текстового файла на принтер в соответствии с параметрами и при * этом проверяется статус принтера при отражении каждой строки и в начале STAT PROC pPrFile( cFile, nBeg, nEnd, nQty, nLen, nW ) LOCA nPage:=0 /*Текущая страница*/, nH:=0 /*handle*/, nQ:=0/*копии*/ LOCA cBuff:="" /*буфер чтения*/, cStr:="" /*буфер печати*/ LOCA nSize:=2048 /*размер буфера чтения*/, cCur:="" /*текущая строка*/ LOCA nI:=0, lStat:=TRUE, nJ:=0, lStr:=TRUE IF !File( AllTrim(cFile) ) THEN RETU // Проверяем статус принтера перед выводом файла. IF !PrintReady() ErrMess("Принтер не готов... Включите его и попробуйте еще раз.",cError) RETU ENDI // Устанавливаем принтер используя стандартную команду операц.системы SET CONS OFF SET PRINTER ON DO CASE CASE nLen==80 .AND. nW==6 RUN MODE LPT1:80,6 >NUL CASE nLen==80 .AND. nW==8 RUN MODE LPT1:80,8 >NUL CASE nLen==132 .AND. nW==8 RUN MODE LPT1:132,8 >NUL CASE nLen==132 .AND. nW==6 RUN MODE LPT1:132,6 >NUL ENDC nH := Fopen( cFile, 0 ) // Открываем файл для чтения BEGIN SEQU // Выводим текст из файла на принтер по одной копии FOR nQ := 1 TO nQty Fseek( nH, 0/*смещение*/, 0/*начало*/ ) nPage := 1 // Начальная страница. // Выводим на принтер текущую копию, анализируя необходимость вывода WHIL Len( cBuff:=FreadStr(nH,nSize) ) <> 0 cStr += cBuff lStat := TRUE WHIL TRUE // Не можем выделить подстроку из накапливаемой строки. IF ( nI:=At(CRLF,cStr) ) == 0 THEN EXIT cCur := Subs( Token(" "+cStr,CRLF,1), 2 ) nJ := At( Chr(12), cCur ) // Признак окончания страницы, переводим текущий счетчик IF nJ <> 0 THEN lStr := FALSE cStr := Subs( cStr, nI+2 ) IF nPage >= nBeg .AND. nPage <= nEnd // Сбой на принтере. Отказ пользователя от дальнейшей печати. IF !lPrStr( cCur ) THEN BREAK ENDI nPage += IF( lStr, 0, 1 ) lStr := TRUE END END NEXT nQ END Fclose( nH ) RUN MODE LPT1:80,6 >NUL SET PRINTER OFF SET CONS ON RETU * --------------------------------------------------------------------------- * Функция распечатки строки с проверкой статуса принтера. STAT FUNC lPrStr( cStr ) cStr := cStr+CRLF IF Inkey() == K_ESC THEN RETU FALSE ?? cStr RETU TRUE * --------------------------------------------------------------------------- * Функция проверки правильности имени введенного файла *.rep * 06.2007 Разрешено расширение. Возвращаю преобразованное имя файла. STAT FUNC lOutFile(cFile) cFile := AllTrim(cFile) // Запрет пустого имени IF Empty(cFile) THEN RETU FALSE IF At(".",cFile) > 0 // Файл с расширением cFile := Left(Alltrim(Token(cFile,".",1)),8)+"."+Right(Alltrim(Token(cFile,".",2)),3) ELSE // Расширение REP по умолчанию cFile := AllTrim(Left(cFile,8))+".REP" ENDI // Проверка на существование IF File(cDreport+AllTrim(cFile)) IF !Fyn("Файл с введенным именем существует... Переписать?",cError) THEN RETU FALSE ENDI RETU TRUE [/pre]

Dima: AndreyZh пишет: подход универсальный: И это называется самодостаточный пример "ГЛЮКА" ? Проще можно изложить проблему ?

Pasha: я тоже ничего не понял Дать самодостаточный пример означает, что ничего, не имеющего отношения к глюку, в примере не должно быть. Скажем, глюк связан с созданием файла ? Если да - в примере должно быть создание файла, если нет - то нет. LOCA cOldCol:=SetColor() LOCA cOff:=" " @ 1,1 SAY "Пожалуйста вв. дату начала ........ конца ........ периода" @ 6,1 SAY "Разделитель чисел для экспорта в MsOffice или ничего ." @6,58 GET cOff // Если отлично от пустого, то заменяется разделитель точка на введённый знак в обычном текстовом файле READ А дальше ? Кратко изложите, как проявляется глюк

AndreyZh: Добрый день! Эта одна из многих ситуаций, почему программирование на Harbour назвал "прогулками по минному полю"... Из-за любопытства пытался сделать "простой" пример данной ситуации вне "большого комплекса", НО НЕ СМОГ породить её!!! Но в самом комплексе ситуация "универсальная"! В принципе Dima ставил "старый вариант" у себя - он ещё содержит данную проблемы. Как её выявить: (например) Программа hld/динамическая отчётность/любой отчёт. В конце формы настройки есть запрос - символ разделитель для экспорта в офис - своеобразная форма отчёта без декоративных элементов, где символ точка заменяется на определённый в запросе. После построения появится форма для вывода на устройства с "явными признаками зацикливания", что прерывается клавишей Esc. В новой версии исправлена данная проблема добавкой кода (повторюсь): [pre]// Из ЭФ читаем параметры печати. @ 5,0 SAY Chr(199)+Repl("-",59)+Chr(182) COLO PosRepl(cOther,Repl(" ",AT("/",cOther)-2)+"N",1) @ 1,2 SAY "Для печати отчета/документа пожалуйста укажите устройство" ....... @2,58 GET nDev PICT "9" VALI nDev>=1 .AND. nDev<=7 ...... READ // Обработка глюка xHarb когда посылает код 15, если .,- в формате экспорта в офис IF ReadKey() == K_CTRL_O KEYB Chr(K_ENTER) WAIT "" LOOP ENDI [/pre]

Pasha: Я все-таки не могу понять, в чем заключается глюк Глюк связан с GET - системой ? После READ (ReadModal) получается неправильное значение односимвольной переменной ? Или после READ возникает какое-то последействие в функцих типа READKEY() ? Или глюк связан с вложенным READ, т.е в обработке READ вызывается еще один READ ? Создание файла существенно, или это просто сопутствующее действие ? Код 15 (ctrl+o) вводится с клавиатуры ? Попробуйте описать словесно, отбросив все несущественные детали

AndreyZh: Я все-таки не могу понять, в чем заключается глюк Я тоже ХЗ? На мелкой тестовой эмуляции не сумел породить проблемы, а в "большой" системе она "стабильная", т.е. какая функция xHarbour порождает посылку коммандных кодов пока не понял. Как это проявляется? 1. Запрос ограничителей отчёта. Последний вопрос о знаке разделителе (.,/ порождают глюк, любые другие символы работают корректно). 2. Строится отчетный текстовый файл, где в числах точка заменяется указанным символом. 3. Всё (txt. времянки) закрывается. 4. Запускается функция вывода на устройство (принтер,файл,экран,win система,Excel,редактор,Word) и в ней вызывается форма настройки вывода, т.к. по умолчанию стоит "принтер", то система не переходит в ожидание READ, а циклично тужится отправить на него, если он выключен, то цикличный запрос печати (нормально прерываемый ESC). // Обработка глюка xHarb когда посылает код 15, если .,- в формате экспорта в офис IF ReadKey() == K_CTRL_O KEYB Chr(K_ENTER) WAIT "" LOOP ENDI Данным кодом я блокирую ситуацию, т.е. "от куда то" посылается код K_CTRL_O (15) и от него ни как не избавится (чистка буфера клавиатуры ничего не даёт), но даёт принудительная посылка K_ENTER, которая "подтверждает" запрос WAIT (что прекращает посылку кодов от xHarbour), после чего читаю форму заново.

Pasha: т.е., если по Read в односимвольную переменную вводится один из символов: .,/ следующий за ним Read не переводит программу в режим ожидания ввода, а зацикливается ? Т.е. в буфере клавиатуры остаются какие-то коды, которые влияют на последующий READ ? Терминал gtwin или gtwvt ? Если gtwin, то для gtwvt этот глюк проявляется ? А где в программе цикл и какое условие выхода из цикла ?

AndreyZh: т.е., если по Read в односимвольную переменную вводится один из символов: .,/ Да, в конце большого блока запросов. следующий за ним Read не переводит программу в режим ожидания ввода, а зацикливается ? В "большой" программе ДА и стабильно (не зависимо от конкретного отчёта), в тестовых мелких программках не смог породить данной ситуации. Т.е. в буфере клавиатуры остаются какие-то коды, которые влияют на последующий READ ? В том-то и ... При "придумывании" приведённоё затычки ни чего в буфере клавиатуры не находил. Chr(15) прилетает, как будто из ниоткуда. Терминал gtwin или gtwvt ? Последние варианты gtwvt (ссылки даны http://www.zhsoft.nm.ru/demo/USLand.exe ), сейчас проверю на gtwin из ссылки первого сообщения темы (что то плохо качает). В GTWIN теже коки! А где в программе цикл и какое условие выхода из цикла ? 1. Читаем параметры печати. READ 2. IF LastKey() == K_ESC то выход из цикла. 3. Обработка вывода на требуемое устройство 4. Переход на 1. Реализовано whil .t. <...> end Если Вам не сложно - скачайте архив из первого поста и легко сможете сами убедиться (в последней ссылке проблема исправлена)

Dima: AndreyZh пишет: Chr(15) прилетает, как будто из ниоткуда. Полтергейст А попробуй запустить прогу в режиме защиты от сбоев (я про Windows) , будет тот же "Полтергейст" ?

AndreyZh: Полтергейст? А попробуй запустить прогу в режиме защиты от сбоев (я про Windows) , будет тот же "Полтергейст" ? Данный "глюк" людям демонстрировал под (разные конторы) Windows 98/ХР Home/Prof/Windows Server/Windows 7 (сейчас проверил и в режиме защиты от сбоев). К тому же Вы легко можете его увидеть, например: - Программа hld - <Динамика> Отражение работы фирмы в динамике - Любой отчёт данного блока/берёте любой период/остальное соглашаетесь - На вопрос "знак разделитель экспорта в офис", если возьмёте (.,) получите "барабашку", другой (не все перепроверил) знак - нормальный отчёт

Pasha: Я нашел этот глюк. Самодостаточный пример: Local cChar := ' ', n := 1 Local GetList := {} cls @ 1,0 say 'Char' get cChar read @ 2,0 say 'number' get n picture "9" read wait Причина глюка: soruce/rtl/tget.prg, line 715: IF ::Type=="N" .AND. ::hasfocus .AND. (::DecPos=NIL .OR. ::DecPos > ::nMaxLen ) .AND. ( LastKey()=Asc(',') .OR. LastKey()=Asc('.') ) Я написал в devlist, пусть Эдуардо Фернандес исправляет PS. С Днем Победы !

AndreyZh: Pasha Супер! Я восхищён! Надеюсь сам когда нибудь научусь так разбираться в исходниках системы разработки...

Петр: Самодостаточный пример: В Harbour все OK.

Pasha: Эдуардо уже исправил этот глюк

AndreyZh: Эдуардо уже исправил этот глюк Оперативно! Но зачем то приведённый Вами "...IF ::Type=="N" .AND. ::hasfocus .AND..." фрагмент исходника создавался? Интересно какой в нём смысл? Для общего развития (в htm инструкции не нашёл): 1. Какая максимальная длина массива в xHarbour? 2. До кучи, что означают :: в фрагменте кода?

Pasha: Устранялась какая-то несовместимость с picture, точно не скажу какая, это было несколько лет назад. То есть, намерения были самыми благими, но реализация неудачной - внесен другой глюк. Максимальный размер массива для 32-битных систем - теоретически - 2^32 степени, т.е. 4 млрд. элементов, для 64-битных систем - 2^64 степени. Практически конечно меньше. Этот фрагмент кода - метод display класса get, а символ "::" - обращение к полям и методам объекта класса get. Такой синтаксис ООП в харборе.

AndreyZh: Pasha Спасибо за конкретный и полный ответ!

AndreyZh: Добрый день! Прикол: Описанная проблемка xHarbour с обработкой READ и исправлением кодом READ IF ReadKey() == K_CTRL_O KEYB Chr(K_ENTER) WAIT "" LOOP ENDI Выявило, что данный "глюк" тянется из Clipper - данный блок не даёт считать цифру 1 (устройство - принтер) - происходит "зацикливание", если все вопросы формы подтверждать Enter (код клавиши 13, а не 15). Другие цифры (устройства) или подтверждение клавишей PgDown обрабатывается корректно. Могет кому-то это интересно.

Andrey: Вообще то всегда нужно делать чистку буфера клавиатуры после обработки.... Тогда глюков не будет. Я такие конструкции даже и не создаю, после граблей еще на 5.01

Stim: Andrey пишет: Вообще то всегда нужно делать чистку буфера клавиатуры после обработки.... А как ты это делаешь, если не секрет?

Dima: Stim пишет: А как ты это делаешь, если не секрет? Вероятно командой CLEAR TYPEAHEAD

Stim: Dima пишет: Вероятно командой CLEAR TYPEAHEAD Точно! Thanks!

gustow: Я иногда (уж не помню теперь из каких резонов) делал не просто CLEAR TYPEAHEAD, а еще после нее втыкал KEYBOARD CHR(0) ... Видимо, от чего-то нежелательного помогало: или CLEA TYPE не до конца все что надо зачищал, или просто чтобы, например, функция пользователя в DBEDIT() "вхолостую" отработала... не помню... но помню, что от чего-то "излечивало". И, кстати, перед командой ожидания нажатия клавиши (перед INKEY(0) или READ) тоже буфер клавиатуры чистил.

AndreyZh: Добрый вечер господа! clea type не работает с данными "глюками". До кучи cmonth не руссифицирован, т.е. пришлось сделать свою функашку. Кроме того, не понятно почему users утверждает, что периодически программа на xHarbour вылетает без сообщений и логов на тех Пк не обнаружил. Продолжается неспешное тестирование практически у всех пользователей (резких шагов не предпринимая до "отпуска") постепенно переводя множество других программ комплекса на xHarb с целью выявления Clipper багов. Спасибо за внимание к теме!

Dima: AndreyZh пишет: До кучи cmonth не руссифицирован А если так попробовать. [pre] Proc main REQUEST HB_LANG_RU866 HB_LANGSELECT("RU866") ? cmonth(date()) return [/pre]

Dima: AndreyZh Как дела с переходом на (X)Harbour , или забил на это ? Просто интересно.

AndreyZh: Спасибо Dima за внимание! Неспешно система тестируется пользователями. Находятся мелкие глюки исправляемые без обращения к уважаемому сообществу. При этом немножко "зарылся" в задачках поставлемых государственными ведомствами, в частности по алкоголю и новом внедрении. Но на ряде предприятий (не критичных) система на xHarbour уже работает в реальном режиме. Серьёзные внедрения по всем конторам скорее всего начнуться с конца сентября. Вот тогда останеться надеяться на оперативную помощь специалистов данного форума.

AndreyZh: Добрый день! Небольшой отчётик о попытках продвижения системы УС Land реализованной на xHarbour в "широкие массы": I. Перевод "старых" пользователей идёт крайне туго... Из десятка магазинов, где перевёл (а это мизер) со скандалом отказались 4 магазина мотивируя: 1. Невозможностью использовать полный экран 2. Активным невосприятием шрифта 3. Якобы (мне так и не показали) периодическим временным подвисанием (на 0.5-2 секунды) программ во время оперативной работы 4. Неудобством Win переключением шрифтов и прочие надуманные причины. II. Перевод у "основного спонсора" должен делать их ИТ отдел. Под него пришлось переписать на xHarb ещё 4 уникальные программы, но они не торопятся переводить: 1. И так ништяк 2. Слишком много настроек переделывать 3. Гемор с прочими бизнес задачами... А для меня переход их на УС Land был бы мощнейшем аргументом для остальных пользователей... Так, что когда смогу спокойно работать только с одной системой разработки - уже не знаю. Спасает несколько моментов: 1. Клиппер и Харбоур системы используют единный исходный код и таблицы, т.ч. переходы вперед-назад решаются только переиндексацией 2. Пользователи из Интернет в основном юзают систему на xHarb присылая замечания по ошибкам, которые периодически исправляются (в обоих системах) Думаю будет интересно. Очередная партия исправленных несовместимостей: 1. Упоминалось. Разный подход к оформлению пользовательских функций в memoedit. 2. Изменил шрифт программ и сейчас размер шрифта (окна Win-dows) адаптируется к разрешению экрана. 3. К окнам добавлены иконки соответствующих программ. 4. Глобальная проблемка (исправил) – при выводе в файл (несмотря на предупреждение делали имена файлов русскими – система это игнорировала) - УС Land не воспринимал русские имена файлов. 5. Отсутствие функции анализа готовности принтера PrintReady – теперь программы печатают на любое устройство печати системы, а так решил проблему печати на матричный принтер (устройство – 1 Принтер). 6. Вылет программы, если она требовала для работы передачи внешнего параметра, но ничего не передавалось. Сейчас задаю «параметр по умолчанию». 7. Название месяца/недели. Данные наименования давались «аглицком» - сейчас по-русски. 8. Решена «потенциальная» проблема. Вылет программы по ошибке при некоторых последовательностях операций в режиме списания товаров (более строгая работа с БД). 9. Переделаны (созданы) под «нюансы» xHarbour ВСЕ программы комплекса. А именно: - HLO – система «внешних» заказов. - HLVZ – эмулятор систем КПК на персональных компьютерах. - HLKPK – интерфейс к системе «МТ – Мобильная торговля». - HLRA – интерфейс к системе мобильной торговли «Оптиум». - HLSM – ограниченный (для ГНИ) вариант «оперативной» программы. При желании "последнюю" версию системы можно скачать со страницы Версия УС Land - Август.2010 года

Pasha: А не пробовали использовать letodb ? По крайней мере был бы аргумент "стало намного быстрее", уж не говоря об остальном Из своего опыта использования letodb: там, где БД небольшая и скорость некритична, переход от DBFCDX к LETO прошел для пользователей почти незаметно. На большой БД, где мне постоянно жаловались на медленную работу, а так оно и было, и я ничего не мог поделать, после установки letodb поиск и выборки стали в разы быстрее, что сразу было заметно. Была у меня и замена ADS на LETO. Вечером, после работы, я сделал все необходимые изменения в настройках, остановил ADS, запустил LETO. Утром пользователи включились, и.. никаких изменений не увидели, будто ничего не произошло.

Pasha: AndreyZh пишет: 1. Упоминалось. Разный подход к оформлению пользовательских функций в memoedit. Я тоже когда-то бодался с несовместимостями в memoedit, пока не сказал себе: а зачем мне все эти архаизмы, тяжелое наследие summer'87, эти странные пользовательские функции И стал использовать нативные средства харбора, класс HBEditor Примерно так: oEd := HBEditor():New( ct, nTop, nLeft, nBottom, nRight, .t., nLen, nTab ) oEd:RefreshWindow() while ! oEd:lExitEdit nKey := Inkey(0, 255) if bUser # nil nKey := Eval(bUser, nKey) endif oEd:Edit( nKey ) enddo

AndreyZh: Спасибо Pasha за реакцию на сообщение! В принципе достаточно полно изучил большинство тем по Harbour и данная система, как "программиста" меня весьма вдохновляет... Более того достаточно активно занимаюсь её продвижением, рекламой преимуществ и перспектив на других форумах (в основном ERP). Но к большому моему сожалению не имею возможности глубоко сам её осваивать и применять её на практике, т.к. занимаюсь поддержкой у десятков фирм свой тиражной учётной системы. При этом вынужден учитывать привычки, стандартные приемы (мои и чужие) работы и кучу других нюансов слабо связанных с процессом программирования. В частности даже для "стартовой" установки УС Land в десятки магазинов был вынужден перенастроить около 30 компьютеров и "обучить" около 70 пользователей в разных районах довольно крупного города, а как уже заметил - это мизер клиентской базы. Учитывая, что каждая фирма за поддержку платит "копейки", а новая, современная, перспективная система разработки им "по барабану" - это превращается в довольно геморройное дело. Но процесс движется вперёд, пусть не так быстро, как хочется. Но движется! По поводу LetoDb, MiniGui, новых механизмов интерфейса и работы с БД. Поддержка абсолютно разных по исходному коду систем КИС Lack (Clipper) и УС land (хHarbour) выкинет меня вообще из IT бизнеса... Так, что в начале ВСЕ пользователи перейдут на УС Land (ещё кучка программ, которые нужно переписать/написать), а только затем начнуться работы по переводу системы на новый интерфейс и техники работы с БД! Даже просто, с целью "общего развития" пока мало времени на изучение и тестирование данных механизмов... Это в частности объясняет несколько агресивный стиль общения на форуме... Теперь надеюсь на "спад" нагрузки в ноябре-январе, может и продвинусь в освоении xHarbour чуть дальше.

Pasha: AndreyZh пишет: Поддержка абсолютно разных по исходному коду систем КИС Lack (Clipper) и УС land (хHarbour) Что касается minigui - да, текстовый и графический интерфейс очень уж отличаются, так что скорее всего исходный код прийдется разделить. Хотя мне в свое время удалось сделать программы для tui и gui, не разделяя исходного кода. Правда, бинарники при это различные А что касается БД - то тут сомнений не должно быть ! Сырцы должны быть одни и те же. Да и исполняемые модули тоже. А используемый rdd надо указывать в настройке. Линковать все возможные rdd, и ставить при старте программы нужный rddSetDefault(...) У меня так и делается - в файле ini задаю значения параметров: RDD=LETO Server=//192.168.1.20:2812/database или RDD=DBFCDX Server=m:\database или Server=\\192.168.1.20\database или Server=\\server\database или тоже самое для ads Иногда даже приходилось совмещать в одной сети доступ к БД и через leto, и через dbfcdx Конечно, при использовании leto/ads некоторые таблицы, находящиеся на локальных дисках, надо открывать через dbfcdcx/dbfntx А при использовании leto желательно не использовать пути в set path/set default, поскольку они существенны для некоторых файловых операций, например File().



полная версия страницы