Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft Access Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 ФАК: Связанные списки  [new]
ё
Guest
Что такое связанные списки ?

Связанные списки, это 2-а (или более) контролов (элементов управления формы) Поле со списком/Список (Combobox/ListBox),
размещённых на одной (совершенно необязательно - можно и на разных) форме,
текущий список значений которых - зависит от выбора значения в одном (или более) списков, от которого он зависит

На чём строятся связанные списки ?

1. Структуры данных имеющие чётко выраженную иерархическую структуру:
Регион -< Город -< Улица (то, что в 1с, называется - подчинёнными справочниками)
2. таблицы-справочники/(измерения), связанные - многие-ко-многим/(через таблицу фактов). В основном - как фильтр (и с ньюансами в виде вариантов - 'ВСЕ', 'Не заданно'):
Группа -< УчебныйПлан >- Предмет
3. ?

Где применяются связанные списки ?

1. "Уточнение", уменьшение диапазона выбора, значения поля, при вводе новой записи
(имеется в виду, - при вводе адресса, id города выбирается только из списка тех id городов, для которых id региона/области - соответствует выбранному в связанном с ним, родительском списке)
2. Динамическая фильтрация в форме. (... ? )
3. ?

...по-поводу - "в каких формах можно использовать?"
- по-большому счёту - только в одиночных

- в случае табл./ленточной формы можно использовать:
или если прикреплённый и отображаемый столбец - один и тот же (что уже - само по себе - неверно - "прощай нормализация")
или - выводить в списке - все значения, но сортируя первыми (в начало списка) - те которые подходят под текущий id списка, от которого зависит данный список
типа так
SELECT Город.Город, Город.КодГорода, 1 as orderby
FROM Город
WHERE (Город.КодРегиона=[Forms]![Форма1]![Регион])
UNION
SELECT '-----------------------------', 0, 2
FROM MSysObjects
UNION
SELECT Город.Город, Город.КодГорода, 3
FROM Город
WHERE (Город.КодРегиона<>[Forms]![Форма1]![Регион])
ORDER BY orderby, Город;

Как сделать связанные списки ?

1. Иерархические списки

1.1. По ссылке в запросе-источнике списка, на элементы управления формы (по Гетцу)
+ минимум программирования в VBA
- не применимы в adp-проектах (? или можно как-то "прогнутся" ?)

В этом варианте, источник для каждого списка, задаётся при создании, - один раз,
и содержит в условии (where) фильтр по текущему значению, связанного с ним, родительского списка

Регион -< Город -< Улица

Регион:
SELECT Регион.Регион, Регион.КодРегиона
FROM Регион
ORDER BY Регион.Регион;

Город:
SELECT Город.Город, Город.КодГорода
FROM Город
WHERE (Город.КодРегиона=[Forms]![Форма1]![Регион])
ORDER BY Город.Город;

Улица:
SELECT Улица.Улица, Улица.КодУлицы
FROM Улица
WHERE (Улица.КодГорода=[Forms]![Форма1]![Город])
ORDER BY Улица.Улица

в коде, в событи "После обновления" соответствующих списков - выполняется обновлениее (Requery), зависимых от них списков
Private Sub Регион_AfterUpdate()
  Город = Null
  Улица = Null
  Город.Requery
End Sub

Private Sub Город_AfterUpdate()
  Улица = Null
  Улица.Requery
End Sub

зы.
прошу уважаемых рецензентов/авторов не стесняться с правкой
и считать это - не более чем план/эскиз


К сообщению приложен файл (1.1.zip - 87Kb) cкачать
6 июл 10, 18:19    [9059713]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
Владимир Саныч
Member

Откуда: Израиль (причем это 1 человек, а не 2 => прошу на ты)
Сообщений: 40414
Наверно, надо будет сделать какую-то реорганизацию оглавления факов, чтобы вся серия "как сделать" была вместе...
6 июл 10, 18:25    [9059757]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
garri2000
Member [заблокирован]

