Поля синхронного просмотра

← →
теркин © (2012-04-05 17:41) [0]

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

← →
CRLF (2012-04-05 17:45) [1]

что ещё за "таблицы"? два набора данных, связанных отношением "мастер-деталь"? что такое "поле синхронного просмотра"?

← →
теркин © (2012-04-05 18:02) [2]

> что такое "поле синхронного просмотра"?

Lookup поле, поля со свойствами
property LookupDataSet, LookupResultField, LookupKeyFields, KeyFields.
А описание

> "таблицы"

> "мастер-деталь"

взяты из книги Программирование в Delphi7 авторы Дарахвелидзе, Марков. Пардон профессионального сленга не знаю.

← →
Ega23 © (2012-04-05 18:05) [3]

Никто не гарантирует, что в подчинённой таблице есть записи для каждой записи из главной.
Более того, никто не гарантирует того, что в подчинённой таблице вообще есть хотя бы одна запись.

← →
CRLF (2012-04-05 18:10) [4]

> взяты из книги Программирование в Delphi7 авторы Дарахвелидзе,
> Марков
Как русскоязычный справочник книжка неплоха, как учебник -- лютый трындец. Найди лучше Фаронова, а лучше Тейксейру и Пачеко.

← →
теркин © (2012-04-05 18:12) [5]

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

← →
теркин © (2012-04-05 18:15) [6]

> Как русскоязычный справочник книжка неплоха, как учебник
> -- лютый трындец. Найди лучше Фаронова, а лучше Тейксейру
> и Пачеко

На счет Дарахвелидзе - точно подмечено. В основном использую Шумакова Фаронова Delphi5 Руководство разработчика базы данных.

← →
pavel_guzhanov © (2012-04-05 18:17) [7]

Расскажи структуру таблиц (поля, и по каким полям они связаны). Приведи пример данных в одной таблице и в другой. И на примере данных объясни, что надо получить в результате.

← →
теркин © (2012-04-05 18:35) [8]

Индексы ведущей таблицы

dmyhastok.TYhastok.IndexFieldNames:="";
dmyhastok.TYhastok.MasterFields:="";
dmyhastok.TYhastok.MasterSource:=dmkoteln.DSKoteln;
dmyhastok.TYhastok.MasterFields:="ID_Koteln";
dmyhastok.TYhastok.IndexFieldNames:="ID_Koteln;Tip;PotrebNomer";

