Большие данные и Lookup-поля
Большие данные и Lookup-поля
Каким образом организовать интерфейс в случае, когда:
1. справочник очень большой - 5000 -10000 записей
2. необходимо из справочника взять значение.
3. использование LOOKUP поля в датасете приводит к торможению - долго открывается справочник.
4. при нажатии кнопки выбора открывается мое окошко выбора чего-либо, значение подставляется в компонент.
хотелось бы КОМПОНЕНТ, который отображает то, что требуется(например наименование чего-либо), а хранит данные о ключевом поле(например, ID). И сохраняет именно ID в связанной таблице.
Кто-нибудь встречался с таким компонентом???
1. справочник очень большой - 5000 -10000 записей
2. необходимо из справочника взять значение.
3. использование LOOKUP поля в датасете приводит к торможению - долго открывается справочник.
4. при нажатии кнопки выбора открывается мое окошко выбора чего-либо, значение подставляется в компонент.
хотелось бы КОМПОНЕНТ, который отображает то, что требуется(например наименование чего-либо), а хранит данные о ключевом поле(например, ID). И сохраняет именно ID в связанной таблице.
Кто-нибудь встречался с таким компонентом???
TDBLookupComboBox (TDBLookupComboBoxEh в случае использования EhLib).хотелось бы КОМПОНЕНТ, который отображает то, что требуется(например наименование чего-либо), а хранит данные о ключевом поле(например, ID). И сохраняет именно ID в связанной таблице.
По поводу больших справочников - создай соответствующую тему в разделе FAQ - это не проблема визуальных компонент.
Допустим, есть документы, подлежащие выдачи. Их около 5000-10000(буду увелич.). Необходимо отобразить выданные документы. запрос выглядит вот так:CyberMax писал(а):А как ты получаешь наименования? У тебя жестко заданный список что-ли? И чем тебе вспомогательный запрос не устраивает?
SELECT DATE, ID_MAINDOC, MAINDOCS.NAME
FROM MAINDOCS
INNER JOIN JOBS ON (MAINDOCS.ID = JOBS.ID_MAINDOC)
Вот так будет правильно: есть код документа и его наименование с датой выдачи. Лишние данные не тягаются с сервере. Компонент (по моему желанию должен хранить в тексте NAME, в FieldName - ID_MAINDOC).
Когда происходит подключение лукап поля, то открывается запрос по ключу ID_MAINDOC, в список (который комбобокс) заполняются значения NAME's и грузятся все 5000-10000. даже при просмотре в гриде будет открытие запроса.
НАДО. Поле с "..." и нажатие на кнопочку (ТОЛЬКО ТОГДА и при необходимости добавления или изменения) открывать полный список документов с возможностью выбора.
фух... много
Теперь понял тебя. У меня была такая же проблема. Там, правда, еще одна грабля есть. Надо постоянно открывать весь набор справочника, так как если скрыть ненужные сейчас записи, то при показе старых документов в комбобоксе пустота будет.
Я решил это проблему просто - сделал наследника от TDBCustomEditEh . В конструкторе создается кнопочка "...", которая открывает окно с сеткой выбора (естественно, добавлена еще пара свойств). Готовых таких компонент не встречал.
Я решил это проблему просто - сделал наследника от TDBCustomEditEh . В конструкторе создается кнопочка "...", которая открывает окно с сеткой выбора (естественно, добавлена еще пара свойств). Готовых таких компонент не встречал.
Как такового компонента нет - у меня почти все формы в ран-тайме создаются. Код наследника прост до ужаса:
Код: Выделить всё
TCMExternalEdit = class(TDBEditEh)
strict private
FViewForm: TForm;
procedure EditClick(Sender: TObject; var Handled: Boolean);
public
constructor Create(AOwner: TComponent); override;
property ViewForm: TForm read FViewForm write FViewForm;
end;
{ TCMExternalEdit }
constructor TCMExternalEdit.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
ShowHint := True;
ReadOnly := True;
with EditButtons.Add do
begin
Style := ebsEllipsisEh;
Hint := 'Изменить';
OnClick := EditClick;
end;
end;
procedure TCMExternalEdit.EditClick(Sender: TObject; var Handled: Boolean);
begin
if Assigned(FViewForm) then
FViewForm.ShowModal;
end;
ясно.CyberMax писал(а): Это в компетенции ViewForm. У Edit'а дело маленькое - показать форму выбора значения, когда пользователь этого хочет. Остальное - не ее дело. Поэтому ViewForm - это у тебя специализированный класс формы, который ты линкуешь к набору сетки.
Видишь ли, у меня тоже формы создаются динамически, читаются кол-во полей и формируется форма редактирования данных рекордсета текущей записи.
А как быть,если несколько таких полей. Форма имеет стэк или лист? Вообще все справочники перенести на такую основу. Какой тогда смысл от SQL варианта??? Тягается вся таблица как в старые добрые времена(прошу прощение за отсупление...)
А как быть,если несколько таких полей. Форма имеет стэк или лист? Где она хранит данные ID о каждом таком поле?CyberMax писал(а):Ты имеешь ввиду таблицы справочников? Ну да. Они вытягиваются один раз при клике на "..." эдита. А что, есть какие-то еще варианты?
А вообще по абзацу распиши поподробнее, что тебе не нравится.
Для каждого эдита - свой экземпляр формы. У класса формы соответствующие свойства: FieldNameID и прочее. Точно сказать не могу - сам пока лукапкомбобокс еще не менял (только в планах). Ты же программист, подумай, как будет удобней и правильней с точки зрения архитектуры .Lars писал(а):А как быть,если несколько таких полей. Форма имеет стэк или лист? Где она хранит данные ID о каждом таком поле?