Откуда: Моск.обл,Ступино
Сообщений: 5069
+1
6 июл 10, 21:49    [9060614]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
Программист-Любитель
Member

Откуда:
Сообщений: 16851
Замечание ТС: Мне кажется, что логичнее иметь на форме имена контролов, строго совпадающие с баунд столбцами. Т.е. КодРегиона а не Регион и т.п. Также в случае показа наименования а хранения кода мне кажется удобнее иметь баунд столбец = 1 и ширину его = 0. Может быть это вкусовщина, но я бы сделал именно так.

Тем не менее, ниже приводится вариант, соответствующий первоначальным описаниям ТС.

1.2. Разновидность предыдущего варианта, одинакого работающая в MDB и в ADP проектах. Некоторые предпочитают его за бОльший контроль в момент сборки строк источников списка.

Регион -> Город -> Улица

Регион (без изменения):
SELECT Регион, КодРегиона
FROM Регион
ORDER BY Регион;

в коде, в событии "После обновления" соответствующих списков - выполняется обновление зависимых от них списков
Private Sub Регион_AfterUpdate()
  Город.RowSource = _
    "SELECT Город, КодГорода "
    "FROM Город " & _
    "WHERE КодРегиона=" & Nz(Me![Регион], -1) & " " & _
    "ORDER BY Город"
  Город_AfterUpdate
  Город = Null
End Sub

Private Sub Город_AfterUpdate()
  Улица.RowSource = _
    "SELECT Улица, КодУлицы " & _
    "FROM Улица " & _
    "WHERE КодГорода=" & Nz(Me![Город], -1) & " " & _ 
    "ORDER BY Улица"
  Улица = Null
End Sub
7 июл 10, 08:39    [9061643]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
mds_world
Member

Откуда: Ташкент
Сообщений: 27576
Для связанных списков важен момент "отката", когда в управляющем списке задается отсутствие выбора, например, "Все". Тогда нужно все зависимые списки вернуть в начальное положение без фильтров.
Я, для этих целей, держу исходное SQL-выражение в таге списка и, если в управляющем списке выбрано кодовое слово отсутствия фильтра (в общем случае может быть и NULL), приравниваю RowSource списка выражению из Tag.
7 июл 10, 09:28    [9061783]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
ё
Guest
Программист-Любитель
Замечание ТС: Мне кажется, что логичнее иметь на форме имена контролов, строго совпадающие с баунд столбцами. Т.е. КодРегиона а не Регион и т.п.
...

Замечание, безусловно, - правильное.
+
так, просто, было сделано в БД, на основе которой я делал
а исправлять, - поленился ))

Принимается.
Исправляю
+ ...по-поводу - "в каких формах ...

...по-поводу - "в каких формах можно использовать?"
- по-большому счёту - только в одиночных

- в случае табл./ленточной формы можно использовать:
или если прикреплённый и отображаемый столбец - один и тот же (что уже - само по себе - неверно - "прощай нормализация")
или - выводить в списке - все значения, но сортируя первыми (в начало списка) - те которые подходят под текущий id списка, от которого зависит данный список
типа так
SELECT Город.Город, Город.КодГорода, 1 as orderby
FROM Город
WHERE (Город.КодРегиона=[Forms]![Форма1]![КодРегиона])

UNION

SELECT '-----------------------------', 0, 2
FROM MSysObjects

UNION

SELECT Город.Город, Город.КодГорода, 3
FROM Город
WHERE (Город.КодРегиона<>[Forms]![Форма1]![КодРегиона])

ORDER BY orderby, Город;


+ 1.1. По ссылке в запросе-источнике списка...

1.1. По ссылке в запросе-источнике списка, на элементы управления формы (по Гетцу)
+ минимум программирования в VBA
- не применимы в adp-проектах (? или можно как-то "прогнутся" ?)

В этом варианте, источник для каждого списка, задаётся при создании, - один раз,
и содержит в условии (where) фильтр по текущему значению, связанного с ним, родительского списка

