Отправлено: 31.01.08 11:36. Заголовок: Leto DB Server (продолжение)

Только что открыл на 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 на Харборе, ... и вообще все в наших руках :).

Кто хочет участвовать в разработке, тестировании - пишите.

 Отправлено: 11.06.10 16:58. Заголовок: Привет. у меня такой..

Привет.
у меня такой результат
1 .F. немного поспешил .T.
1 .T.

 Отправлено: 12.06.10 12:31. Заголовок: Pasha пишет: В связ..

Pasha пишет:

цитата:

В связи с этим обьявляется конкурс на иконку для letodb-tray

Первое приближение:

 Отправлено: 12.06.10 14:36. Заголовок: http://jpe.ru/1/max/..

 Отправлено: 12.06.10 22:11. Заголовок: Может сервисом все т..

Может сервисом все таки сделать?
Удобнее во всех отношениях и не надо на сервере логиниться для запуска

 Отправлено: 12.06.10 23:20. Заголовок: alx_on пишет: Может..

alx_on пишет:

цитата:

Может сервисом все таки сделать?

Нет нужен выбор, как у всех продуктов:
1) Приложение (Application)
2) Сервис (Service)

Но я тоже за СЕРВИС, мне его удобней использовать под Виндой !

 Отправлено: 13.06.10 13:51. Заголовок: Pasha пишет: Доклад..

Pasha пишет:

цитата:

Докладываю. Вот в таком случае: ... флажок deleted() возвращается неправильный

Ясно. Такая же история будет, если вы поле какое-то замените, т.е. вместо dbDelete() - table1->Id := 100, а потом ? Recno(), table1->Id .
Дело в том, что запись фактически изменяется только в момент вызова leto_CommitTransaction() и skip, skip -1 во время транзакции приводят к тому, что в буфер записываются необновленные значения.
Надо будет в leto_CommitTransaction() поставить автоочищение буферов.

 Отправлено: 13.06.10 16:48. Заголовок: Надо будет в leto_Co..

цитата:

Надо будет в leto_CommitTransaction() поставить автоочищение буферов.

Не так оно просто ...
Может, лучше не надо во время транзакции возвращаться на измененную во время этой транзакции запись ? Честно говоря, не вижу в этом действии никакого смысла. Повторно что-то в ней изменить ? А почему тогда сразу не сделать необходимые изменения ? Транзакция - это все таки процедура специфическая, она предназначена исключительно для изменения/добавления данных и другие действия в ней не должны иметь места.
Кстати, dbCommit() в транзакции не нужен - он просто не исполняется.

 Отправлено: 13.06.10 17:57. Заголовок: Я вижу 2 выхода: 1)..

Я вижу 2 выхода:

1) простой. После CommitTransaction выдавать запрос на чтение в изменившихся WA, т.е. goto(recno())
Но при этом во время транзакции содержимое записей может быть искаженным, т.е. до изменения, что тоже нежелательно.

2) во время транзакции после получения ответа с сервера в операциях навигации просматривать буфер транзакции, и, если запись, полученная с сервера, есть в буфере, заменять ее значение данными из буфера.

 Отправлено: 13.06.10 18:09. Заголовок: alx_on пишет: Может..

alx_on пишет:

цитата:

Может сервисом все таки сделать?

В Harbour эта возможность появилась всего месяц назад. Кто нибудь тестировал contrib\hbwin\win_svc.c ? Годится для letodb ?

 Отправлено: 13.06.10 20:16. Заголовок: Pasha пишет: Кто ни..

Pasha пишет:

цитата:

Кто нибудь тестировал contrib\hbwin\win_svc.c

Не работает в MT и не только. Т.е. сервис инсталируется/деинсталируется, но не запускается. По крайней мере у меня .
Вот еще любопытная цитата

цитата:

I'm not familiar with services in MS-Windows so I hope that real MS-Windows programmers can verify the text below. MSDN says that StartServiceCtrlDispatcher() makes calling thread service dispatcher which creates new thread to execute the appropriate ServiceMain function when a new service is started. It means that current win_svc.c code cannot work with MT HVM because it does not initialize new HVM stack for newly created thread. It also does not unlock HVM stack used by thread calling StartServiceCtrlDispatcher() what will cause deadlock when some other thread activates GC. It works with ST HVM because thread created for ServiceMain function reuses the HVM stack bound with thread calling StartServiceCtrlDispatcher() taking its address from static variable. It does not work with MT HVM because in MT mode each HVM thread extracts HVM stack pointer from TLS so newly create thread takes NULL as its own stack pointer. If you want to use this code with MT HVM then it has to be adopted to work safely with it. It should create and destroy on exit new HVM stack and encapsulate call to StartServiceCtrlDispatcher() into hb_vmUnlock()/ hb_vmLock(). best regards, Przemek

 Отправлено: 13.06.10 21:28. Заголовок: 1) простой. После Co..

цитата:

1) простой. После CommitTransaction выдавать запрос на чтение в изменившихся WA, т.е. goto(recno())

Не хотелось бы - это приведет к заметному снижению производительности, причем для большинства случаев неоправданному. Я уже думал об этом, надо тогда добавлять флаг в area и определенную логику в leto_getValue() и пр., чтобы перечитывать запись только когда это действительно нужно.

цитата:

) во время транзакции после получения ответа с сервера в операциях навигации просматривать буфер транзакции, и, если запись, полученная с сервера, есть в буфере, заменять ее значение данными из буфера.

В общем случае это невозможно, т.к. записи может и не быть в буфере, поэтому это не может быть решением.
Я все же не вижу ни одной причины, зачем было бы нужно возвращаться к записи во время транзакции ...

 Отправлено: 13.06.10 21:54. Заголовок: alkresin пишет: В о..

alkresin пишет:

цитата:

В общем случае это невозможно, т.к. записи может и не быть в буфере, поэтому это не может быть решением.

Почему невозможно ? В буфере транзакций хранятся только изменившиеся записи. Если прочитанной записи в буфере нет, значит оставляем ее такой, какая она пришла с сервера, а если есть - изменяем. Меня сейчас интересует не сложность реализации, а принципиальная правильность подхода. Да и на быстродействие это повлияет незначительно, так как от сервера ничего получать не надо, надо только выполнить поиск в буфере транзакции. А поиск этот лучше сделать в leto_ParseRec.

цитата:

Я все же не вижу ни одной причины, зачем было бы нужно возвращаться к записи во время транзакции ...

Скажем, есть основной документ и связанные с ним. Во время транзакции изменяется основной документ, затем связанные, и затем указатель возвращается к основному. А он оказывается таким, каким был до изменения. Вот я как раз нарвался на такую ситуацию. Да мало ли, какие случаи еще могут встретиться.

 Отправлено: 13.06.10 22:27. Заголовок: Почему невозможно ? ..

цитата:

Почему невозможно ? В буфере транзакций хранятся только изменившиеся записи. Если прочитанной записи в буфере нет, значит оставляем ее такой, какая она пришла с сервера, а если есть - изменяем.

Из буфера транзакции - да, согласен, можно.

цитата:

Скажем, есть основной документ и связанные с ним. Во время транзакции изменяется основной документ, затем связанные, и затем указатель возвращается к основному.

Так зачем возвращать указатель на основную во время транзакции ? Почему не после ?

цитата:

Да мало ли, какие случаи еще могут встретиться.

Нет таких случаев, чтобы необходимо было делать это именно во время транзакции.

 Отправлено: 13.06.10 22:57. Заголовок: alkresin пишет: Нет..

alkresin пишет:

цитата:

Нет таких случаев, чтобы необходимо было делать это именно во время транзакции.

Да есть. Предположим, я решил оформить расчет зарплаты 1-го работника как транзакцию.
Упрощаю. Есть таблица удержаний. Считаю налоги (у нас их 4 штуки). Затем считаю алименты, для чего суммирую уже рассчитанные налоги, чтобы отнять их от дохода и... не нахожу их, так как на сервере их еще нет.
Затем считаю перечисление на сберкнижку, для чего нужны все выше перечисленное, и... опять его нет !
Затем... там много видов удержаний еще есть. Про начисления я и не заикаюсь, там еще более сложные случаи

 Отправлено: 14.06.10 10:18. Заголовок: Pasha пишет: Упроща..

