Страница 2 из 10

Btrieve и clarion

Добавлено: 28 Январь 2019, 19:06
Игорь Столяров
Дать пример скрипта на создание DDF P.SQL для таблицы ?

Btrieve и clarion

Добавлено: 28 Январь 2019, 19:28
finsoftrz
SQL, конечно, штука крутая. Но, нет, спасибо, не надо.

Btrieve и clarion

Добавлено: 28 Январь 2019, 19:35
finsoftrz
Про алгоритм рассказывать долго и не нужно это. Считайте, что обычный set по ключу, в котором первое поле дата (long) и оно в заданном диапазоне. Типа такого:

clear(pre:record,-1)
pre:date=dateBeg
set(keyDate,keyDate)
loop
next(file)
if error() or pre:date>dateEbd
break
.
....
.

Вот эта конструкция работает медленно, пока записи после первого прохода не попадут в кэш. Затем быстро. Таблица в районе 8 млн записей, но мы их не все смотрим. Еще в цикле разные get на другие таблицы по первичному ключу, но это мелочь. Вся работа локальная.

Btrieve и clarion

Добавлено: 28 Январь 2019, 19:40
finsoftrz
Не знаю, насколько критично, на том же компе в боевом режиме крутится та же база на tps с реальными пользователями. Висят 12 пользователей в терминальных сессиях и периодически могут еще кто-то коннектиться через ip драйвер. Но и на своем компе ощутимую разницу с скоростях я тоже вижу.

Для tps тоже такой эффект присутствует. Но в меньшей степени.

Btrieve и clarion

Добавлено: 28 Январь 2019, 19:46
Игорь Столяров
finsoftrz писал(а): 28 Январь 2019, 19:35Про алгоритм рассказывать долго
Тоже это подозревал, но всё-таки решил спросить … ;)

При выборке по ключу, скорость зависит ещё и от размера самого ключа. Если там несколько полей, среди которых STRING и REAL -
то всё это может заметно тупить, пока ключ не будет загружен в кеш. Также есть смысл прогнать большую БД через REBULD, не зря
ведь в современных версиях добавили фоновую дефрагментацию БД ...

Btrieve и clarion

Добавлено: 28 Январь 2019, 19:57
Игорь Столяров
Не совсем верно сказал … REBULD перестроит и оптимизирует только ключи.
Для дефрагментации самого списка, нужно перезагрузить его через текст при помощи утилиты BUTIL.

Btrieve и clarion

Добавлено: 28 Январь 2019, 20:24
finsoftrz
Нет, в ключах только два long. При обычном чтении set/next тоже заметно. Прерываем процесс. Запускаем заново. До того момента, где прервали бежит быстро, затем опять медленно.

Btrieve и clarion

Добавлено: 28 Январь 2019, 20:41
Игорь Столяров
finsoftrz писал(а): 28 Январь 2019, 20:24При обычном чтении set/next тоже заметно.
Попробуйте:
- открыть список только на чтение и как вариант, ещё с монопольным доступом.
- Открыть файл под транзакцией Logout(), т.к. Btrieve не поддерживает LOCK().

Btrieve и clarion

Добавлено: 28 Январь 2019, 21:21
finsoftrz
Я думаю, что разница на порядок связана все таки с тем, что тест проводился на боевом "сервере". По монитору ресурсов, у него вся оперативная память была забита (8ГБ). Кроме учетной системы и терминальных сессий еще запускали openOffice.

Подрихтовал немного процедуру прогрева кэша. На моем компьютере разница до прогрева и после, конечно, заметна, но уже не на порядок. Если еще чего найду, напишу.

Btrieve и clarion

