| |
|
|
| | Нужна помощь в решении такой задачи:
Есть таблица в которой 1 столбец - перечень областей, 2 столбец - перечень городов
Нужно сделать форму в которой есть два поля со списком в 1 выберается область, а во втором в списке должны оказаться только те города которые в таблице принадлежат этой области.
Короче нужно иметь возможность выбора города только из конкретной области
Очень надо! (насколько я понимаю нужно сделать запрос на выборку - как?)
Заранее благодарю! | |
| |
| |
| |
 14 Кб. |
|
| | Тут на форуме масса примеров - если поискать то можно все найти
ну как вариант (не блещущий оригинальностью) - в прицепе => | |
| |
| |
| |
|
|
| | Пример меня полностью устроил, но самостоятельно повторить пока не удалось!
Разбираюсь с обработчиками событий! | |
| |
| |
| |
|
|
| | сложного ни чего нет
у комбобокса есть источник строк для списка ( свойство RowSource) - этим источником может служить таблица, сохраненный запрос или запрос написанный на SQL - последним и воспользуемся
кроме того есть событие После обновления (AfterUpdate) - Т.е. когда Вы делаете выбор в комбобоксе возникает это событие
Кроме того у формы (или подчиненной формы) есть свойство Источник записей (свойство RecordSource) - этим источником может служить таблица, сохраненный запрос или запрос написанный на SQL - последним утверждением и будем пользоваться
теперь при возникновении события После обновления комбобокса Область нужно изменить Источник строк комбобокса Город (запрос лежащий в основе источника строк меняется в зависимости от значения комбобокса) и меняется Источник записей подформы в зависимости от состояния комбобоксов (там функция специальная есть а вызов функции идет из события AfterUpdate каждого комбобокса)
вот вроде и весь принцип работы
могут быть частности - все зависит от типа полей применяемых для связи комбобокса числовые или текстовые (т.е. комбобокс может показывать одно - текст например, а передавать в таблу число) - тут надо конкретно смотреть и разбираться какой столбец присоединенный и какой отображается | |
| |
| |
| |
22 Кб. |
|
| | Принцип такой:
1. Создаешь 2 таблицы: Area, City.
2. Создаешь третью таблицу Area_City, которая будет связующей между таблицами Area, City.
3. На форме по событию AfterUpdate комбобокса, в котором указаны области, изменяешь источник данных комбобокса, в котором указаны города.
См. пример. | |
| |
| |
| |
|
|
| |
1. Создаешь 2 таблицы: Area, City.
2. Создаешь третью таблицу Area_City, которая будет связующей между таблицами Area, City.
|
Плохой совет. Достаточно одной таблицы. | |
| |
| |
|
|
|
|
| |
|
|
| | а работать с этой одной таблой как она же должна содеражать ссылки на справочники об ентом и грил чел.
вот он так создаст а потом у него будет Москва, Мсква, москва.
судя по его вопросу - начинает. так что совет считаю правильным. | |
| |
| |
| |
|
|
| |
вот он так создаст а потом у него будет Москва, Мсква, москва.
|
Справочники из нескольких таблиц не смогут предотвратить это. | |
| |
| |
| |
|
|
| | ключи и автоподстановка сможет, по крайней мере, предупредить :) | |
| |
| |
| |
|
|
| | оснобенно если на ввод новых названий дать доступ только одному челу  т.к. фантазии юзера и действа рученек блудливых яго нужно максимально пресекать | |
| |
| |
| |
|
|
| | а я создал справочник городов, районов, областей.... сам заполнил его руцями :)) согласно данным с Почты... и всё... никому больше не надо вводить ничего | |
| |
| |
| |
|
|
| | Радикальный метод, но не панацея.
Завтра, к примеру, Львов переименуют в Бендеровск. 
Или построят новую деревню "Нью Васюки".
Или объединят две деревни "Старые живопырки" и "Новые живопырки" в "Большие живопырки".
То есть вводить/изменять все равно придется.
Хорошо, если Магистр под боком, а если где-то пузо греет на лазурном берегу?  | |
| |
| |
| |
|
|
| |
Или объединят две деревни "Старые живопырки" и "Новые живопырки" в "Большие живопырки".
|
У нас это случается значительно чаще, чем это может показаться на первый взгляд.
По поводу одинаковых названий - таких названий полно. Деревень с названием углы, заречье и пр. полно в каждой области. Зачастую встречаются в одном районе деревни с одинаковым названием.
Так, что сделать защищенную систему можно только разрешением добавления записей путем считывания информации из официальных справочников Минстата.
В рФ - это называется, по-моему, КЛАДР, В РБ - это СОАТО.
Таким образом разбивать на несколько таблиц справочник населенных пунктов нецелесообразно. | |
| |
| |
|
|
|
|
| |
|
|
| | там Лукас раскрыл тему сисег :) | |
| |
| |
| |
|
|
| | Тут еще зависит от масштаба задачи:
Одно дело серверное решение уровня предприятия(холдинга), где все дОлжно быть по уму,
другое дело адресная книга одноклассников, где все лежит в плоской табличке в абсолютно ненормализованном виде. | |
| |
| |
|
|
| |
|
|
| |
Радикальный метод, но не панацея.
Завтра, к примеру, Львов переименуют в Бендеровск.
...
Хорошо, если Магистр под боком, а если где-то пузо греет на лазурном берегу?
|
[панацея]
Магистр, перед тем как уехать на лазурный берег греть пузо,
всегда оставляет на своем рабочем столе или на рабочем столе того, кто остается выполнять обязанности Магистра, ярлык к текстовому файлу с названием "Что делать, Достоевский"
тама все ходы записаны :)
Ваш случай конкретно к справочнику "Города и веси" не критичен :)
Одну-две записи можно исправить (в отдельном справочнике - дата переименования, IDOBJOLD, IDOBJNEW)
это правильный подход, я так щетаю 
[/панацея] | |
| |
| |
| |
|
|
| | "Что делать, Достоевский" |
Как в анекдоте про три конверта в сейфе начальника.
...тама все ходы записаны :) |
Абсолютно грамотный подход. | |
| |
| |
