Автоподстановка из родительской таблицы

← →
YurikGL © (2005-01-04 09:35) [0]

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

Пусть есть две таблицы Товары и Приходы
Нужно сделать добавление/изменение прихода. Хочу сделать DBComboBoxEh с MRUList-м в который загружен список товаров. Далее обрабатывать события beforePost/insert и т.д.
Теперь, если в ADODatasetPrihod организовать Lookup-поле, то DBComboBoxEh не дает набирать в нем текст, хотя ReadOnly везде вырублен. Если делать запросом на уровне Access-a, то Access генерирует новую запись в таблице товары и сам подставляет его id-к.
В общем, по всякому пробовал, что-то не получается.

← →
msguns © (2005-01-04 10:16) [1]

Справочник товаров надо делать отдельной формой, открываемой при коррекции не только приходов, но и отпусков (реализации). В модуле предусмотреть несколько режимов: "только просмотр", "просмотр с возможностью редактирования" и т.д., задаваемых в зависимости от документа.
А вообще, ИМХО, посмотри как построен учет товаров в "брандовских" продуктоах, а 1С той же.

← →
YurikGL © (2005-01-04 10:29) [2]

> msguns © (04.01.05 10:16) [1]

вопрос в том, как совместить автоподстановку при наборе с использованием родительской таблицы?

← →
YurikGL © (2005-01-04 10:30) [3]

Приходы и товары я для примера привел...

← →
Sergey_Masloff (2005-01-04 10:46) [4]

Как правильно сказал msguns © (04.01.05 10:16) [1] если список возможных подстановочных значений > 10 комбобокс не годится.
Давай вводить в подстановочное поле текст и этот же текст передавай в поисковую форму. При этом поисковая форма открывается при выходе из контрола. Можно сделать так - если введено много (скажем 5 символов) то сразу запускаешь процедуру отбора и если она вернула 1 значение то подставляешь его сразу не показывая пользователю форму а если результатов много или критерий неэффективен то показываешь форму.

← →
YurikGL © (2005-01-04 10:51) [5]

> Sergey_Masloff (04.01.05 10:46) [4]

> Как правильно сказал msguns © (04.01.05 10:16) [1] если
> список возможных подстановочных значений > 10 комбобокс
> не годится.

Хотелось бы, что-бы человек начал набирать название товара, набрал первые три-четыре буквы, и список сократился до 2-3 х элементов.
В моем случае это - не товары а фамилии людей.

← →
msguns © (2005-01-04 10:56) [6]

Опять же ИМХО.
Отказаться от редактирования в гриде и вообще DB-Aware контролов (дедовщина и местничество). Если надо подстановка из справочника с несложными сущностями (т.е. такими, которые кроме своего наименования ничего более не содержат), то на форму редактирования записи соотв.документа класт комбобокс со списком, куда предварительно закачивается содерэимое этого самого справочника, а первым элементом списка добавлять что-то типа такого
<Добавить новый>
По выбору узером этого итема открывать форму для добавления в справочник, по завершению добавления (успешному, ессно), перечитывать справочник и заполнять список комбобокса по-новой.

Хотя, опять же ИМХО, во многих случаях можно вообще отказаться от такого справочника как от таблицы БД и записывать в раб.таблицы (документы) непосредственно текст. Заполянить же список с помощью запроса к этой же осн.таблице только по полю этого "справочника" с DISTINCT.
Как пример, "справочник" единиц измерения.

← →
msguns © (2005-01-04 11:01) [7]

Если люди, то, конечно, нужен справочник. И нужна модальная форма, показывающая список людей. А на этой форме сделать удобный для узера поиск, упорядочение по выбранной колонке и фильтацию. Панель на форме должна содержать еще кнопки "Выбрать", "Редактировать", "Добавить", "Удалить". Причем эти кнопки должны быть активны в зависимости от режима. Например, в режиме простого просмотра-коррекции справочника, кнопка "Выбрать" неактивна, а в режиме добавления в некий документ (например, в наряд), неактивны должны быть остальные 3, а 1-я активна. И т.д.

← →
YurikGL © (2005-01-04 11:04) [8]

> Хотя, опять же ИМХО, во многих случаях можно вообще отказаться
> от такого справочника как от таблицы БД и записывать в раб.таблицы
> (документы) непосредственно текст.

это понятно... но ведь всякие 3-и нормальные формы....