Индексы ведомой таблицы
dmpotreb.TPotreb.MasterFields:=""; dmpotreb.TPotreb.MasterSource:=dmyhastok.DSYhastok; dmpotreb.TPotreb.MasterFields:="ID_Koteln;PotrebNomer"; dmpotreb.TPotreb.IndexFieldNames:="ID_Koteln;ID";
Создаются динамически в зависимости от того какая таблица открывается в отдельной форме. Ведущий ведомый могут меняется местами.
Ведущая таблица
type TDMYhastok = class(TDataModule) DSYhastok: TDataSource; TYhastok: TTable; TYhastokID_Koteln: TIntegerField;{Главный индекс для двух таблиц} TYhastokID: TStringField;{ID записи} TYhastokTip: TStringField; TYhastokYzel1_TipTryb: TIntegerField; TYhastokYzel1_Nomer: TIntegerField; TYhastokYzel2_TipTryb: TIntegerField; TYhastokYzel2_Nomer: TIntegerField; TYhastokID_Diametr: TIntegerField; TYhastokG: TFloatField; TYhastokL: TFloatField; TYhastokKekv: TFloatField; TYhastokSummSopr: TFloatField; TYhastokEDS: TFloatField; TYhastokHist: TFloatField; TYhastokPrimehanie: TMemoField; TYhastokPotrebNomer: TIntegerField;{индекс для связи с дочерней таблицы} TYhastokYzel1TipTrybObozn: TStringField; TYhastokYzel2TipTrybObozn: TStringField; TYhastokYzel1Temper: TFloatField; TYhastokYzel1Geo: TFloatField; TYhastokYzel1Napor: TFloatField; TYhastokYzel2Temper: TFloatField; TYhastokYzel2Geo: TFloatField; TYhastokYzel2Napor: TFloatField; TYhastokDvn: TFloatField; TYhastokID_TempNaporPotreb: TIntegerField; TYhastokSposobPrisoed: TStringField; TYhastokID_TempNapGWS: TIntegerField; TYhastokPrisoedGWS: TStringField; TYhastokTemNaporOtVen: TFloatField; TYhastokTemNaporGWS: TFloatField; TYhastokNeravnGWS: TFloatField; TYhastokGWSShemaVkl: TStringField; TYhastokID_TempNapSistema: TStringField; TYhastoktgwsgor: TFloatField; TYhastoktgwshol: TFloatField; TYhastokt2izl: TFloatField; TYhastokt1izl: TFloatField; TYhastokSkorost: TFloatField; TYhastokRe: TFloatField; TYhastokGidrotrenie: TFloatField; TYhastokHlin: TFloatField; TYhastokHmes: TFloatField; TYhastokHyh: TFloatField; TYhastokSy: TFloatField; TYhastokID_TempNapTexn: TIntegerField; TYhastokTempNapTex: TFloatField; TYhastokPrisoedTexn: TStringField; TYhastokTizlGWS: TFloatField; TYhastokGexit: TFloatField; TYhastokHdrosel: TFloatField; TDiametrID_Diametr: TAutoIncField; TDiametrGost: TStringField; TDiametrDy: TFloatField; TDiametrDn: TFloatField; TDiametrDvn: TFloatField; TDiametrTolshina: TFloatField; TDiametrQ_5PodBezk95: TFloatField; TDiametrQ_5PodBezk70: TFloatField; TDiametrQ_5PodKanl95: TFloatField; TDiametrQ_5PodKanl70: TFloatField; TDiametrQ_5Nadzem95: TFloatField; TDiametrQ_5Nadzem70: TFloatField; TYhastokProkladka: TStringField; TYhastokQnorm: TFloatField; TYhastokDopQ: TFloatField; TYhastokdT: TFloatField; TYhastokTistok: TFloatField; TYhastokPloshad: TFloatField; TYhastokObem: TFloatField; TYhastokGpodp: TFloatField; TYhastokQpodp: TFloatField; TYhastokNameTemperNaporSistema: TStringField; TYhastokTemperNaporSistema: TFloatField; TYhastokKletn: TFloatField; TYhastokGWSTempNapLetn: TFloatField; TYhastokQyhast: TFloatField; TYhastokRnorm: TFloatField; TYhastokDot: TFloatField; TYhastokPotrebH: TFloatField; .....
Это все поля ведущей таблицы, процедуры отсутствуют их реально много
Ведомая таблица
TDMPotreb = class(TDataModule) DSPotreb: TDataSource; TPotreb: TTable; TPotrebID_Koteln: TIntegerField;{Главный индекс для двух таблиц} TPotrebID: TIntegerField;{ID дочерней таблицы- связь с ведущей} TPotrebName: TStringField; TPotrebAdres: TStringField; TPotrebYzelPodkl: TMemoField; TPotrebData: TDateField; TPotrebV: TFloatField; TPotrebVisota: TFloatField; TPotrebGeo: TFloatField; TPotrebGVS: TFloatField; TPotrebPrisoedOtop: TStringField; TPotrebPrisoedVent: TStringField; TPotrebPrisoedGVS: TStringField; TPotrebPrisoedTehn: TStringField; TPotrebQo: TFloatField; TPotrebQv: TFloatField; TPotrebQg: TFloatField; TPotrebQt: TFloatField; TPotrebSumQ: TFloatField; TPotrebPrimehanie: TMemoField; TPotrebTipYhastok: TStringField; TPotrebNamePotreb: TStringField; TPotrebGo: TFloatField; TPotrebGv: TFloatField; TPotrebGg: TFloatField; TPotrebGt: TFloatField; TPotrebSumG: TFloatField;
Обе таблицы являются дочерними таблицами другой таблицы. У этих двух таблиц имеется одна общая дочка. Структура очень сложная.

