Форум » Для флейма » Помогите протестировать первую 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
Петр: 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() хммм... А что не так ?
полная версия страницы