Форум » LetoDB, HbNetio. » Leto DB Server (продолжение) » Ответить
Leto DB Server (продолжение)
alkresin: Только что открыл на Sourceforge новый проект - Leto DB Server - https://sourceforge.net/projects/letodb Это мультиплатформенный ( Windows, Unix/Linux ) сервер баз данных, предоставляющий клиентским программам доступ к dbf/cdx файлам, находящимся на удаленном сервере ( можно и на локальном компьютере запускать - в отладочных целях ). В общем, как ADS :). Проект - на стадии разработки, не все даже базовые функции еще реализованы, до оптимизации дело еще не дошло. Но работает :). Крутится у меня на сервере несколько дней, подключал до 15 клиентов, пока не падает. Мои программы работают с ним нормально. Преимущества по сравнению с обычным файл-сервером: 1) Безопасность - базы могут быть в каталоге, недоступном для клиентских компьютеров - никто их случайно не удалит и не повредит. 2) Поскольку базы открываются серверной программой, а не клиентской, ее целостности ничего не грозит при случайном отключении клиентского компьютера. 3) значительное уменьшение сетевого траффика. 4) Должен быть, по идее, выигрыш в скорости. 5) Возможность контроля за пользователями с помощью утилиты manage ( можно придумать и другие формы контроля ). 6) Можно будет сделать транзакции, stored procedures на Харборе, ... и вообще все в наших руках :). Кто хочет участвовать в разработке, тестировании - пишите.
alx_on: alkresin пишет: Я не ставлю никаких своих дополнительных ключей, что есть в стандартных файлах конфигурации, то и использую В смысле просто make?
alkresin: alx_on пишет: В смысле просто make? В той версии, которой я пользуюсь, еще есть make_b32.bat и make_b32.mak, там еще не используется gnu make :)
alkresin: Это для Windows. А для Линукс - да, просто make, и перед ним устанавливаю несколько переменных окружения: export HB_ARCHITECTURE=linux export HB_COMPILER=gcc export HB_GT_LIB=gtcrs
alkresin: Посмотрел внимательнее hs_openindex, там вроде бы все в порядке, ничего не переоткрывается, ничего не переинициализируется.
alkresin: Павел, что-то после ваших сегодняшних изменений "for compatibility with older xHarbour versions" у меня перестало компилироваться: source\server\server.prg(110) Error F0029 Can't open #include file: 'hbextcdp.ch' ... Error: Unresolved external '_hb_GetSetStructPtr' referenced from C:\MYAPPS\LETODB\OBJ\B32\LETOFUNC.OBJ
Pasha: Я проверял сборку для Harbour с SVN, поэтому получилась такая неувязка. с _hb_GetSetStructPtr понятно, я сейчас поправлю. У меня Harbour 1.х нет, но суть ясна. А с source\server\server.prg(110) какие-то чудеса, а поскольку чудес не существует, видимо баг в препроцессоре Я собирал letodb с xharbour 1.01, и на строке 105, в ветке для Harbour, которую xHarbour не должен компилировать: #if ( (HB_VER_SVNID - 0) > 11796 ) получил ошибку на #if я заменил конструкцию: #if defined(HB_VER_SVNID) #if ( (HB_VER_SVNID - 0) > 11796 ) #define __HB_EXT_CDP__ #endif #endif на идентичную: #if defined(HB_VER_SVNID) && ( (HB_VER_SVNID - 0) > 11796 ) #define __HB_EXT_CDP__ #endif ошибка в xharbour исчезла, но появилась непонятная ошибка в Harbour Я конечно верну все назад, но фокусы с препроцессором непонятны
alx_on: alkresin пишет: Посмотрел внимательнее hs_openindex, там вроде бы все в порядке Я вставил отладочные сообщения - hs_openindex каждый раз отрабатывает, т.е. OrdListAdd( cBagName ) OrdSetFocus( OrdCount() ) хотя таблица с таким индексным файлом уже открыта и используется
alkresin: Pasha пишет: А с source\server\server.prg(110) какие-то чудеса, а поскольку чудес не существует, видимо баг в препроцессоре Да, по-видимому, в тех версиях такие конструкции вызывают ошибки. Я уже сталкивался с этим.
alkresin: alx_on пишет: Я вставил отладочные сообщения - hs_openindex каждый раз отрабатывает, т.е. OrdListAdd( cBagName ) OrdSetFocus( OrdCount() ) хотя таблица с таким индексным файлом уже открыта и используется Да, отрабатывает. Но если вы посмотрите на реализацию OrdListAdd() d dbfcdx и dbfntx ( я вчера посмотрел :) ), то увидите, что там проверяется, открыт ли уже этот индекс, и, если открыт, не делается ничего.
alx_on: Нашел интересную зависимость под win Если стоит "microsoft visual C++ 2008 Redistributable - x86 9.0.21022" то лето падает (как мной описано постами выше) если удалить (стандартно), то не падает (конечно, может и неверно лето работает, например, ошибки по памяти остаются, но молча пропускаются )
alkresin: alx_on пишет: Если стоит "microsoft visual C++ 2008 Redistributable - x86 9.0.21022" то лето падает (как мной описано постами выше) если удалить (стандартно), то не падает Интересно... А каким С компилятором у вас letodb скомпилирован ? MSVS ? Если да, то той же версии, что и Redistributable ?
alx_on: alkresin пишет: С компилятором у вас letodb скомпилирован ? MinGW Но суть не в этом. Я нашел проблему! По крайней мере одну из... :) При передаче значений полей возникает путаница, если кол-во полей в таблице > 255 Там такой бардак начинается, что диву даешься как это все работало Попытаюсь сегодня выложить предварительные исправления PS Александр, вопрос: в старом harbour и xHarbour есть функции (правильно! работающие под разные ОС) hb_osPathSeparator() hb_osDriveSeparator() hb_osNewLine()
alkresin: alx_on пишет: PS Александр, вопрос: в старом harbour и xHarbour есть функции (правильно! работающие под разные ОС) hb_osPathSeparator() hb_osDriveSeparator() hb_osNewLine() Функции есть, ну а правильно они работают или нет - не проверял. Наверное, правильно :).
alx_on: alkresin пишет: Функции есть Предлагаю их использовать вместо прямых указаний "/", "\" и перевода строк все пути в коде сервера переводить на нативный вариант текущей оси сервера (путаница возникает при использовании на клиентских местах разных ОС)
alkresin: Предлагаю их использовать вместо прямых указаний "/", "\" и перевода строк Не возражаю. А перевод строк где нам нужен ? все пути в коде сервера переводить на нативный вариант текущей оси сервера Так они переводятся, только с использованием напрямую "/", "\"
alx_on: alkresin пишет: А перевод строк где нам нужен В логах, например Так они переводятся, Не везде Вопрос: для чего в letoOrderCreate() после успешного создания индекса нужно делать SELF_GOTOP()? Во первых это лишний вызов (у меня в CDX-файле штук 10 ордеров и 10 gotop соответственно мне не нужны, после создания последнего может и надо, и то не в моем случае) Столкнулся со странной ситуацией - на ОДИН файл не может создать индекс (причем, подобные файлы с такой же структурой - ок) именно "return SELF_GOTOP( ( AREAP ) pArea )" возвращает ошибку! upd! Ошибся! Сделал SELF_GOTOP( ( AREAP ) pArea ); return SUCCESS; - тоже самое Ничего не понимаю
alkresin: Вопрос: для чего в letoOrderCreate() после успешного создания индекса нужно делать SELF_GOTOP()? Потому что так ведет себя эта функция во всех RDD. именно "return SELF_GOTOP( ( AREAP ) pArea )" возвращает ошибку! Ошибку - в смысле run-time error с соответствующими gencode, subcode ? Если так, то что дает return SUCCESS, если эта runtime error уже произошла во время исполнения SELF_GOTOP ...
alx_on: alkresin пишет: во время исполнения SELF_GOTOP В чем может быть проблема? в функциях letoGoTop() в leto1.c leto_Goto() в letofunc.c ошибки не возникают...
alkresin: В чем может быть проблема? в функциях letoGoTop() в leto1.c leto_Goto() в letofunc.c ошибки не возникают... Как я понял, эта ошибка происходит у вас при создании одного определенного индекса - т.е. сразу после его создания программа вываливается, так ? Значит, letoGoTop() для этого индекса не вызываются, или я не так понял ? А вот почему именно этот индекс вызывает ошибку надо смотреть. Создался он на сервере или нет, нормальный ли он ( открывается ли с dbfcdx ), какую именно ошибку вернул сервер. Мне, чтобы предметно об этом говорить, нужен самодостаточный пример, чтоб я мог его воспроизвести.
alx_on: alkresin пишет: сразу после его создания программа вываливается, так ? да Значит, letoGoTop() для этого индекса не вызываются только что еще раз проверил - вызывается Создался он на сервере или нет, нормальный ли он ( открывается ли с dbfcdx ) да и да самодостаточный пример попытаюсь сделать PS пока баловался - сделал нечаянно тот же самый индекс с параметром DESCENDING - прошло без ошибок
полная версия страницы