Регион -< Город -< Улица

КодРегиона:
SELECT Регион.Регион, Регион.КодРегиона
FROM Регион
ORDER BY Регион.Регион;

КодГорода:
SELECT Город.Город, Город.КодГорода
FROM Город
WHERE (Город.КодРегиона=[Forms]![Форма1]![КодРегиона])
ORDER BY Город.Город;

КодУлицы:
SELECT Улица.Улица, Улица.КодУлицы
FROM Улица
WHERE (Улица.КодГорода=[Forms]![Форма1]![КодГорода])
ORDER BY Улица.Улица

в коде, в событи "После обновления" соответствующих списков - выполняется обновлениее (Requery), зависимых от них списков
Private Sub КодРегиона_AfterUpdate()
  КодГорода = Null
  КодУлицы = Null
  КодГорода.Requery
End Sub

Private Sub КодГорода_AfterUpdate()
  КодУлицы = Null
  КодУлицы.Requery
End Sub


К сообщению приложен файл (1.1.zip - 94Kb) cкачать
7 июл 10, 12:24    [9063379]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
ё
Guest
Программист-Любитель

1.2. Разновидность предыдущего варианта, одинакого работающая в MDB и в ADP проектах. Некоторые предпочитают его за бОльший контроль в момент сборки строк источников списка.

с Вашего разрешения, с небольшими дополнениями

1.2. Динамическое переназначение источников строк (RowSource) зависимых списков в коде VBA

+ контроль сборки строк источников списка со стороны программиста позволяет оптимално составлять запрос-источник для зависимых списков (это правда больше не в иерархических, а в "многие-ко-многим", но всё же)
+ применимо и в MDB и в ADP проектах (причём код, при переезде с MDB на ADP - нужно изменять минимально - только в части условий по датам)
+ зависимые списки (все - кроме главного в иерархии), загружаются с пустым источником строк (RowSource) - соответственно загрузка всей формы - быстрее (мелочь - но приятно)
- как минимум - в код - прийдётся залезть. одними макросами - не обойдешся

Регион -> Город -> Улица

КодРегиона (без изменения):
SELECT Регион, КодРегиона
FROM Регион
ORDER BY Регион;

в коде, в событии "После обновления" соответствующих списков - выполняется обновление зависимых от них списков
Private Sub КодРегиона_AfterUpdate()
  КодГорода.RowSource = _
    "SELECT Город, КодГорода " & _
    "FROM Город " & _
    "WHERE КодРегиона=" & Nz(Me![КодРегиона], -1) & " " & _
    "ORDER BY Город"
  КодГорода_AfterUpdate
  КодГорода = Null
End Sub

Private Sub КодГорода_AfterUpdate()
  КодУлицы.RowSource = _
    "SELECT Улица, КодУлицы " & _
    "FROM Улица " & _
    "WHERE КодГорода=" & Nz(Me![КодГорода], -1) & " " & _
    "ORDER BY Улица"
  КодУлицы = Null
End Sub
прочтение следующего ФАКа - может весьма пригодится при выборе данного вида связанных списков

К сообщению приложен файл (1.2.zip - 26Kb) cкачать
7 июл 10, 12:29    [9063418]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
ы
Guest
Программист-Любитель
Замечание ТС: Мне кажется, что логичнее иметь на форме имена контролов, строго совпадающие с баунд столбцами.

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

тс
В этом варианте, источник для каждого списка, задаётся при создании, - один раз,
и содержит в условии (where) фильтр по текущему значению, связанного с ним, родительского списка

Регион -< Город -< Улица

Здесь надо отдельно выделить, что предлагаемый вариант будет коряво работать в ленточной и табличной форме. И предлагаю в примерах привести рабочее решение с комментариями, о том, как реализуются связанные списки в случае использования ленточных/табличных форм

П-Л
1.2. Разновидность предыдущего варианта, одинакого работающая в MDB и в ADP проектах. Некоторые предпочитают его за бОльший контроль в момент сборки строк источников списка.