Pasha пишет:

цитата:

Упрощаю. Есть таблица удержаний. Считаю налоги (у нас их 4 штуки). Затем считаю алименты, для чего суммирую уже рассчитанные налоги, чтобы отнять их от дохода и... не нахожу их, так как на сервере их еще нет.

А зачем их искать на сервере если они рассчитаны и они либо в массиве либо во временной таблице или в памяти?
Взял исходные данные с сервера, рассчитал все что нужно и положил на сервер результат.

 Отправлено: 14.06.10 11:35. Заголовок: Насколько я помню, ф..

Насколько я помню, функции hs_* в server.prg не стали переписывать на C из-за обработчика ошибок на C-уровне
Достаточно ли использование последовательности

hb_xvmSeqBegin();
...
hb_xvmSeqEnd();

для обработки ошибок ? Если да, то может стоит переписать оставшиеся функции на C ?

 Отправлено: 14.06.10 14:35. Заголовок: Обнаружил и исправил..

Обнаружил и исправил еще один глючек с блокировками.

Вызов:

goto 1
dbrlock(1)
goto 2
dbrlock(2)

работает
а если сделать так:

dbrlock(1)
dbrlock(2)

то фактически блокируется только текущая запись.

Исправления выложу вечером

 Отправлено: 14.06.10 14:48. Заголовок: AlexMyr пишет: А за..

AlexMyr пишет:

цитата:

А зачем их искать на сервере если они рассчитаны и они либо в массиве либо во временной таблице или в памяти?

Они рассчитаны, но не хранятся ни в массиве, ни во временной таблице. Конечно, теоретически можно переделать таким образом алгоритм. Но я этого делать не стану. Алгоритм сложный и громоздкий, там более 80к кода, я его дал в очень упрощенном виде. Скажем, один налог зависит от остальных трех, налоги за каждый месяц пересчитыватся отдельно, и глубина перерасчета не ограничена. Бывали ситуации, когда делали доплаты и пересчитывали налоги за 2 года, т.е. за 24 месяца. При перерасчетах надо учитывать все перарасчеты за все месяца, а также все изменения мин.зарплаты (аналог МРОТ) за все периоды, а они у нас меняются несколько раз в год, растут (правительство нас очень любит и заботится). Я уж лучше от транзакции откажусь. Или поправлю тразакцию, тем более как это делать - понятно.
А пример я могу дать еще. Скажем, проводится накладная. На ее основе формируется налоговая накладная, это у нас аналог счет-фактуры (которая может не совпадать с накладной). Затем надо вернуться в накладную, и записать в нее данные налоговой накладной.
Так что в общем это беспредметный разговор. Жизнь сама даст примеры

 Отправлено: 14.06.10 15:30. Заголовок: Pasha Тоже приходи..

Pasha

Тоже приходиться пересчитывать но максимум это 2-3 месяца (по больничным). А так все рассчитал, результат в массив, и в конце из массива в базу. Если не секрет что за доплата такая, что нужно за 2 года пересчет делать?

P.S. Я из Украины, в профиле уже указал.

 Отправлено: 14.06.10 15:50. Заголовок: AlexMyr пишет: Тоже..

AlexMyr пишет:

цитата:

Тоже приходиться пересчитывать но максимум это 2-3 месяца (по больничным). А так все рассчитал, результат в массив, и в конце из массива в базу. Если не секрет что за доплата такая, что нужно за 2 года пересчет делать? P.S. Я из Украины, в профиле уже указал.

Да то ли выслугу неправильно считали, то ли ранг. Через 2 года это обнаружили, и пересчитывали за весь период.
Я знаю Алексей, что вы с Украины, по leto mail list. Просто я стараюсь писать, чтобы и остальным было понятно, о чем речь