> то на форму редактирования записи соотв.документа класт
> комбобокс со списком

комбобокс или DBComboBoxEh?
Я хочу через DB-компоненты реализовать. В т.ч. в целях самообучения.

Так вот проблема в том, что если это - DBComboBoxEh то если поле lookup то DBComboBoxEh блокируется на ввод текста.

← →
YurikGL © (2005-01-04 11:05) [9]

> msguns © (04.01.05 11:01) [7]

У нас 40 человек и делать отдельную форму с глобальным поиском не актуально.

← →
Sergey_Masloff (2005-01-04 11:08) [10]

YurikGL © (04.01.05 10:51) [5]
>Хотелось бы, что-бы человек начал набирать название товара, >набрал первые три-четыре буквы, и список сократился до 2-3 х >элементов.
>В моем случае это - не товары а фамилии людей.
Зачем. Пока он не набрал 3-5 букв в этом нет смысла. Когда набрал ему откроется поисковая форма в которой и так будет уже не так много. Преимущества инкрементного поиска - миф, далеко не всем пользователям он понятен и удобен а на червер может быть неслабая нагрузка.
А то получается - в таблице 1 млн. Набрали "И" сервер прошуршал все отбирая 50000 записей. Набрали "В" прошуршал опять отбирая 2500 записей начинающихся на "ИВ", набрали "A" еще 200 записей отбираем - но для пользователя 200 тоже много - поехали в 4 раз на сервер

← →
YurikGL © (2005-01-04 11:16) [11]

> Sergey_Masloff (04.01.05 11:08) [10]

дык это все понятно... :-)
Все же интересует, как реализовать то, что хочется? Через db-компоненты?

← →
msguns © (2005-01-04 11:16) [12]

>YurikGL © (04.01.05 11:04) [8]
>Я хочу через DB-компоненты реализовать. В т.ч. в целях самообучения.

Дело, конечно, хозяйское. Но надо учитывать прежде всего концепцию приложения: если это локальное приложение, расчитанное для удобного и быстрого обслуживания одного пользователя одной БД, то DB-Aware вполне "рулят". Если же ориентация на клиент-сервер (акцесс вообще-то имеет именну такую идеологию, хотя и не без ограничений и неудобств), то надо приложение ориентировать на "пакетные" апдейты, когда запись (записи) обновляются "на клиенте", а затем "пачкой" отправляются на сервер. В этом случае все DB-Aware контролы есть всего-навсего фикция, по сути скрывающая от разработчика логику обмена с БД. И от них лучше вообще отказаться в пользу более прозрачных и простых алгоритмов доступа к БД.

>YurikGL © (04.01.05 11:05) [9]
>У нас 40 человек и делать отдельную форму с глобальным поиском не актуально.

В случае именно этого справочника в контексте именно этого приложения, работающего именно с этой БД, возможно.
А как быть с другим справочником ? Или с другим приложением ? Не лучше ли один раз потрудиться и создать универсальный класс (форму, фрэйм и т.д.), который будет содержать в себе кучу полезных фичей и который можно будет юзать на любых справочниках в любых задачах и любых БД ?
Хотя, все опять же ИМХО ;)

> msguns © (04.01.05 11:16) [12]

Это - локальное приложение, которое я пишу под конкретного человека.
Учет входящих телефонных звонков, что-бы девочка, сидящая за телефоном не в екселе набирала каждый звонок, а потом вручную составляла отчеты. Количесво сотрудников - около 40-ка.

Т.е. учет КОМУ звонили ? А КТО и ЗАЧЕМ - по барабану ? Странный учет однако. И вопрос: а почему нельзя а екслеле-то ? Там тож можно забабахать справочник. И отчеты там можно получать автоматически. Либо просто ссылками, либо макросом.

> msguns © (04.01.05 11:31) [14]

Кто и зачем - тоже есть поля. Но выделять их в отдельную таблицу не вижу смысла. Проще заполнять через DISTINCT.

А в екселе почему не хочу - потому что я его знаю фигово, а с вопросами ко мне пойдут. Фильтры, автофильтры всякие.... мне проще новый документ в екселе сгенерировать :-)

>YurikGL © (04.01.05 11:36) [15]

Странный у тя подход: первичны инструменты, а потом уже цели. Вообще-то надо бы наоборот. Ну, тебе из погреба виднее.

Автоподстановка из родительской таблицы Найти похожие ветки