Добавлено: 28 Январь 2019, 22:38
RaFaeL
Игорь Столяров писал(а): 28 Январь 2019, 18:11Как ему её посмотреть хотя бы ? Как установить SQL или настроить ODBC источники - Вы ему никогда не сможете объяснить.
Ну во-первых, давайте не мешать в кучу "коробочное решение" и "демо-версию". К коробочному решению прилагается пошаговая инструкция в картинках со всеми нужными ссылками. Если ставить по этой инструкции, то в 95% случаев все работает "из коробки" и не надо ничего настраивать. Просто у вас нет такой инструкции с картинками )) А демо-версию вполне можно собирать на tps, не обязательно полнофункциональную - то, что работает на стороне сервера, мы просто в неё не включаем, это будут "ограничения демо-версии"

Btrieve и clarion

Добавлено: 28 Январь 2019, 23:04
kreator
Игорь Столяров писал(а): 28 Январь 2019, 13:46Переход на SQL всё-таки требует переделки всего приложения,
чего избалованные шаблонами программисты Clarion - не любят.
Народ, прекратите! Всех неофитов тут распугаете. Для перехода на SQL нужно только драйвер в словаре сменить. Классы и шаблоны работают с SQL хорошо. Нужно только политику загрузки броуза сменить с Page на File. Очень рекомендуется. Далее можно двигаться в направлении всяких расчётов, отчётов. Менять парадигму set/get на select, хотя и так работает. Многие переходили, и я в том числе. Проблем особых не было, а скорость и все остальные плюхи на лицо.

Btrieve и clarion

Добавлено: 28 Январь 2019, 23:18
RaFaeL
kreator писал(а): 28 Январь 2019, 23:04Нужно только политику загрузки броуза сменить с Page на File. Очень рекомендуется.
Ни к чему, просто нужно сделать все ключи, по которым строится броуз, уникальными, а постраничную загрузку отключать не надо

Btrieve и clarion

Добавлено: 29 Январь 2019, 4:22
morkovin
RaFaeL писал(а): 28 Январь 2019, 23:18просто нужно сделать все ключи, по которым строится броуз, уникальными, а постраничную загрузку отключать не надо
+ поля, которых нет в броусе, но используются в процедуре, надо обязательно указывать в HotFields

Btrieve и clarion

Добавлено: 29 Январь 2019, 8:18
Игорь Столяров
RaFaeL писал(а): 28 Январь 2019, 22:38 Если ставить по этой инструкции
Где-то здесь уже можно подводить промежуточный итог дебатов … Если нет возражений - то я это сделаю.

1. Просто перевести приложение на SQL заменой словаря в общем случае нельзя, нужно вносить изменения в структуру БД
и само приложение. Для Btrieve - можно, в частном случае, можно даже заменить драйвер TPS на Btrieve программно.

2. Просто установить приложение SQL приложение на компьютер нельзя, но можно выполнить некую инструкцию с картинками.
При этом мы должны рассчитывать, на то, что у пользователя есть желание, квалификация и административные права для
её выполнения. Для Btrieve - можно, в частном случае, не требуется отдельно содержать приложение с TPS для "посмотреть".

3. Локальное приложение с SQL будет работать медленнее, чем аналогичное с TPS. А приложение с Btrieve - быстрее, чем с TPS.

При этом, безусловно, у SQL - масса преимуществ, которых нет в ISAM драйверах БД. Это понятно и бесспорно.
Но если говорить, о том, что бы быстро "улучшить" работу существующего приложения с TPS - то драйвер Btrieve безальтернативен.
Как-то оно так получается … ;)

Btrieve и clarion

Добавлено: 29 Январь 2019, 9:28
finsoftrz
Игорь Столяров писал(а): 29 Январь 2019, 8:18 При этом, безусловно, у SQL - масса преимуществ, которых нет в ISAM драйверах БД. Это понятно и бесспорно.
Я бы еще добавил то, что у isam тоже есть масса преимуществ, которых нет в sql. Это тоже понятно и бесспорно. Просто две разные технологии, два разных мира. Надо работать в соответствии с выбранной архитектурой и все будет хорошо. Выбор зависит от личных предпочтений, особенностей мышления разработчика, имеющихся наработок и опыта. По какой схеме осуществляется доступ к данным здесь вторично.