forum.clarionlife.net

Clarion 5.5

Господа, система пока работает в режиме файл-серверного приложения. Базы растут и, естественно, скорость работы приложения падает и падает... В связи с этим, сейчас встал вопрос о создании терминального сервера. Пользователей будет 5 человек.

Вопрос вот какого характера - есть н-ное количество вспомогательных баз данных, которые формируются из основных баз при формировании отчетов. То есть, сделали выборку из основной, закинули её во вспомогательную и вывели эту вспомогательную базу на просмотр и печать. Так вот не будет ли проблем, если 2-3 пользователя запустят один и тот же отчет?

Пока организую так - на вспомогательные базы жестко прописываю пути в Full PuthName справочника таблиц. Например, C:\Temp\RabAm.tps В результате этого, эти вспомогальные файлы формируются на локальной машине каждого конкретного пользователя. Естественно, что при этом совместного доступа нет. В терминале так, конечно, не выйдет.

Есть надежда, что данная проблема ничтожна, так как может быть решена разработчиками клашки. Или же нет?

Заранее спасибо.

Не специалист по терминалам, но сдается мне - это не поможет. Файлы БД открываются в монопольном режиме? И во-вторых, если было бы так просто, стали бы люди покупать дорогущие SQL сервера, переделывать под них программы и т.д.
Я в свое время столкнулся с этим (файл-сервер не тянет). И у меня сложилось мнение, что дело не столько в размере БД, сколько в количестве пользователей. Как проверял. Входит в программу один пользователь. Запускает большую долгую аналитику. Засекаю время. Входит в программу второй пользователь. Первый запускает ту же аналитику, а второй ничего не запускает, а только добавляет новые записи и редактирует старые. Засекаю время. Оно существенно увеличивается. Потом с третьим пользователем также. и т.д. После пятого можно аналитику не запускать. Причем, что интересно, добавление и редактирование записей проходит довольно комфортно.
И еще. Знаю человека, которому кто-то сказал, что Linux работает с файл-серверной БД существенно лучше. БД (1С) была лихо туда перенесена. Скорости особо не прибавило это. Только через три месяца по неизвестной причине слетел partition Линуха. Достать БД не удалось (хорошо копии БД делали). Попыток больше никаких не предпринимали, стали копить деньги на MS SQL.

Поддержу. Лучше переводить сразу на SQL. Сразу рывок будет в надежности и скорости!

optron писал(а):Есть надежда, что данная проблема ничтожна...

У нас для входа для каждого терминала используется свой пользователь, таким образом если ты будешь писать не в C:\Temp а в C:\Users\userXXX\AppData\Local... или даже просто создав уникальное имя таблицы типо MyTable_1289364091283472309874 для каждого пользователя (т.е. не жестко как сейчас, а изменяя путь при создании файла любым способо, хоть через переменную хоть через PROP:Name)... все будет ОК.

Пользователи также будут разграничены. И естественно нужно создавать рабочий файл в Темповской папке данного пользователя. Просто пока не соображу как к ней прицепиться. Как я понимаю, если я в Full PuthName справочника таблиц опишу путь к файлу
%USERPROFILE%\Local Settings\Temp\RabAm.tps, то это не сработает. Видимо, ловить нужно в самих шаблонах.

Переводить на SQL, конечно же самый оптимальный вариант. Но даже если отбросить затраченное на перевод время, то интересно, на чем лучше всего писать клиентскую часть?

IMHO по скорости разработки Clarion 6 + MAV + MS SQL вне конкуренции!

Хм... Заинтригован )) Спасибо.

Переходить с 5.5 на 6 сейчас в конце 11 года? Я пошел бы такими путями. Перевел бы приложение, написанное на 5.5, на SQL, а потом бы на 8-ку, если к тому времени не появится 9-ка. А еще лучше - перевел бы приложение на 5.5 сначала на 8-ку, а потом бы на SQL.

Зачем столько заморочек.
IMHO при переводе на скуль нужно держаться за 6-ку как за последнюю стабильную версию.
Все. Что тут говорить.

"Слушал я вас, слушал и ПОНЯЛ!" (дальше сами продолжите)

Ты же сам озвучил ответ на свой вопрос! Файлы у тебя временные! Значит делается всё очень просто. в NAME файла кладёшь переменную. А потом этой переменной присваиваешь уникальное имя временного файла средствами Clarion или WinAPI. (GETTEMPFILENAME). Система сама найдёт куда кинуть файл и озаботится, чтобы никто больше не получил такое имя. И ей глубоко пилевать сколько копий приложения запущено. Всё будет работать.

Ну, в общем всё верно. Спасибо всем.

Сделал перед открытием файла в Global embeds вот такую конструкцию:

RabAm{PROP:Name}=clip(GLO:Login)&'RabAm.tps'

Теперь для каждого пользователя при запуске программы временные файлы переопределяются на свои с личным 3-х буквенным префиксом (GLO:Login), который у меня так и так присутствует в системе.

Ну это так, может еще какому нибудь неучу типа меня понадобится и можно будет найти на форуме.

У меня давно программы работают с tps в терминальном режиме. Проблем нет, все очень быстро и надежно, у sql серверов в данных вопросах преимуществ нет. Пять пользователей немного, на современном бытовом компьютере может 2-3 десятка спокойно работать. По поводу временных файлов рекомендовал бы не класть в стандартные виндовые каталоги пользователей, а сделать свои в корневой папке приложения. В этом случае мы все держим в одном месте, просто перемещать, обновлять, если будут другие программы, избегаем потенциальных конфликтов. Поскольку сейчас проблем с количеством оперативной памяти нет, то под отчеты вместо временных файлов можно использовать очереди. Получаем заметный выигрыш в скорости. Я часто отчеты формирую в локальные очереди, а для их просмотра стандартными средствами использую служебную таблицу с одним полем id, для которой устанавливаю range limit c 1 по количеству записей в очереди.

FinSoft писал(а):Проблем нет, все очень быстро и надежно, у sql серверов в данных вопросах преимуществ нет.

Смеялся

А что вызывает улыбку? То, что прочитать информацию из оперативной памяти локально быстрее, чем извлечь из sql-сервера, или то, что серверные операционки работают надежно? Преимущества sql-серверов на данный момент иные. Это открытость решений, которая позволяет чать функций по разработке и технической поддержке делегировать другим людям (разработчикам в других средах, админам клиентов), наличие готового и хорошо протестированного функционала для администрирования, унифицированный доступ из разных инструментов. Между тем, сама концепция клиент-серверного доступа к базам данных стала довольно противоречивой в свете быстрого развития технологий. Если есть возможность организации централизованных вычислений, то какой смысл мучиться с распределенными? Аппаратные решения развиваются гораздо быстрее, чем программные, поэтому только недавно начали говорить, а может нам кроме sql поддерживать еще альтернативные средства доступа (noSQL). В самом Оракле заявили, что sql-сервера не являются оптимальными решениями для итерактивной работы с данными, но как-то быстро замяли.
Если вернуться к нашим "баранам", то пользовать tps+терминал или sql зависит от ряда причин. Прежде всего от того, является ли софт тиражным решением для конечных бизнес-пользователей или заказным. В первом случае я бы отдал предпочтение tps+терминал, во втором sql. Далее от опыта конкретных разработчиков и наличия готовых решений. Ну и учесть, что кларион разрабатывался как инструмент для работы со встроенными форматами баз данных и выглядит не очень убедительно при работе с sql-серверами. Я имею ввиду всю концепцию, начиная от использования словаря (по сути дублирующего функции sql-сервера), жесткой привязки к структуре данных, компилируемых деклараций окон и т.п.