Форум » 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 на Харборе, ... и вообще все в наших руках :). Кто хочет участвовать в разработке, тестировании - пишите.
Pasha: Pasha пишет: Оптимизация вызовов dbCommit() dbUnlock() Надо все-таки реализовать на клиенте pLocksPos, тем более это все равно нужно. Тогда при вызове flush (если установлен флажок) можно будет делать сразу unlock. А при unlock проверять на клиенте pLocksPos, и, если он пуст, ничего не делать В результате мы получим один пакет при обновлении данных вместо трех
Pasha: Я смотрю, в leto_PutRec после if( bTransActive ) нет вызова free( szData ); наверное, он нужен
alkresin: нет вызова free( szData ); наверное, он нужен Да.
alkresin: Надо все-таки реализовать на клиенте pLocksPos, тем более это все равно нужно. Тогда при вызове flush (если установлен флажок) можно будет делать сразу unlock. А при unlock проверять на клиенте pLocksPos, и, если он пуст, ничего не делать Это хорошо, если программист пишет строго "как в книжке рекомендовано". А если он почему-то после commit опять начнет корректировать данные ?
Pasha: alkresin пишет: Это хорошо, если программист пишет строго "как в книжке рекомендовано". А если он почему-то после commit опять начнет корректировать данные ? Так инструмент дается тому, кто понимает, зачем он нужен и как его использовать. А если не понимает - проблемы индейцев шерифу безразличны. Кто не понимает, тот пусть не устанавливает этот флажок. Пусть это будет функция вида: Leto_UnlockOptimize( lOn/lOff ) и использование будет рекомендовано так: Leto_UnlockOptimize( .t. ) dbCommit() dbUnlock() Leto_UnlockOptimize( .f. )
alkresin: и использование будет рекомендовано так: Leto_UnlockOptimize( .t. ) dbCommit() dbUnlock() Leto_UnlockOptimize( .f. ) Тогда уж лучше какая-нибудь leto_Unlock() вместо этих четырех строк.
Andrey: А как по коду можно определить какой драйвер используется ? Т.е. LetoDB() или стандартный CDX ? Хочется иметь в одной задаче ОДНОВРЕМЕННО ДВА драйвера !!! Т.е. иметь локальный вариант и файл-серверный и LetoDB-драйвер. Соответственно в коде нужно будет тогда делать условия обработки: 1) для CDX 2) для LetoDB
Pasha: Andrey пишет: Хочется иметь в одной задаче ОДНОВРЕМЕННО ДВА драйвера !!! Да хоть 10 драйверов можно подключать. В dbUseArea 2-й параметр - это используемый rdd. Можно указаль LETO, или DBFCDX, или что угодно. Параметр есть и в dbCreate А проверка, какой драйвер используется в рабочей области - вызов RddName()
Pasha: Есть таблица размером 62М, 620 тыс. записей Создается тэг, в нем 3 индекса. Если запущен letodbtray, который здесь дал SashaBG, то при создании индекса может возникать ошибка: Create error (1-1081): 1081 - это argument error + Если не запущен letodbtray, то ошибка не возникает. letodbtray с интервалом в 1 сек вызывает leto_connect для проверки, жив ли сервер. Время индексации - примерно 10 сек. Я в лог добавляю аргументы при ошибке и вижу: 24.06.10 09:44:21: Create error (1-1081): Arguments: ( [ 1] = Type: C Val: 08232078, [ 2] = Type: N Val: 0)carecs.CDX индексное выражение для 1-го индекса такое: Stock+Code+DTOS(Date)+NDT 1-й аргумент "08232078" - это как раз Stock+Code. 2-й аргумент - это результат DTOS(), который нулем буть никак не может, но тем не менее... Т.е., вызов leto_connect() каким-то образом прерывает индексацию Сервер при этом не падает. PS Ошибка при LTrim - похоже из этой же серии, когда аргумент не может быть числовым, но тем не менее им оказывается.
Pasha: Т.е., вызов leto_connect() с другого клиента портит стек харбора
Pasha: Сервер был собран с xHarbour С Harbour ошибка возникает намного реже, но все равно возникает. С Harbour индексация выполняется немного быстрее, так что коллизия возникает реже
Pasha: Я использую xHarbour с кодовой страницей RU1251 Сейчас она называется RUWIN Если использовать клиенты xHb с сервером letodb, собранным с Harbour, то где-то надо транслировать имя кодовой страницы Подскажите красивое решение, где это лучше сделать.
Pasha: Pasha пишет: Т.е., вызов leto_connect() с другого клиента портит стек харбора Может быть, дело в вызове hb_retni() в функции hb_ipclose() ? Он там не нужен, его можно перенести в HB_FUNC( HB_IPCLOSE )
Pasha: Да, дело именно в этом, лечение помогло, теперь полет нормальный Надо еще пересмотреть остальные hb_ret* в этом модуле Может, и проблема alx_on в этом состояла
alkresin: Да, дело именно в этом, лечение помогло, теперь полет нормальный Здорово! Нашлась ошибка, которая реально могла доставлять проблемы.
alkresin: Если использовать клиенты xHb с сервером letodb, собранным с Harbour, то где-то надо транслировать имя кодовой страницы По-видимому, надо в строчку с версией, передаваемой клиенту при соединении, включить информацию о том, чем собран сервер ( Harbour/xHarbour ), тогда клиент при необходимости может, в соответствии с хранящейся у него таблицей, подменить название кодовой страницы.
Pasha: Хочется добавить в AREASTRU на сервере клиентский алиас таблицы Это понадобится в дальнейшем для выполнения клиентских процедур на сервере. Можно следать на сервере функцию, которая бы возвращала реальный алиас по клиентскому в окружении текущего пользователя, чтобы затем в процедуре по нему обращаться к таблице Для начала можно сделать хотя бы триггеры, тем более dbfcdx их поддерживает
alkresin: Хочется добавить в AREASTRU на сервере клиентский алиас таблицы Да, надо добавить. Мне даже казалось, что он уже где-то хранится, потому что задумка такая была.
Pasha: Выявил и устранил еще один неприятный глючек Блокируем запись по rlock Затем перемещаемся назад, что-то делаем, в том числе rlock - unlock на другой записи По skip возвращаемся на начальную запись Выдаем RLock. Клиент не перечитывает запись с сервера, поскольку она в есть буфере skip Затем по RLock клиент на сервер запрос не выдает, так считает что запись блокирована, а блокировка уже снята В результате при Commit получаем lock required Надо очищать буфер skip на клиенте при unlock Вопрос. В каких еще случаях это надо делать ?
Pasha: Попутно еще такой вопрос. RLock() блокирует только текущею запись. Если ранее была блокирована другая запись, то такая блокировка должна сниматься. А в leto на сервере в leto_RecLock структура pAStru->pLocksPos не очищается Это правильно ?
полная версия страницы