Надо начать с вопроса "зачем?". В данном случае, зачем Вы постоянно открываете/закрываете таблицы в процессе работы с формой ? Какие проблемы надеетесь этим решить или предотвратить?

q1w1e1ВладимирМ,

интуитивно...:-), чем меньше времени открыта таблица, тем больше вероятность, что она останется целой(отключится эл-во, рухнет заголовоки т.д.) :-)), взял необходимое и по быстрому захлопнул её...:-)
Угу. Очередное изобретение велосипеда. Ну, успехов в этом трудном деле

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

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

Под "копией" совершенно естесственно понимать выборку из таблицы. Запрос. Select-SQL. Следовательно, логика работы в этом случае выглядит так:

- Открыть таблицу
- Сделать выборку (Select-SQL)
- Закрыть таблицу

Пользователи вносят модификации в сохраненную выборку. Затем, когда пользователь нажал кнопку "Сохранить" необходимо перенести сделанные модификации в таблицу источник. Для этого

- Открыть таблицу
- Перенести сделанные модификации из копии
- Закрыть таблицу

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

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

Ну, идентифицировать изменения можно наложив режим буферизации на выборку. Тогда функция GetNextModified() позволит определить какие записи были изменены, а GetFldState() какие именно поля. Соответственно, несложно будет перенести найденные изменения в таблицу-источник

Разумеется, Вы все это можете сделать "вручную". Но гораздо удобнее использовать для этой цели уже существующие инструменты в FoxPro. В данном случае - это CursorAdapter. Правда, придется его "допилить" под себя окружив все методы чтения/модификации командами открытия/закрытия таблиц-источников

В результате, в момент открытия формы Вы сразу же настриваете все источник данных у всех объектов на всех закладках формы и в процессе работы формы эти источник данных (CursorAdapter) уже не закрываются и, естесственно, не теряются. А вот сами таблицы/источники открываются на очень не значительное время, необходимое только для того, чтобы прочитать данные и/или внести необходимые изменения.

Только вот, здесь возникает достаточно "щекотливый" вопрос. При такой технологии, Вы вынуждены будете организовать работу максимально близкую к технологии клиент-сервер. А отсюда возникает вполне логичный идея использовать вместо таблиц DBF какую-либо серверную базу данных. Ведь они гораздо лучше защищены от различных сбоев "железа", чем "голые" DBF. Что, собственно, и требовалось доказать. Т.е. что ерундой Вы занимаетесь

Максимально возможную защищенность от глюков "железа" на сегодняшний день обеспечивает клиент-серверная технология. Если, тем не менее, Вы оставляете базу данных на DBF-таблицах, то эту технологию тоже можно реализовать, но путем больших трудозатрат. При наличии большого количества бесплатных серверных СУБД (MSDE, MySQL, Postgree и т.п.) это выглядит довольно странно.

q1w1e1ВладимирМ,

Большое спасибо за развёрнутый ответ, всё это верно, но я так и не увидел отввета простая локальная сеть(5-10 комп.), или просто один комп, что быстрее выборка из миллиона записей или поиск по индексу...
Однозначного ответа нет. Зависит от кучи условий. В среднем, с точки зрения производительности, можно сказать, что это равнозначные технологии, поскольку основа Rushmore-оптимизации (то, что ускоряет выполнение Select-SQL) - это индексы

q1w1e1недавний случай пять компов, на одном развёрнута задача, другие обращаются на эту машину, технология файл-сервер, для клиент серверной это мне пришлось бы устанавливать SQL сервер и т.д. и т.п., тут же всё просто, если нужно что-то изменить, присылаю по почте ехешник они его меняют, просто и удобно, никаких контейнеров баз данных триггеров и хранимых процедур,
У Вас несколько логических ошибок в этом рассуждении

1) Вы путаете процесс первоначальной установки (инсталяции) приложения и процесс модификации уже установленного приложения

