Lookup или не lookup - вот в чём вопрос (программирующий Гамлет)

← →
31512 (2004-02-11 14:40) [0]

Проблема заключена в заставлении DBGrid работать так (или примерно так), как это сделано в Access. Итак есть на MS SQL Server 2000 база данных. В базе данных имеется несколько таблиц, связанных отношениями. Например пусть есть

таблица "Организации", с полями:
"Наименование организации" - ключевое поле (nvarchar(255)),
"Юридический адрес" (nvarchar(255)), и т.д. (атрибуты организации).
Вторая таблица "Регистрационные номера" с полями "Регистрационный номер" - ключевое поле (nvarchar(255)), "Наименование организации"(nvarchar(255)) - оно берётся из таблицы "Организации". Таблицы, естественно связаны отношением один-ко-многим Вот так:

Организации 1------------| Регистрационные номера
Наименование организации | Регистрационный номер
Юридический адрес |-->Наименование организации
ПолеX $ ПолеY
ПолеY ПолеZ
ПолеZ .
. .
. .
.
Значок $ заменяет значок бесконечности...

Первое: является ли поле [Регистрационные номера].[Наименование организации] lookup полем?

Ясно что что в нём хранятся значения ключевого поля таблицы Организации. Если бы в Организации ключевым полем был бы "Счётчик", то в Регистрационные номера].[Наименование организации] хранились бы соответсвующие значения это счётчика из таблицы Организации.

Второе: как заставить DBGrid поступать так же как это делает редактор в Access?.

Ведь Access формирует на клетке сетки Комбобокс, а из него выбираются значения поля подстановки ( не значения ключевого поля).

← →
VLAD-MAL (2004-02-11 14:45) [1]

TDBLookupComboBox

---------------
Интересно, у тебя что, у одной организации много рег. номеров может быть?

← →
Fiend (2004-02-11 14:45) [2]

самому надо анализировать таблицу и добавлять лукап поля. Ничего сложного. Я такое делал, тока для ФБ

← →
Anatoly Podgoretsky (2004-02-11 14:48) [3]

Это все таки один ко одному связь

← →
VLAD-MAL (2004-02-11 14:50) [4]

Ой, блин, чего это я?

Не TDBLookupComboBox, конечно же, а Lookup - поля!

← →
Shaman (2004-02-11 15:31) [5]

используй join в запросе

← →
31512 (2004-02-12 08:44) [6]

Для VLAD-MAL:
Да, много. Приведу пример:
Супермаркет "Рамстор" имеет регистрационный номер X как производитель товара, регистрационный номер Y как покупатель товара, регистрационный номер Z как перепродавец товара. Так очень удобно классифицировать организации. Могу дать детальные пояснения.

← →
31512 (2004-02-12 08:46) [7]

Для Anatoly Podgoretsky. Нет, один ко многим. Каждое предриятие может иметь несколько регистрационных номеров.

← →
Sergey13 (2004-02-12 09:04) [8]

to 31512 © (11.02.04 14:40)
Че то, сдается мне, ты напутал при проектировании, а решаешь проблему с гридом. Какое поле у тебя ПК?
>"Наименование организации" - ключевое поле (nvarchar(255))
А завтра название поменяли, и что? Все перелопачивать? Я уж не говорю про производительность такого ключа.

Регистрационные номера - их может быть сколько угодно, или все таки ограниченное количество? Есл второе, я бы прямо в первую таблицу вставил. Да и вообще, что организация является продавцом, покупателем или производителем, ИМХО, должно следовать из ОПЕРАЦИИ (продажи, покупки...). Иначе не исключены возможности записи продажи на покупателя и наоборот.

← →
31512 (2004-02-12 09:51) [9]

Для Sergey13!!!!
Для начала хочу сказать спасибо что откликнулся.
Ты не прав в корне.
Во-первых
Это пример, возможно, неудачный, на самом деле всё сложнее. Я лишь пытался облегчить понимание проблемы. Я не просил анализировать пример базы данных. Базу данных я давно сделал и к ней претензий нет. Она не имеет отношения к продавцам, покупетелям и т.д. Ещё раз, это просто пример, от балды...
Во-вторых
Забудь про 1С. Нет её. Просвоение регистрационного номера - это операция. Этому соответсвует целая кипа государственных докумунтов и сам номер не просто набор цифр. Тоже самое относится и к отмене регистрационного номера. Поясню: даже если организация исчезла с лица планеты, то регистрационный номер за неё всё равно остаётся. И его нельзя присвоить другой организации. Отмена регистрационного номера - операция (тоже с кипой документов).
В третьих
Вопрос прост: как заставить DBGrid работать так как это сделано в Access.

← →
Соловьев (2004-02-12 09:56) [10]

чтобы в сентке появилось выпадающий список - надо сделать новое поле Lookup и при редактировании автоматически будет список

← →
Sergey13 (2004-02-12 10:11) [11]