← →
Jeer © (2012-04-05 20:57) [9]

> Структура очень сложная.

Значит ошибочная.

← →
теркин © (2012-04-05 22:33) [10]

Ну как ошибочная, если рабочая, каков реальный объект такова и база данных, что тут еще можно сказать. Пробовал упростить ну никак не получается, чем дальше тем сложнее.

← →
Ega23 © (2012-04-06 10:49) [11]

> Ну как ошибочная, если рабочая

Одно не следует из другого.

> каков реальный объект такова и база данных

Просмотрел список полей бегло. Есть очень сильные подозрения, что:
1. База не нормализована.
2. Наследованием ты не захотел пользоваться (не знаешь что это такое).

> чем дальше тем сложнее.

Если база нормализована, то нет. А вот если в кучу всё, тогда да, в геометрической прогрессии сложность возрастает.

Судя по названию полей - это проект гидравлической разводки по котельным и потребителям.
Это однозначно сетевая структура и сначала надо решить ее в терминах графов и объектов, только затем попытаться переложить на реляционную структуру БД.

> ... значения поля
> в главной таблице переходят из зависимой "неустойчиво" ...

Что значит "неустойчиво" ?

К тому же Вы сами себе противоречите в первом Вы сказали что:

> Имеются две связанные таблицы в отношении один ко многим

А потом уточняете:

> Ведущий ведомый могут меняется местами.

можно предположить, что
> Jeer ©

прав, сказав, что

> Это однозначно сетевая структура..

и тут отношение "многие ко многим".

А так же видя следующие строки исходника:

..
> TYhastok: TTable;
..

Могу Вам предложить послать подальше Lookup поля
и использовать TQuery. Причем формировать запрос динамически от того кто в конкретной ситуации ведущий, а кто ведомый.
т.е. например
select a.* from tableA a left join tableB b on b.idSviaz=a.id
и дальше в соответствии с логикой программы и выбором пользователя, менять запрос на
select b.* from tableB b left join tableA a on a.idSviaz=b.id

Вообще, это очень плохо использовать TTable для такого рода операций. Т.к. таблица открыта на редактирование, а это чревато разрушением индексов, с последующим их перестроением и зачастую потерей данных, из-за незавершенных транзакций.

> т.е. например
> select a.* from tableA a left join tableB b on b.idSviaz=a.
> id
> и дальше в соответствии с логикой программы и выбором пользователя,
> менять запрос на
> select b.* from tableB b left join tableA a on a.idSviaz=b.
> id

Почему left, почему не inner?

> Вообще, это очень плохо использовать TTable для такого рода
> операций.

TTable вообще плохо использовать. Кстати, а с чего ты решил, что автор им пользуется?

> Ega23

> TTable вообще плохо использовать. Кстати, а с чего ты решил,
> что автор им пользуется?

ну дык , посмотрите пост

> теркин © (05.04.12 18:35) [8]

я же привел кусочек из его объявлений.

> Почему left, почему не inner?
>

Он же хочет менять отображение между родителем и подчиненным
т.е. типа А->B либо B->A
тут inner ну ни как... :)
тем более что если ему inner сделать, то он вообще запутается (ИМХО) :)

> Судя по названию полей - это проект гидравлической разводки
> по котельным и потребителям.
> Это однозначно сетевая структура и сначала надо решить ее
> в терминах графов и объектов....

Так точно это и есть сетевая структура графов тепловых сетей, и она переложена из графов в БД. Здесь многие программисты помогают решать отдельные задачи, что существенно повышает скорость программы и за это им больное спасибо, как говорится -"От глубины до слез".
Ega23 берут большие сомнения что необходима полная нормализация. Уже сейчас полное количество используемых наборов данных 54. Если её нормализовать полностью, то их количество наверно за 100 перевалит. Сложно выбрать что проще работать с 100 нормализованных таблиц или 54 "распухшими". У меня опыта нет никакого и судить о том какой путь проще очень сложно.

Поля синхронного просмотра Найти похожие ветки