2) SQL сервер тоже можно использовать как простое хранилище данных, которе не имеет "никаких контейнеров баз данных триггеров и хранимых процедур". В этом случае модификация приложения также будет заключаться в простой замене EXE

3) То, что Вы не используете триггера и хранимые процедуры - это скорее недостаток, чем достоинство. Это всего-лишь означает, что Вы не понимаете что это такое и зачем нужно. Как следствие, Вы делаете много "лишней" работы. В том смысле, что Вам приходится писать то, что уже написано разработчиками FoxPro и реализовано в этих самых "триггерах и хранимых процедурах". По сути, дублируете стандартный функционал "вручную".

4) Если Ваша модификация потребует изменение структуры данных, то одного EXE Вам явно будет мало. И просто заменить старые таблицы на новые Вы тоже не сможете (надо ведь и данные перенести). Необходимо будет написать дополнительный EXE который выполнит модификацию данных. При этом совершенно не имеет значения, будет ли хранилище данных в виде DBF-таблиц или SQL-сервер. А если Вы все-таки будете использовать хранимые процедуры, то модификация этих самых хранимых процедур будет относится к модификации данных, а не модификации EXE.

Другими словами, с точки зрения установки и модификации приложения нет принципиальной разницы между файл-серверной и клиент-серверной технолгией. В обоих случаях придется выполнять примерно одинаковые манипуляции.

q1w1e1т.е. технология уже определена, задача была написана половина с запросами и представлениями (надо было сделать быстрее, поэтому всегда в первую очередь select from и т.д.), звонят, на удалённых очень долго выбирает, т.е надо вызвать приходящего сисадмина, отпроситься у своего начальства, посидеть с сисадмином настроить и протестировать программу в настроенной сети..., да я за полчаса переписываю select from на do while, компилирую отсылаю, проблема исчезает, звонят опять, в другом месте долго выбирает, ну опять переписываю...в течении дня все select оказываются переписаны..
То, что Select-SQL работает медленее do while - это Ваши проблемы. Это означает, что Вы таким образом создали базу данных. Создали такие индексы. Т.е. не сумели оптимизировать работу запросов. И сисадмин тут вообще не при чем. Это исключительно логические ошибки проектирования базы данных.

Тут надо использовать SYS(3054) и смотреть, что же является "тормозом" выполнения запроса.

При этом, следует заметить, что для оптимизации Select-SQL, как правило, предпочтительнее создавать простые индексы, ключем которых является одно поле таблицы. А для Do While, наоброт, предпочтительнее создавать сложные составные индексы. Впрочем, конечно, зависит от конкретной задачи...

q1w1e1Select from удобная штука, и тут очень много "но", но только если fox выступает клиентом у SQL-сервера, если отлажена и оптимизирована сеть и т.д....
Ваша проблема в том, что Вы, вероятно, очень хорошо представляете как можно ускорить Do While (большая практика), но очень плохо представляется как можно ускорить Select-SQL. Просто банально не знаете "как оно внутри тикает". Более того, Вы плохо понимаете даже то, как вообще организована работа с данными в сети.

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

И совершенно не имеет значения, как Вы сформируете эти данные для клиента: через do while или через Select-SQL. Результат будет один и тот же. Просто у этих инструментов немного разный механизм работы.

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

Другими словами, если данные лежат не на клиентском компьютере, то вопросы отладки и оптимизации сети для файл-серверной технологии даже более важны, чем для клиент-серверной. Вне зависимости от того, через do while Вы получаете данные или через Select-SQL

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

Команда USE скачивает на клиента лишь заголовок таблицы (несколько байт) и первые несколько записей, которые должны быть отображены на форме.

Другими словами, размер таблицы вообще никак не влияет на скорость открытия таблицы. Влияет то, сколько записей должно быть отображено и нет ли большого количества записей помеченных как удаленные "перед" отображаемыми записями. Ну, и наложенные фильтры, конечно.