231512 © (12.02.04 09:51) [9]
>Ты не прав в корне.
1. Я прав всегда
2. Если я не прав см. п.1
8-)

>Это пример, возможно, неудачный
Да уж.

>Забудь про 1С
А что это?

>Первое: является ли поле [Регистрационные номера].[Наименование организации] lookup полем?
Как ты сделаешь в апликухе, так и будет. Сделаешь лукапом, будет им (но скорее не им а полем связи для лукапного поля, если я не запутался в твоих именах полей 8-). Вставишь в запрос, не будет лукапом.

>Второе: как заставить DBGrid поступать так же как это делает редактор в Access?.Ведь Access формирует на клетке сетки Комбобокс
Я уж не помню как в стандартном гриде (давно не юзал), в EhLib-овском вроде будет так же.

>Вопрос прост: как заставить DBGrid работать так как это сделано в Access.

Вот и изъяснялся бы попроще (не по Гамлетовски 8-) - как вделать в грид комбобокс. Было бы проще. ИМХО. А то ... ту би не ту би. Как в Аксес да на МS SQL. Нет у меня этого аксеса на МS SQL.
8-)

← →
31512 (2004-02-12 10:31) [12]

Для Sergey13
Просто хотелось упростить проблему. То есть вообще решить задачу, для любых баз данных MS SQL Server 2000. Блин, ну трудно объясняться на расстоянии.

← →
Плохиш (2004-02-12 10:41) [13]

> 31512 © (12.02.04 10:31) [12]

> Блин, ну трудно объясняться на расстоянии

Блин, ну ни фига себе, угрозы пошли.

← →
Sergey13 (2004-02-12 10:45) [14]

2 31512 © (12.02.04 10:31) [12]
>Просто хотелось упростить проблему
Упростил. 8-)

>То есть вообще решить задачу, для любых баз данных MS SQL Server 2000. Блин, ну трудно объясняться на расстоянии.

Ты, ИМХО, просто путаешь понятия БД и прикладной программы для БД - это две большие разницы. Если тебя волнует грид (т.е. приклада), то не за чем описывать свой сервер и ссылаться при этом на другую БД+средство разработки (аксес). Иными словами - правильно заданный вопрос - половина ответа.

ЗЫ: Будь попроще, и люди к тебе потянутся. 8-)

← →
stone (2004-02-12 10:46) [15]

> 31512 © (12.02.04 10:31)

Тип базы данных тут не имеет никакого значения, если мы говорим о клиентском приложении.

Я не понимаю одного - ветка открыта 11.02.04 14:40. Неужели почти за сутки трудно нажать F1 и набрать lookup fields?

← →
Плохиш (2004-02-12 10:52) [16]

>stone © (12.02.04 10:46) [15]

Если все будут F1 нажимать .... (c) ...

← →
31512 (2004-02-12 11:17) [17]

Для stone

lookup fields тут вообще не причём. [Регистрационные номера].[Наименование организации] не есть lookup field.

← →
Соловьев (2004-02-12 11:23) [18]

Второе: как заставить DBGrid поступать так же как это делает редактор в Access?.

А это о чем ты спрашивал?

← →
31512 (2004-02-12 11:27) [19]

Sergey13

Хорошо. Special for you, my dear. Ставлю проблему ребром. Есть БД вообще. Как переделать DBGrid, чтобы он работал как в Access.
Очевидно, что анализируя связи, он поступает так (или примерно так):
Смотрит входит ли поле в связь. Если да, то выясняет из какой таблицы берутся значения первичного ключа. Лупит на ячейке комбобокс. Туда заливает значения поля подстановки. А при выборе значения из комбобокса, в ячейку подставляет соотвествующий первичный ключ. При этом при запросе SELECT * FROM [Регистрационные номера] никаких комбобоксов не возникает.

← →
Соловьев (2004-02-12 11:30) [20]

кликаем дважды по компоненте и добавляем все поля а потом и новое - и ставим ему тип Lookup

← →
31512 (2004-02-12 11:33) [21]

Для Соловьев

Согласен. Но хотлелось бы всё делать автоматом. То есть снизить зависимость от базы данных до минимума.

← →
Sergey13 (2004-02-12 11:39) [22]

231512 © (12.02.04 11:27) [19]
>Special for you, my dear.
О как загнул. Круто. Кембридж небось кончал. 8-)

>Ставлю проблему ребром.
Через колено, если не сказать через....

>Есть БД вообще.
Согласен.

>Как переделать DBGrid, чтобы он работал как в Access.
А Делфа у тебя есть? Что ты все про аксес то...

>Очевидно, что анализируя связи, он поступает так (или примерно так):....
Ты шибко большого мнения о гриде.

