Здравствуйте, Softwarer, Вы писали:

S>А что за лукап-элементы? Вообще говоря, я бы не советовал пользоваться lookup-полями; для небольших приложений они применимы, но лучше не приобретать вредную привычку

S>Лично я предпочитаю запрашивать данные справочника в тот момент, когда пользователь собственно и начинает выбор из справочника. Кэшировать справочник на клиенте — в принципе можно; принципиальных проблем для этого тоже не вижу; на худой конец, если это будет самым простым, можно воспользоваться ClientDataSet-ом.

DBLookupComboBox в основном.. Приходится конектится сразу, так как некоторые данные проставляются по умолчанию

P>> Поэтому, при активации формы запрос переактивируется,
S>Какой? Если датасет "основных данных" — мягко говоря, непонятно зачем. Если какой-то лукаповский — хм, во-первых см. выше, во-вторых, если вдруг изменения в лукаповском запросе передергивают основной (что очень странно), значит, надо вставить между ними какой-нибудь буфер, опять же любой ClientDataSet, MemTable итп.

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

S>Хм. И в конце концов, если уж идти по пути наименьшего сопротивления, можно запускать обновление только при отсутствии редактируемых записей.
неудобно пользователю

P>>модель ситуации: пользователь заполняет документ (1-я форма), в это время вспоминает, что ему нужно заполнить справочник (2-я форма), причем данные из этого справочника должны попасть в 1-ю форму. Он открывает соответственно справочник...
S>В том подходе, который предпочитаю я, он открывает справочник, вставляет редактирует данные, и когда жмет наконец Enter — данные вставляются в базу, а кроме того возвращаются в первую форму. Та, соответственно, заполняет поля своего датасета (включая псевдолукаповские). Впрочем, это не единственный подход.
опять таки может быть длинная цепочка