И тут я бы попробовал, скажем, тоже в примерах, привести несколько вариантов реализации. Первый использованный ТС проще, и наверняка подойдет большому числу читающих фак. Единственное, надо сразу оговориться, в каких случаях он нерабочий. Второй, предложенный П-Л, имеет более широкую область применения, но чуть сложнее в реализации и понимании для новичков. И тоже, кстати, не работает в ленточных/табличных формах.

ТС
само по себе - неверно - "прощай нормализация

Про нормализацию лучше не упоминать совсем. Она не имеет отношения к предложенной теме фака, да кроме того, сказанное еще и неверно. Иногда в таких осмысленно и оправданно используется денормализация
7 июл 10, 12:45    [9063593]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
alvk
Member [заблокирован]

Откуда: Находка
Сообщений: 10974
ы
Программист-Любитель
Замечание ТС: Мне кажется, что логичнее иметь на форме имена контролов, строго совпадающие с баунд столбцами.

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


У меня есть две разные задачи(решения), у которых как раз прямо противоположно, в одном случае это как благо, в другом пришлось делать разные имена контролов и столбцов. Задачи абсолютно разные, повторюсь, но в обеих и то, и то очень удобно.
7 июл 10, 12:52    [9063652]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
Программист-Любитель
Member

Откуда:
Сообщений: 16851
автор
Мне кажется, это очень плохой совет. В факе про имена как раз рекомендуют давать разные имена контролам и полям рекордсорса. Выгода от использования одинаковых имен стремится к нулю, а неудобства, как то: неочевидность, к чему в данный момент идет обращение, к полю источника или к полю формы, налицо.


Имею в большом (огромном, гиганстском) проекте все формы, устроенные по таким правилам: имена контролов и имена полей в случае баундинга строго совпадают (одних на другие). Вкупе с достаточно строгой дисциплиной формирования имен полей в таблицах и запросах позволяет как раз избежать путанницы. Обращение к полю формы - Me.<Поле>. Все поля, надобные в коде, вытаскиваются на форму (если не нужно показывать - в скрытом виде).
Выгода от сквозной трассировки решения по цепочке форма - запрос - таблица налицо. Неудобств ни на лице, ни где-либо еще в упор не вижу.

автор
Иногда в таких осмысленно и оправданно используется денормализация
Ох в каком же подавляющем большинстве случаев она используется совершенно бессмысленно! Нарушать правила можно, сначала выучив их.
7 июл 10, 12:55    [9063677]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
ы
Guest
П-Л
Имею в большом

https://www.sql.ru/faq/faq_topic.aspx?fid=156
Будьте внимательны, если пользуетесь подобными сокращениями. В случае, когда форма содержит одноименные элементы различных коллекций, пропуск идентификатора коллекции может повлечь за собой неверную работу вашей программы (см. п. 3.6). Хороший способ избегать подобных "совпадений" - использовать префиксы в именах, например, поле "Поле1" в форме переименовать в "пфПоле1" и т.п

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

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

В подавляющем используется, правила надо учить. Но это топик про связанные списки. И не стоит замусоривать его большими не относящимися к нему темами. К тому же неправильно выраженными
7 июл 10, 13:15    [9063886]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
alvk
Member [заблокирован]

Откуда: Находка
Сообщений: 10974
ы,

ну так ёлки, можно написать, что "можете использовать совпадающие названия, а можете использовать разные"
7 июл 10, 13:19    [9063934]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
Владимир Саныч
Member

Откуда: Израиль (причем это 1 человек, а не 2 => прошу на ты)
Сообщений: 40414
Я думаю, про совпадение имен контролов и полей говорить в факе ничего не нужно, а в примерах эти имена должны быть разными, чтобы было понятнее, где что.
7 июл 10, 13:20    [9063937]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
alvk
Member [заблокирован]

Откуда: Находка
Сообщений: 10974
alvk,