>При этом при запросе SELECT * FROM [Регистрационные номера] никаких комбобоксов не возникает.
И не возникнет. Это не джин, чтоб из бутылки возникать. И уж никак не при селекте из регномеров.
К датасету по организациям добавь лукап-поле со ссылкой на регномера. Они (номера) появятся в гриде как комбобокс. Если все правильно сделаешь то это ВСЕ.

ЗЫ: Что то доставать меня начала эта ветка.

← →
Соловьев (2004-02-12 11:40) [23]

А может еще сделать так: запустить Делфи сказать в микрофон - хочу! - и F9 - и с принтера деньги уже полезли за поргу?
Автоматом не получится - просто в Ацесе это за тебя сделали, а тут надо самому ручками.

← →
Sergey13 (2004-02-12 11:52) [24]

← →
Sergey13 (2004-02-12 11:56) [25]

2 31512 © (12.02.04 11:33) [21]
>Но хотлелось бы всё делать автоматом. То есть снизить зависимость от базы данных до минимума.
Ты думаешь что данный способ работы (в гриде с лукапами в комбобоксах) самый оптимальный и крутой? Ты мягко говоря ошибаешься. Прикинь если возможно выбирать из 1000 значений, а не из 3(где это действительно удобно).

← →
31512 (2004-02-12 11:59) [26]

Для Sergey13
Нет. Для Кембриджа я мелко плаваю - попу видно.
От тебя кроме пустой болтовни я ничего не услышал, отсюда и скука твоя к ветке. Разумеется тривиальное решение помогло. Тупо, но работает. Это скучно, согласен: создай, укажи, подставь... Я не прошу от тебя указавыть решения. Ибо, возможно, оно мне не подойдёт, но может навести на орпеделённые мысли. Мне нужно от тебя обсуждение. И только-то. Например: Я бы сделал так и вот так. Пока я от тебя ничего не услышал. Все равно спасибо.

← →
Sandman25 (2004-02-12 12:08) [27]

[26] 31512 © (12.02.04 11:59)

Логически мысля...
Вы не хотите явно указывать, что данное поле является foreign key, значит, программа должна опеределять это сама. Как она может это определять? Либо через какой-нибудь DBExpress, либо явно завязываясь на системные таблицы конкретной СУБД (для MS SQL это sysobjects и т.д., если я не ошибаюсь).
После того, как определено, из какой-таблицы брать вторую часть "foreign key", нужно опеределить, какое поле использовать для отображение. Либо это будет поле с некоторым заранее известным индексом, либо это будет заранее известное имя. После полученя этой информации вставка ComboBox уже будет технической деталью.
Значит, можно написать потомка какого-нибудь TCustomDBGrid, который будет все это делать, либо при создании компонента, либо при открытии связанного DataSet, либо при первом клике на ячейке, либо вообще при явном вызове некоторого метода.

← →
31512 (2004-02-12 12:09) [28]

Для Соловьев

Ты описал мечту любого пользователя и программиста. Кстати, к этому всё и идёт.

← →
31512 (2004-02-12 12:14) [29]

для Sandman25

Дорогой мой! Ну хоть кто-то меня услышал! Спасибо огромное! Вместо пустой болтовни - конкретика. Только поправлю TCustomDBGrid - класс предок TDBGrid. Мыслю так же.

← →
31512 (2004-02-12 12:16) [30]

Sergey13
Разумеется предусмотрены специальные формы ввода. Фильтровать можно.

← →
Sandman25 (2004-02-12 12:19) [31]

← →
31512 (2004-02-13 09:10) [32]

Одно из решений (к сожалению не самых удачных) я здесь приведу. Цель этого возбудить процесс обсуждения.
Нет ничего проще:
На форму бухаем, например, TADOConnection, 2 TDataSource, 2 TADOQuery. Связаваем компоненты. В ADOQuery1.SQL пишем: select * from Организации. В ADOQuery2.SQL пишем: select * from [Регистрационные номера]. Для ADOQuery2 добавляем поля (в результате запроса) в редакторе полей. Там же создаём новое Lookup-поле, задаем для него все параметры. Для грида прописываем DataSource2. И вот имеем 2 поля со смыслом "Наименование организации". Подстановочное(созданное нами) и не очень(то которое родное). Добавляем все поля в грид для колонок. и убираем колонку, соответсвующую "родному" полю "Наименование организации". Всё.

На мой взгляд это глупое решение. Я на него посмотрел и решил задать вопрос в форум. Собственно с этого всё и началось.

Чего хотелось бы:

Некоторый класс(над ним я и работаю), который позволяет по заранее заданому подключению (TADOConnection) сформировать для грида (свойство DataSource) однозначное понимание того какие поля "подстановочные" (ковычки поставлены сознательно) а какие поля простые-смертные.

Надеюсь на обсуждение. Спасибо.

← →
не МС (2004-02-13 11:13) [33]

Удалено модератором
Примечание: Гуляй от сюда

Lookup или не lookup - вот в чём вопрос (программирующий Гамлет) Найти похожие ветки