|
Сервер на базе Access
|
|||
---|---|---|---|
#18+
Я тут столкнулся с проблемой производительности. Приложение с разделенной базой, многопользовательское, на клиенте довольно сложная логика, в обычном режиме непосредственно с базой большого обмена нет, все работает нормально. Но потребовалось прикрутить импорт из Экселя. После получения оносительно короткой строки с данными и обработки, при сохранении идет довольно интенсивный обмен данными с базой, любое обращение к базе занимает 100-150 микросекунд, в результате при медленной сети сохранение одной строки занимает порядка полутора секунд. Если же бэкэнд находится на той же машине, то 1000 строк сохраняются за несколько секунд. Возникла идея: поместить дополнительную базу с логикой импорта на тот же файловый сервер, где находится бэкэнд, клиентское приложение копирует файл импорта туда же и удаленно запускает импорт, получая в ответ логи и сообщения. Кто-нибудь делал такой вот третий уровень в Акцессе, своего рода сервер приложений? Не предлагайте переход на серверную базу, там у клиента свои заморочки, это ему не подходит. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2017, 14:21 |
|
Сервер на базе Access
|
|||
---|---|---|---|
#18+
Теперь вот пытаюсь понять, каким образом лучше запустить "сервер приложений" на удаленной машине и как лучше общаться с ним. Пока в голову ничего лучшего не приходит, чем запуск по расписанию на удаленной машине командного файла, который проверяет на наличие нового файла импорта и запускает приложение обработки. Приложение, в свою очередь, пишет логи и запросы к пользователю в базу, а клиентское приложение по таймеру же анализирует эти логи/запросы и передает команды назад тем же некрасивым способом. Могут ли два акцессовских приложения, запущеных на разных машинах, общаться между собой напрямую, минуя промежуточные таблицы/файлы и таймеры? Подозреваю, что нет, насмотря на наличе СОМ ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2017, 14:47 |
|
Сервер на базе Access
|
|||
---|---|---|---|
#18+
может локально сделать таблицу? на клиенте в неё импортировать файл, а далее эту таблицу уже копировать в таблицу в общей базе (добавлять или обновлять). ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2017, 14:54 |
|
Сервер на базе Access
|
|||
---|---|---|---|
#18+
Не работает Access нормально как файл сервер. Обсуждалось десятки раз. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2017, 14:56 |
|
Сервер на базе Access
|
|||
---|---|---|---|
#18+
Вот тебе другая идея. Сначала выполняется импорт в локальную БД с интерфейсом, а потом данные одним запросом копируются в боевую БД. Поскольку речь идёт о копировании целой таблицы, которой в базе назначения нет, процесс должен быть быстрым. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2017, 15:06 |
|
Сервер на базе Access
|
|||
---|---|---|---|
#18+
MrShin, если есть долглиграющая процедура с занесением множества записей в Recordset, открытый на таблице из сетевой БД, то ускорить процесс можно применением транзакции или использование ADODB.Recordset-а с пакетным обновлением (UpdateBath). А то, что вы хотите замутить - не взлетит (ИМХО). ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2017, 15:08 |
|
Сервер на базе Access
|
|||
---|---|---|---|
#18+
aleckoможет локально сделать таблицу? Да, такой вариант рассматривается, но там десятки таблиц, по которым разносятся данные и среда многопользовательская, сложновато будет все это утрясти, также, как и с копированием из локальной базы, как предложил Akina, но можно. Сама база не такая маленькая, копирование на локальную машину може съесть выигрыш. Анатолий ( Киев )процесс можно применением транзакции или использование ADODB.Recordset-а с пакетным обновлением (UpdateBath) Транзакции уже используются, это действительно дает ускорение почти в 2 раза. Как думаете, имеет смысл пакетным обновлением заморачиваться? Мне кажется, что разница будет небольшая. Анатолий ( Киев )то, что вы хотите замутить - не взлетит Вот у меня тоже такие подозрения. Просто пакетная обработка на сервере у нас давно используется, назад только конечный результат передается, а здесь хотелось инерактива добавить. Но больно уж все это коряво получается. Эх, если бы серверную базу можно было использовать... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2017, 16:06 |
|
Сервер на базе Access
|
|||
---|---|---|---|
#18+
MrShinМогут ли два акцессовских приложения, запущеных на разных машинах, общаться между собой напрямую, минуя промежуточные таблицы/файлы и таймеры? Подозреваю, что нет, насмотря на наличе СОМТаки могут, просто заахаетесь на современных ОС права доступа на DCOM настраивать. Синтаксически всё начинается проще пареной репы, см. второй параметр CreateObject(). Но нюансы тоже будут. Например, если захочется асинхронного вызова метода серверного объекта. Тогда и таймеры могут появиться как средство реализации очереди сообщений. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2017, 17:34 |
|
Сервер на базе Access
|
|||
---|---|---|---|
#18+
MrShinВозникла идея: поместить дополнительную базу с логикой импорта на тот же файловый сервер, где находится бэкэнд, клиентское приложение копирует файл импорта туда же и удаленно запускает импорт, получая в ответ логи и сообщения. Кто-нибудь делал такой вот третий уровень в Акцессе, своего рода сервер приложений? Не предлагайте переход на серверную базу, там у клиента свои заморочки, это ему не подходит. Делал около 6 лет назад подобный мегакостыль, отвратительно. В excele в силу особенностей было порядка 14000 строк, с 36-38 полями. Всё дохло при импорте. Вы можете конечно реализовать, но это тупиковая ветвь эволюции. Плюс иногда файловый сервер почему то подбаговывал и появлялись сохраненные резервные копии файлов. УЖос. Может все таки попробуете перетащить на mysql либо ms sql. Оболочку можно такой же оставить. Если клиент ваш работает в аксессе, то он ведь абсолютно также и продолжит там работать. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2017, 17:45 |
|
Сервер на базе Access
|
|||
---|---|---|---|
#18+
MrShin, Не вижу препятствий... Я делал почти подобное для одной из брокерских контор, там нужно было отслеживать в реальном времени изменение курсов... Задача примерно такая - откуда то (не важно) прилетает извещение об изменении курса за позицию (позиции) и нужно чтобы у всех на мониторах было актуальное состояние автоматически... - база лежит на сервере - у юзеров нужное из базы постоянно на экране должно быть актуальным. Решение примерно такое: 1. Клиентская часть по таймеру (настраивает сам юзер, от пару секунд до минут) проверяет значение счетчика изменений в БД, если оно изменилось, обновляет содержимое экрана. 2. На сервере висит фоновое задание, которое по таймеру (тоже настраивается) проверяет содержимое определенной папки. Если в ней (не важно как) появляется извещение (файл определенного формата) об изменении курса чего либо, происходит изменение данного курса в бд, увеличение счетчика изменений и перемещение обработанного файла в папку с архивом изменений курсов... Все замечательно работает! И сводится к тому, что нужно просто метнуть в определенную папку файл изменений (у вас это импорт). Слабое место в вашем случае - кривые файлы экселя (у меня был жесткий формат), тут нужно (если что не так) импорт файла не делать вообще,а кривой файл экселя вместе с его логом бросать не в архив, а в папку брак... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.10.2017, 20:19 |
|
Сервер на базе Access
|
|||
---|---|---|---|
#18+
vmagНе вижу препятствий... Я делал почти подобное для одной из брокерских контор Да, это вполне работоспособно, недолюбливаю таймеры только в силу фактической однопоточности Акцесса. Если скорость в текущей версии не будет устраивать, примерно так и сделаем. sdfJh24onВ продолжение: вспоминаеЦЦа Интересно... Но, боюсь, это также не подойдет по той же причине, что и серверная БД - департамент-заказчик совершенно не хочет зависеть от собственного ИТ, максимум локальная сеть с файлопомойками :) Впрочем, для очень крупных компаний, типа этого клиента такие парадоксальные требования не редкость. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2017, 07:30 |
|
|
start [/forum/topic.php?fid=45&msg=39532501&tid=1612034]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
47ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 162ms |
0 / 0 |