вдогонку, новичкам бы я как раз посоветовал использовать совпадающие.
7 июл 10, 13:20    [9063946]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
ё
Guest
ы
Программист-Любитель
Замечание ТС: Мне кажется, что логичнее иметь на форме имена контролов, строго совпадающие с баунд столбцами.

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

глупости какие...
а чё ж сам Акс - так делает ?
да и на кой, может понадобится обращение к "полям рекордсорса" (я про это - Поле.Value - где кроме Value - ничего больше нет) - если есть связанный с этим полем контрол

ну а если сильно захочется обратится "к полю источника " - обратись явно - через рекордсет

зы.
ого! отошел на 10 мин. называется...,
но всё равно выскажусь
7 июл 10, 13:31    [9064086]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
ё
Guest
ы
...
тс
В этом варианте, источник для каждого списка, задаётся при создании, - один раз,
и содержит в условии (where) фильтр по текущему значению, связанного с ним, родительского списка

Регион -< Город -< Улица

Здесь надо отдельно выделить, что предлагаемый вариант будет коряво работать в ленточной и табличной форме. И предлагаю в примерах привести рабочее решение с комментариями, о том, как реализуются связанные списки в случае использования ленточных/табличных форм
...

...да пока - любой из предложенных вариантов - "будет коряво работать" в лент./таб. форме..
и в первом посте - я про это упоминал...

>> И предлагаю в примерах привести рабочее решение с комментариями, о том, как реализуются связанные списки в случае использования ленточных/табличных форм

предложение принимается!
приводи!
7 июл 10, 13:36    [9064147]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
ё
Guest
ы
...
ТС
само по себе - неверно - "прощай нормализация

Про нормализацию лучше не упоминать совсем. Она не имеет отношения к предложенной теме фака, да кроме того, сказанное еще и неверно. Иногда в таких осмысленно и оправданно используется денормализация


>> сказанное еще и неверно.

что не верно-то ??
вы поняли о чём речь ?

на пальцах

Регионы
Регион
Киевская


Города
Регион Город
Киевская Бровары
Киевская Борисполь


Улицы
Город Улица
Бровары Петрова
Бровары Водкина


вот это г. - будет "нормально" работать в таб./ленточной форме
это конечно - лучше чем "плоская таблица", но всё равно г. - остаётся г.
7 июл 10, 14:01    [9064392]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
ы
Guest
ё
да и на кой, может понадобится обращение к "полям рекордсорса"

Разве этот вопрос имеет отношение к выбранной теме фака? Есть другой фак, посвященный этому вопросу. В нем дан ответ, который противоречит написанному здесь. Так быть не должно. Какой смысл включать в ваш фак заведомо плохие советы?

ё
предложение принимается!
приводи!

Кто из нас факописатель? )

ё
на пальцах
...
вот это г. - будет "нормально" работать в таб./ленточной форме
это конечно - лучше чем "плоская таблица", но всё равно г. - остаётся г.

Не надо мне рассказывать всё, что вы знаете о нормализации. Очевидно, что вы знаете далеко не всё.
Почему это неверное выражение? Давайте приведу пример: "нельзя разводить змей". Это выражение неверное. Да, коль скоро вы будете разводить их дома, в конце концов одна из змей укусит вас, скажем, в палец. И вы можете умереть. Но несмотря на это, змей специально разводят для изготовления лекарств.
Здесь аналогично. Погуглите слово "денормализация"
7 июл 10, 14:20    [9064540]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
ё
Guest
ы
...
ё
предложение принимается!
приводи!

Кто из нас факописатель? )

...ну так - не знаю я НЕ "рвотных" "рабочих решений" для лент./таб. формы
поделитесь - я первый скажу "спасибо"

ы

Не надо мне рассказывать всё, что вы знаете о нормализации. Очевидно, что вы знаете далеко не всё.
...

...спасибо, что не в морду

пример со змеёй - г.
7 июл 10, 14:37    [9064680]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
Нервотная змея
Guest
ё
пример со змеёй - г.

