Форум » 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 на Харборе, ... и вообще все в наших руках :). Кто хочет участвовать в разработке, тестировании - пишите.
PSP: Скажите, пожалуйста, как это работает в LetoDB? 1. DBAppend( .F. ) и DBAppend() 2. DBRLock( xRec ) и DBRLock() Имеется в виду, работает ли сохранение существующих блокирововк при вызовах DBAppend( .F. ) и DBRLock( xRec )?
PSP: И еще. Когда Share_Tables = 1, Leto_CommitTransaction() иногда (пока не понял закономерности), вываливатеся по ошибке: "Ошибка LETO/19727357 Ошибка типа данных: -101" Тот же самый код при Share_Tables = 0 работает нормально.
alx_on: PSP пишет: Имеется в виду, работает ли сохранение существующих блокирововк при вызовах DBAppend( .F. ) и DBRLock( xRec )? Должно! (по крайней мере, работало в ноябре 2009)
PSP: Т.е. в этом плане "все соответствует стандартам"? :) Значит показалось... :) Проверю еще раз. Спасибо.
spair2k: подскажите пожалуйста... я пытаюсь собрать сервер на Линхе (Ubuntu 8.04 LTS, xHaroubr 1.20 из DEB пакет взят с сервера xharbour.org) и у меня возникли проблемки. естественно пришлось переписать make_linux.sh под себя, поскольку описание путей для запуска харбора несколько отличается (спасибо сборщикам пакета). не это беда. вот что пишется в лог a2.log source/client/leto1.c: В функции ‘leto_CreateKeyExpr’ source/client/leto1.c:853: предупреждение: pointer targets in passing argument 2 of ‘(pArea)->lprfsHost->compile’ differ in signedness source/client/leto1.c: В функции ‘letoOpenConnection’ source/client/leto1.c:2395: предупреждение: pointer targets in passing argument 1 of ‘letoRemoveIpFromPath’ differ in signedness source/client/leto1.c:2422: предупреждение: pointer targets in passing argument 1 of ‘leto_getIpFromPath’ differ in signedness source/client/leto1.c:2427: предупреждение: pointer targets in passing argument 1 of ‘strrchr’ differ in signedness source/client/leto1.c:2429: предупреждение: pointer targets in passing argument 1 of ‘strrchr’ differ in signedness source/client/leto1.c: В функции ‘letoCreate’ source/client/leto1.c:2496: предупреждение: pointer targets in passing argument 1 of ‘leto_getFileFromPath’ differ in signedness source/client/leto1.c: В функции ‘letoOpen’ source/client/leto1.c:2672: предупреждение: pointer targets in passing argument 1 of ‘leto_getFileFromPath’ differ in signedness source/client/leto1.c:2678: предупреждение: pointer targets in assignment differ in signedness source/client/leto1.c:2691: предупреждение: pointer targets in passing argument 1 of ‘leto_getFileFromPath’ differ in signedness source/client/leto1.c:2750: предупреждение: pointer targets in assignment differ in signedness source/client/leto1.c: В функции ‘letoOrderCreate’ source/client/leto1.c:3235: предупреждение: passing argument 2 of ‘(pArea)->lprfsHost->compile’ discards qualifiers from pointer target type source/client/leto1.c:3256: предупреждение: pointer targets in passing argument 1 of ‘letoRemoveIpFromPath’ differ in signedness source/client/leto1.c:3260: предупреждение: несоответствие указательных типов в условном выражении source/client/leto1.c: На верхнем уровне: source/client/leto1.c:4038: ошибка: ‘DBENTRYP_SCP’ undeclared here (not in a function) source/client/leto1.c:4053: ошибка: ‘DBENTRYP_CP’ undeclared here (not in a function) source/client/leto1.c:4055: ошибка: ‘DBENTRYP_VO’ undeclared here (not in a function) source/client/leto1.c:4055: ошибка: expected ‘}’ before ‘letoCreate’ make: *** [obj/linux/leto1.o] Ошибка 1 лезть в исходники я не спец в СИ. посоветуйте, что делать?
alkresin: spair2k пишет: я пытаюсь собрать сервер на Линхе (Ubuntu 8.04 LTS, xHaroubr 1.20 из DEB пакет взят с сервера xharbour.org) и у меня возникли проблемки. Это связано с вашей версией xHarbour. Для Harbour сейчас есть средства автоопределения версии и я стараюсь их использовать, есть ли что-то аналогичное для xHarbour - не знаю. Поэтому просто откройте include/funcleto.h и раскомментируйте строку 85: #define __OLDRDD__
spair2k: alkresin пишет: #define __OLDRDD__ Сделал, попытался собрать, выдало следующее: source/server/server.prg(105) Error E0025 Error in #if expression
alkresin: source/server/server.prg(105) Error E0025 Error in #if expression А на строке 105 у вас "#if ( (HB_VER_SVNID - 0) > 11796 )" ? Если так, похоже что эта версия xHarbour не понимает такие выражения. Тогда просто закомментируйте эту и последующие 2 строчки, вплоть до #endif - все равно они не для xHarbour.
PSP: А можно попросить сделать функцию, которая бы возвращала клиенту системную дату и время компьютера (можно типа DateTime), на котором запущен сервер?
PSP: Как должна работать функция LETO_MILLISEC() ? Понятно, что подсчет миллисекунд... И, судя по исходникам, подсчет с начала года. Но у меня возвращает отрицательное число (сейчас что-то типа "-1652863174"). Причем, если вызывать в цикле, число увеличивается (т.е. стремится к нулю). Такое впечатление, что есть ошибка с типом числовой переменной и происходит отрицательное переполнение.
Pasha: Эта функция возвращает колличество миллисекунд "от царя панька", т.е. от условной даты, от которой считаются юлианские дни, до текущего момента. Получается: в сутках 86400000 миллисекунд, сейчас примерно 2500000-й юлианский день, вот результат и вылазит за пределы 32-битного целого Можно использовать, конечно, 64-битное целое, только я не возьму в толк, зачем такая функция нужна ?
PSP: Pasha пишет: Эта функция возвращает колличество миллисекунд "от царя панька", т.е. от условной даты, от которой считаются юлианские дни, до текущего момента. Да, да, да... точно. Там же в исходниках, в коде под Линукс, явно это видно. зачем такая функция нужна ? Мне нужна не имеено эта функция. Мне нужно брать дату и время (точнее, уникальный временной отпечаток, TimeStamp) для всех клиентов из одного источника (чтобы соблюдалась четкая временная последовательность операций). Мне не приходит в голову ничего лучшего, чем компьютер, где запущен сервер LetoDB. Как оттуда взять время? Вот я и стал рыться, искать. Нашел LETO_MILLISEC(). Паш, а можно ее подправить или сделать другую, которая возвратит переменную типа DateTime (yyyymmddhhmmssccc), а? Заранее спасибо.
Pasha: Понятно Но LETO_MILLISEC() выпоняется локально, так что нужное время она не вернет Функция leto_MgGetInfo() возвращает информацию с сервера, и 5-й элемент массива-результата - как раз время, прошедшее с момента запуска сервера. Это подойдет ?
PSP: Pasha пишет: Это подойдет ? Если сервер перезагрузить, отсчет пойдет сначала? Если да, то не подходит. Вполне подошло бы системное время... :) Может можно в Leto_MgGetInfo() еще один эдемент добавить? Извините за навязчивость... Спасибо.
Pasha: Может быть есть другой вариант, получать время сервера по протоколу NTP, подскажите, кто знает, как это сделать Если это делать средствами letodb (c точностю до миллисекунд), то это делается так: source\server\letofunc.c, строка 3736: sprintf( s,"+%d;%d;%d;%d;%lu;%lu;%lu;%lu;%u;%u;%s;%7.3f;%7.3f;%lu;%lu;%lu;%9.3f;", uiUsersCurr,uiUsersMax,uiTablesCurr,uiTablesMax, (leto_Date()-lStartDate)*86400+(long)(dCurrent-dStartsec), ulOperations,ulBytesSent,ulBytesRead,uiIndexCurr,uiIndexMax, (pDataPath ? pDataPath : ""),dMaxDayWait,(ulWait)? dWait/ulWait : 0, ulTransAll,ulTransOK, leto_Date(), dCurrent ); source\client\letomgmn.c, со строки 289: aInfo = hb_itemArrayNew( 17 ); for( i=1; i<=17; i++ ) 16-й и 17-й элемент массива будут соответственно дата (Long) и время: целая часть - секунды, дробная часть - миллисекунды после полуночи Если Александр не против, можно это сбросить на CVS
PSP: Паш, огромное спасибо! :) Выручил.
PSP: Pasha пишет: Если Александр не против, можно это сбросить на CVS Александр, Вы же не против? Имхо, пригодится.
PSP: Народ, я еще вас помучаю слегка, ок? Речь о блокировках при работе с транзакциями. Если при активной транзакции снять блокировку(ки), то она(и) успешно снимаются, не дожидаясь выполнения Leto_CommitTransaction(). Соответственно, когда наступает очередь Leto_CommitTransaction(), прога вываливается по ошибке из-за попытки писать в незаблокированную запись. Это фича или баг? По идее-то все действия, производимые с базой после Leto_BeginTransaction(), должны делаться в Leto_CommitTransaction() или я не прав?
PSP: PSP пишет: Речь о блокировках при работе с транзакциями. Если при активной транзакции снять блокировку(ки), то она(и) успешно снимаются, не дожидаясь выполнения Leto_CommitTransaction(). Соответственно, когда наступает очередь Leto_CommitTransaction(), прога вываливается по ошибке из-за попытки писать в незаблокированную запись. Это фича или баг? По идее-то все действия, производимые с базой после Leto_BeginTransaction(), должны делаться в Leto_CommitTransaction() или я не прав? Неужто никто не расскажет?
Pasha: Транзакции делал Александр. Попробуйте написать ему напрямую
полная версия страницы