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 - и с принтера деньги уже полезли за поргу?
Автоматом не получится - просто в Ацесе это за тебя сделали, а тут надо самому ручками.

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

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

[26] 31512 © (12.02.04 11:59)

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

Для Соловьев

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

для Sandman25

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

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

Одно из решений (к сожалению не самых удачных) я здесь приведу. Цель этого возбудить процесс обсуждения.
Нет ничего проще:
На форму бухаем, например, 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 - вот в чём вопрос (программирующий Гамлет) Найти похожие ветки