Приведу пример с г.
7 июл 10, 14:40    [9064703]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
Программист-Любитель
Member

Откуда:
Сообщений: 16851
Для ленточных / табличных только трюк с отодвиганием вниз и занулением ("") расшифровок, которые не должны быть видны в ведомом списке при текущем значении ведущего.
7 июл 10, 14:45    [9064759]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
ы
Guest
Программист-Любитель
Для ленточных / табличных только трюк с отодвиганием вниз и занулением ("") расшифровок, которые не должны быть видны в ведомом списке при текущем значении ведущего.
Что имеется в виду? А то я не встречал на форуме этого способа.
ё
...ну так - не знаю я НЕ "рвотных" "рабочих решений" для лент./таб. формы
поделитесь - я первый скажу "спасибо"
Значит надо рефреном с начала фака написать: "автор не знает рабочего решения со связанными списками для ленточных и табличных форм" (не в том смысле, что автор недостаточно знающий, а подразумевая, то оно может всё-таки быть, недокументированное, или через танцы с бубнами, или эмулируя поведение полей со списками, или еще как, но здесь его привести не представляется возможным).
Я у в своих задачах делал посредством эмуляции поля со списком. Т.е. отображается значение, берущееся из приджойненной таблицы, а при попытке внести изменения в это поле над ним всплывает маленькая формочка, похожая на выпадающий список.
Но предлагать такое решение в фак... не думаю, что правильно. Оно нетривиальное, далеко не всем будет удобно + даже если попытаться притянуть функционал этой формы к оригинальному полю со списком, наверняка остануться отличия.
7 июл 10, 18:12    [9066700]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
ё
Guest
ы
Программист-Любитель
Для ленточных / табличных только трюк с отодвиганием вниз и занулением ("") расшифровок, которые не должны быть видны в ведомом списке при текущем значении ведущего.
Что имеется в виду? А то я не встречал на форуме этого способа.
...

это - это

К сообщению приложен файл. Размер - 0Kb
7 июл 10, 18:55    [9066981]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
ё
Guest
ё
это - это

+ чуть более продвинутый вариант
SELECT Улица.Улица, Улица.КодУлицы, Улица.Улица, 1 as orderby  
FROM Улица  
WHERE (((Улица.КодГорода)=[Forms]![Клиенты]![КодГорода]))    

UNION ALL   

select TOP 20 Null, Null, Null, 2 
from MSysObjects  

UNION ALL 

SELECT Улица.Улица, Улица.КодУлицы, "", 3 
FROM Улица  
WHERE (((Улица.КодГорода)<>[Forms]![Клиенты]![КодГорода]))

ORDER BY orderby, Улица;

но всё равно, такой вариант не даёт ни какой гарантии, что будет выбрана дочернее значение - соответствующее родительскому

поэтому без проверки в Before/AfterUpdate - использовать такое нельзя,
соответственно - вариант - из разряда...ну вы знаете
7 июл 10, 18:59    [9067001]     Ответить | Цитировать Сообщить модератору
 Re: ФАК: Связанные списки  [new]
ё
Guest
ы
...
ё
...ну так - не знаю я НЕ "рвотных" "рабочих решений" для лент./таб. формы
поделитесь - я первый скажу "спасибо"
Значит надо рефреном с начала фака написать: "автор не знает рабочего решения со связанными списками для ленточных и табличных форм"
...

...я, чесно говоря, думал, что написание ФАКа - дело коллективное,
и если я чего-то не знаю - старшие товарищи подскажут/дополнят...

...но раз так ставите вопрос
ё

автор не знает рабочего решения со связанными списками для ленточных и табличных форм,
которое стоило бы "безапеляционно" внести в ФАК
известные автору решения - имеют очевидную "кривизну" и/или сложность и не могут быть рекомендованны неподготовленному пользователю

подписался
7 июл 10, 19:10    [9067050]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Microsoft Access Ответить