Форум » 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 на Харборе, ... и вообще все в наших руках :). Кто хочет участвовать в разработке, тестировании - пишите.

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

alkresin: alx_on пишет: Простой фильтр - клиент сам проверяет выражение фильтра на каждой записи Оптимизированный - фильтр ставится на сервере А, ну да, точно ... Просто есть какие-то еще оптимизированные фильтры в некоторых RDD - я подумал, что вы о них. 1. (1) клиент вызвал FLock() 2. (2) клиент сделал dbappend() (успешно, ему ничего не помешало, на сервер ничего не ушло, запись НЕ заблокировалась, ошибки не произошло) теперь оба клиента уверены, что у них все хорошо Не уверены. При реальном добавлении записи на сервере произойдет ошибка, клиенту будет послан соответствующий ответ и его программа ( если не стоит BEGIN SEQUENCE ... ) аварийно завершится. Но, конечно, проверка на NetErr() лучше, чем аварийное завершение. Я считаю, что если необходимы быстрые dbappend (не используется FLock) - можно сделать некую настройку (при компиляции или в рантайме) Согласен. Именно в runtime - какую-нибудь SetAppendMode(). Но чтоб прежний вариант ( быстрый ) стоял по умолчанию :) Существуют и другие ошибки при добавлении записи (например, место на диске кончилось, сеть тоже кончилась:) и т.д.) А вот при такого рода проблемах аварийное завершение, которое произойдет сразу после попытки записать добавленную запись на сервер, - это нормально.

alkresin: Pasha пишет: т.е., для letodb neterr() должен посылать запрос на сервер на предмет блокировок. В этом случае все равно получится 2 запроса при dbAppend: на neterr и commit. Но, если пользователь уверен, что FLock() не используется, он может не выдавать NetErr() Нет, пусть уж лучше dbAppend() посылается сразу на сервер и получает ответ, на основе которого можно выставить флаг для NetErr(). Но только при SetAppendMode( .t. )

alx_on: alkresin пишет: Не уверены. При реальном добавлении записи на сервере произойдет ошибка, клиенту будет послан соответствующий ответ и его программа ( если не стоит BEGIN SEQUENCE ... ) аварийно завершится. Это в случае, если не успели снять flock :) Но только при SetAppendMode( .t. ) Годится PS можете меня включить в список доступа на обновление letodb? :)


alkresin: Это в случае, если не успели снять flock :) А если успели, то запись успешно добавится. PS можете меня включить в список доступа на обновление letodb? Какой у вас логин на Sourceforge ?

alkresin: Pasha, а зачем вы в manage.prg изменили путь к rddleto.ch ? Оно ж так компилироваться не будет ...

alx_on: alkresin пишет: Какой у вас логин на Sourceforge ? aokhotnikov

Pasha: alkresin пишет: а зачем вы в manage.prg изменили путь к rddleto.ch ? Оно ж так компилироваться не будет ... Мне прислали это изменение Przemek'a для сборки с текущим Harbour SVN. Наверное, он собирал с помощью hbmk2. Если собирать через bld.bat, то действительно не скомпилируется

alkresin: alx_on пишет: aokhotnikov Добавлен.

alx_on: alkresin пишет: Добавлен спасибо

PSP: Чё-та у меня DBOrderInfo( DBOI_NUMBER, , cOrdName ) кажись косячит при работе с RDDLETO. Если указать в cOrdName существующее имя ордера, она возвращает его номер в списке ордеров правильно. Если же в cOrdName указать несуществующий ордер, функция возвращает число, равное количеству ордеров в файле. С OrdNumber() та же песня. А вот с RDDCDX при несуществующем cOrdName, обе функции возвращают 0. Как быть? Если можно, проверьте, плизззз...

Pasha: PSP пишет: Как быть? Если можно, проверьте, плизззз... В source\client\leto1.c вместо case DBOI_NUMBER: { hb_itemPutNI( pOrderInfo->itmResult, uiTag ); break; } надо поставить case DBOI_NUMBER: { hb_itemPutNI( pOrderInfo->itmResult, (pTagInfo) ? uiTag : 0 ); break; } я поправлю на cvs

PSP: Паша, большое спасибо! It works!

PSP: alx_on пишет: DbRLockList - не работает (в принципе, не сильно важно) Скажите, а нельзя ли сделать, чтобы заработало? Понадобилась... :)

alx_on: PSP пишет: Скажите, а нельзя ли сделать, чтобы заработало? Сделать можно все! :) А оно надо? Пример: заблокировано 10000 записей (обычная ситуация :) ) берем локи а) с клиента (хорошо, но переделка клиента и двойная работа по учету блокировок) б) с сервера (плохо, по сети минимум 50Кб на каждый вызов, вроде немного, но разом. а клиент то не один) Проще у себя сохранять в массиве (или не использовать совсем, а переделать логику программы)

PSP: alx_on пишет: Проще у себя сохранять в массиве Уже так и сделал. Хотел красивее... :) Спасибо за ответ.

PSP: Ошибка при сборке Letodb с последними Harbour nightly-sources bcc32 -c -Iinclude;J:\Job\MiniGUI\Harbour\include -d -tWM -D__WIN32__ -D__WIN_DAEMON__ -w-8075 -oobj\b32\errint.obj source\server\errint.c Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland source\server\errint.c: Error E2356 source\server\errint.c 66: Type mismatch in redeclaration of 'hb_errInternalRaw' Error E2344 J:\Job\MiniGUI\Harbour\include\hbapierr.h 171: Earlier declaration of 'hb_errInternalRaw' Error E2356 source\server\errint.c 96: Type mismatch in redeclaration of 'hb_errInternal' Error E2344 J:\Job\MiniGUI\Harbour\include\hbapierr.h 170: Earlier declaration of 'hb_errInternal' *** 4 errors in Compile ***

Pasha: Ошибка при сборке связана с этим изменением в Harbour: 2009-11-16 17:35 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbapierr.h * harbour/src/rtl/errint.c * harbour/src/rtl/errintlo.c ... * changed ULONG ulIntCode to HB_ERRCODE errCode in internal errors опять в разных версиях харборов определения одних и тех же функций разнятся :(

PSP: Наверное, лучше подождать выхода стабильной сборки Harbour. Петр говорил, что до Нового года может появиться...

Pasha: Ну это изменение назад все равно не вернут, так что приводить в соответствие letodb все равно надо Сделать это просто: в server\errint.c надо заменить определение ULONG ulIntCode на HB_ERRCODE ulIntCode Только как сделать, чтобы сохранить сборку и с предыдущими версиями, да и с xHarbour, надо подумать

PSP: Pasha пишет: Ну это изменение назад все равно не вернут Нееее, я не жду, что вернут... :) Я о том, что стоит подождать, пока сделают все изменения.



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