2r0ckЖутко тормозящую прогу (в качестве СУБД - Access) недавно перевел на SQLServerExpress и исправил несколько кусков кода. Так вот программа начала работать в раз 10 (!) быстрее- даже пришлось на загрузку проги ставить sleep(паузу) - чтобы показывалось окно приветствия (а не проскакивало) =) . Рефакторинг кода я еще не делал.. в коде особо ничего не менял - отсюда складывается вопрос: неужели Access настолько позади SQLServerExpress? Я ожидал прироста производительности, но что бы в 10 раз.... =) . Ваше мнение господа )
вот одевал тапочки и бегать не мог, а как гипс сняли так в кроссовках и побежал! все дело в тапках! :)

к тому же вот это:
автор Так вот программа начала работать в раз 10 (!) быстрее- даже пришлось на загрузку проги ставить sleep(паузу) - чтобы показывалось окно приветствия (а не проскакивало) =)
есть мнение, что если проблема в показывании окна приветствия, то БД ни причем тут ;)

хотя:
1) Для обработки данных Аксесс копирует к себе всю таблицу и потом на клиенте это все обрабатывается
2) Сервер обрабатывает данные сам

При разработке Аксессовских файл-серверных приложений крайне важно минимизировать объем передаваемых данных. Да, такая же рекомендация существует и для клиент-серверных приложений, однако в случае с Аксессом эта рекомендация имеет критическое значение.
Например если объем таблицы 20 Мб, то чтобы в Аксессе найти в ней какое-то значение, необходимо перед этим эти самые 20 Мб скопировать. ( LAN 100 Мбит/сек - скорость передачи ~12 Мбайт/сек => 2 секунды минимум потребуется только чтобы получить данные)
как-то так

2r0ckЖутко тормозящую прогу (в качестве СУБД - Access)
тут думаю дело в:
а) самой спроектированной БД (нормализация/денормализация и прочее)
б) способе организации интерфейса
Для примера (с чем сам столкнулся):
Было в таблице поле. Поле со списком. Источник записей - значения того же поля, введенные ранее. То есть, при открытии поля со списком запускался запрос, который должен был прошерстить всю базу, выбрать все значения и сгруппировать их. Записей было много и открытие поля со список занимало ~3-5 секунд. Взамен этого была сделана служебная таблица с перечнем этих значений. Время открытия поля со списком стало менее секунды.
Таких полей со списком было несколько. Форма открывалась секунд этак 10-15. После оптимизации интерфейса в соответствии с особенностями механизма работы MS Access форма открывается 1-2 секунды. Как то так

pkarklinавторПри разработке ... файл-серверных приложений крайне важно минимизировать объем передаваемых данных.

Интересно, каким образом?!
Думаю, вам повезло, вы не видели какие могут быть схемы интерфейсов и данных ;)

pkarklinавторПри разработке ... файл-серверных приложений крайне важно минимизировать объем передаваемых данных.

Интересно, каким образом?!

F1Примечание. Связать таблицу можно только в базе данных Microsoft Access, но не в проекте Microsoft Access.

Связанные таблицы используются как обычные таблицы в базе данных Microsoft Access, но следует помнить, что на самом деле они не находятся в базе данных Microsoft Access. Для каждого просмотра данные связанной таблицы извлекаются из другого файла. Это требует времени, особенно если связанная таблица находится в сети или в базе данных SQL.

Если связанная таблица хранится в сети или в базе данных SQL, следующие правила помогут получить наилучшие результаты.

Если оставлять открытыми связанные базы данных, то можно повысить производительность при открытии основной базы данных и при открытии таблиц и форм. Для этого необходимо создать пустую таблицу в связанной базе данных и связать ее с основной базой данных. Для открытия связанной таблицы используется метод OpenRecordset. Это предотвращает постоянное открытие и закрытие связанных баз данных, а также создание и удаление связанных файлов (с расширением LDB) ядром базы данных Microsoft Jet.
Просматривайте только необходимые данные. Не перемещайтесь без необходимости по экранам в режиме таблицы. В больших таблицах избегайте перехода к последней записи. Если требуется добавить в большую таблицу новые записи, выполняйте команду Ввод данных (меню Записи), чтобы не загружать в память существующие записи.
Применяйте фильтры или запросы, чтобы ограничить количество записей, просматриваемых в режиме формы или таблицы. В этом случае по сети передается меньше данных .
В запросах, включающих связанные таблицы, старайтесь не использовать функции в условиях отбора в запросе. Особенно избегайте в любых местах запроса применения статистических функций по подмножеству, таких как Dsum. При вызове статистической функции по подмножеству Microsoft Access для выполнения запроса загружает все данные из связанной таблицы .
Если приходится часто добавлять данные в связанную таблицу, создайте для добавления записей форму, у которой в свойстве Ввод данных (DataEntry) задано значение Да - сам не знал O_o . В этом случае в форме, открываемой для ввода данных, не выводятся существующие записи. Это экономит много времени, позволяя избежать загрузки записей из связанной таблицы.
Помните, что другие пользователи могут пытаться получить доступ к внешней таблице одновременно с вами. Если база данных Microsoft Access используется в сети, старайтесь не блокировать записи дольше, чем это необходимо.

и так далее.

pkarklin
Интересно, и какое отношение это имеет к Вашему "При разработке Аксессовских файл-серверных приложений", если речь идет о связанных таблицах, что уже клиент\сервер и эти рекомендации применимы к разработке любого клиента для клиент серверной СУБД. Я спрашивал как можно "минимизировать объем передаваемых данных" в файл\серверной архитектуре . ;)
2r0ck
Красивые блондинки работают быстрее, чем полные, лысые девушки... ???
Как эргономика интерфейса влияет на скорость работы программы? - она влияет на скорость работы пользователя с программой..
А вот так! ;)
во как!!11
Для примера (с чем сам столкнулся):
Было в таблице поле. Поле со списком . Источник записей - значения того же поля, введенные ранее. То есть, при открытии поля со списком запускался запрос, который должен был прошерстить всю базу, выбрать все значения и сгруппировать их . Записей было много и открытие поля со список занимало ~3-5 секунд. Взамен этого была сделана служебная таблица с перечнем этих значений . Время открытия поля со списком стало менее секунды.
Таких полей со списком было несколько. Форма открывалась секунд этак 10-15. После оптимизации интерфейса в соответствии с особенностями механизма работы MS Access форма открывается 1-2 секунды. Как то так
а, каково! двух зайцев одним выстрелом! (то есть на два вопроса ответил одним примером! xD )
Как видим, в примере файл-серверной архитектуры был изменен способ организации интерфейса (формирования значений в поле со списком) - в итоге был получен PROFIT :)

pkarklinво как!!11
и так далее.

Интересно, и какое отношение это имеет к Вашему "При разработке Аксессовских файл-серверных приложений", если речь идет о связанных таблицах, что уже клиент\сервер и эти рекомендации применимы к разработке любого клиента для клиент серверной СУБД. Я спрашивал как можно "минимизировать объем передаваемых данных" в файл\серверной архитектуре. ;)
обращаю ваше внимание на то, что в случае клиент-серверной архитектуры профит был бы гораздо меньше, так как данный запрос бы выполнялся на сервере без передачи по сети. ;)
как вам ответ? :)