2 Лоху

А по теме поста у тебе что-нибудь есть или и дальше сам с собой будешь разговаривать?

До жив до своих лет, я понял одно - бывает все.

А проблемы (тут как-то был мой топик) с 1-ой формой с кучей полей со списками и прочей мутотенью. В чем причина я так и не понял (то ли акес глючит, то ли я, то ли у меня и у заказчика стоит та самая заплатка от микрософта, которая делает работу некоторых приложений раз в 10 медленее, то ли из-за защиты, то ли .... Решил (временно, пока не найду причину) просто всегда держать эту форму открытой (скрытой), тогда скрость ее появления нормальная (около 1-2 сек)

>Во время запроса Accessa скорость передачи ~100-200 кбайт/с

Ага и может либо падать до 0 либо взлетать до 3-3Мб. Не предсказуемо.


Меня чистый Акес при работе в сети ЗАДОЛБАЛ .

Поверте мне, я испробовал все способы оптимизации, описанные в хелпе, в MSDN (настройки Jet), книгах (Гетц и другие)
И спрашивать про дефрагментацию как и сжатие/восстановление для меня обидно. :(

2 Лоху Позорному

>Вспомнил, был топик. У тебя там кажется какие-то хитрые (большие) join'ы были?

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

>1. Запрос должен быть достаточно сложным, чтобы у аксеса съехала крыша.

Он у меня простой Select Поля From ОднаТаблица Where ID=Чему-то

>2. Таблицы должны быть прилинкованы через сеть. Подключение через сеть к себе же (через шару) - все нормально, летает.

Да, через сеть: //Server/Data/data.mdb

>3. (!!!) Запрос должнен быть хотя бы один раз сохранен в режиме SQL. Звучит полным бредом, но факт. Если запрос от момента рождения до момента смерти сохранялся в режиме конструктора - все летает. Запросы, создаваемые на лету - тормозят как сохраненные в SQL.

Одни авторы (вроде Гетц, но не уверен) предлагают открыть в режиме SQL добавить проблел, сохранить. И более его не трогать. Таким образом Jet перестроит план выполнения. Тогда получается, что лгут? Буду пробовать.

>4. В запросах используются ограничения на индексированные поля. Вернее, они-то как раз и не используются при выполнении запроса к связанным через сеть таблицам в случае сохранения в виде SQL

Надо будет посмотреть, как раз и индексов полно.

>и действительно, для сохраненных в SQL и в конструкторе планы отличаются.
Оху$ть, буду пороверять

> Для показа плана выполнения запроса надо в реестр какой-то ключ добавить, точно не помню но могу найти.

Да у меня это есть, Гетц подробно описывает, но не описывает как эту абракадабру расшифрововать, хотя Table scan виден как и Index
Надо будет пробовать

Спасибо за толчок в нужном(о, как я надеюсь на это!) направлении.

2 Владимир Смирнов

А настройки по пропускной способности там есть?

2 Лоху Позорному

Кол-во записей не проблема для анализа. Я недавно внес тестовые данные в прогу по 800 000 - 1 000 000 записей в таблицы. Прикольно - все шевелиться, на них и буду смотреть план.

2 alexkov

> Если правильно приложение слелано и не тормозит при одном подключении то не будет тормозить и при 5, 10, 30, и т.д.

Речь идет о файл-сервере (mdb+mdb). И ему по хрену, что ты в условии отобрал 1 запись из 100 000.Все равно притащит себе все 100 000 и тогда уж отберет 1.
Так что, чем больше записей тем тормазнутей становиться прога.
А сделать правильней можно только перейдя на клиент-серверную технологию, что в данном случае не обсуждается.

>Вот тебе и все тестирование.
Ну тогда наладь мне такое тестирование у меня дома (за твой счет, разумеется). Согласен на 3 ПК, 1 свитч, и кабель 5-ой категории.

2 Лоху

А ты попробуй выбрать из 100 000 записей 1 по PrimaryKey и посмотри, сколько Акес тебе через сеть тянет. 1 индекс несколько мегабайт весить не может