Форум » 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 на Харборе, ... и вообще все в наших руках :). Кто хочет участвовать в разработке, тестировании - пишите.
alkresin: Догадываюсь, в чем там дело. Попробуйте поменять в line 665: pUStru->uiAreasAlloc = 20; 20 на что-нибудь побольше - 40, например.
Pasha: сейчас попробую Простой тест: Local cPath := '//127.0.0.1:2812/' use (cPath+'table1') new use (cPath+'table2') new ... use (cPath+'table25') new стабильно приводит к gpf на сервере на 25-м use при сборке под xHarbour При сборке под Harbour gpf нет Но при попытке открытия (use) несуществующей таблицы gpf на сервере происходит как для xHarbour, так и для Harbour По поводу udf-функций. Пересборка сервера с нужными функциями для некоторых может вызвать затруднения. Да и добавление новых функций приведет к необходимости пересобрать сервер, что нежелательно Может быть, сделать dll для udf-функций, которую бы сервер загружал, и предоставить программисту добавлять свои функции в эту dll и пересобирать ее ? Хотя, как-то надо указывать codepages, которые должен использовать сервер, то есть без пересборки не обойтись
Pasha: Да, теперь все работает
Pasha: Смотрю вопросы в Open discussion Наверное, надо заменить: IF !oApp:lAnyExt .AND. !Empty( cBagName ) .AND. Len( cTemp := GetExten( cBagName ) < 3 ) .AND. !( cTemp $ "cdx;idx;ntx" ) на IF !oApp:lAnyExt .AND. !Empty( cBagName ) .AND. Len( cTemp := GetExten( cBagName ) ) < 3 .AND. !( cTemp $ "cdx;idx;ntx" ) ?
Andrey: Когда можно будет приступить к тестированию СЕРВЕРА БД под свои рабочие базы ? Я писал об БОЛЬШОЙ проблеме открытия баз с большим количеством полей !!! Если надо образцы баз на которых не работает сервер leto DB , могу выслать.
alkresin: Pasha пишет: Наверное, надо заменить: IF !oApp:lAnyExt .AND. !Empty( cBagName ) .AND. Len( cTemp := GetExten( cBagName ) < 3 ) .AND. !( cTemp $ "cdx;idx;ntx" ) Точно. Сейчас заменю.
alkresin: Andrey пишет: Я писал об БОЛЬШОЙ проблеме открытия баз с большим количеством полей !!! Я все исправил, теперь должно работать нормально. Думаю выложить build3 сегодня-завтра.
spair2k: в посте говорилось о том, что главная идея этого проекта в легкости переноса существующего кода на другую платформу "добавив 3 строчки кода". попробовал, начал с создания индексов, получилось, но заметил одну вещь - не создаются индексы в которых есть FOR, т.е. в самом индексе TAG прописан, но он пустой. это только у меня проблема?
Pasha: spair2k пишет: но заметил одну вещь - не создаются индексы в которых есть FOR, т.е. в самом индексе TAG прописан, но он пустой. Это на build2 или на свежих сырцах ? Пару недель назад я добавлял OrdCondSet(), должно работать Команду, которой создается индекс, в студию
alkresin: Выложил build3
gfilatov: alkresin пишет: Выложил build3 Выложил готовую к использованию полную сборку LetoDB build 0.3 по адресу: http://minigui.mylivepage.ru/file/16/4742_letodb-bin-w32-bcc-5-5.zip.zip
Pasha: Александр, все-таки более 20-ти таблиц не открываются, на сервере происходит gpf Надо увеличить в letofunc.c параметр pUStru->uiAreasAlloc ? И еще возник глючек. После dbAppend() Field->F1 := value ... dbCommit() dbUnlock() на последней команде клиент зависает, по-видимому безуспешно ждет ответ от сервера
alkresin: Александр, все-таки более 20-ти таблиц не открываются, на сервере происходит gpf Надо увеличить в letofunc.c параметр pUStru->uiAreasAlloc ? Это просто отодвинет барьер после которого происходит gpf. Надо разобраться, в чем дело.
Pasha: Смотрю, как бы получше сделать relations Надо и на клиенте, и на сервере хранить установленные relations в каждой РО Затем, на сервере в leto_rec их отрабатывать, и передавать на клиент данные не только текущей РО, но и всех РО, указанных в relations На клиенте их принимать, и соответственно отрабатывать в leto_ParseRec Только при этом надо учесть отложенные commit в связанных РО: проверять не только pArea->uiUpdated, но и изменения в связанных РО Такая схема подойдет ?
alkresin: Александр, все-таки более 20-ти таблиц не открываются, на сервере происходит gpf Теперь окончательно исправил.
Pasha: Теперь БД открывается без проблем
alkresin: Смотрю, как бы получше сделать relations Надо и на клиенте, и на сервере хранить установленные relations в каждой РО Затем, на сервере в leto_rec их отрабатывать, и передавать на клиент данные не только текущей РО, но и всех РО, указанных в relations... Чем больше думаю об этом, тем труднее представляю, как это можно сделать корректным путем. RDD методы имеют дело с одной текущей workarea, которая передается им в качестве параметра, а при таком подходе каждый метод, связанный с перемещением по базе, будет получать и должен обрабатывать данные для разных workareas - сделать-то можно, но это нарушает всю логику работы RDD. Не думаю, что это хорошо.
alkresin: Создал developers mail list, подписка на https://lists.sourceforge.net/lists/listinfo/letodb-developers
Pasha: Буду делать аккуратно Постараюсь, чтобы методы workarea не выходили за пределы своих полномочий Все равно, эффективнее было бы получать посылку от сервера о состоянии всех связанных РО одним пакетом. Да по-другому, наверное, нельзя
alkresin: Выложил build4, т.к. были важные исправления
полная версия страницы