master-detail

← →
Xmen (2005-07-04 09:59) [0]

Привет всем!!!
Вот хотел сделать связь master-detail, вроде бы получилось связь установлен и когда ввожу данные то все ОК но когда хотел сохранить данные даёт ошибку "violation of foregn key constraint "FK_DATA2" on table "DATA2".
Кто небуд сталкивался с такой проблемой?
Для того чтобы был понятнее могу выслать код с базой. Вчера с утра до вечера посидел решая эту проблему, но никак не вышло. Как можно сделат связь правилно. Если можно дайти простой пример. В хелпах Делфи покапался, но непонял.

← →
Johnmen © (2005-07-04 10:05) [1]

Если уж и в хелпах не понял, то давание простого примера не поможет...:)

← →
Stakan © (2005-07-04 10:10) [2]

В подчинённой таблице в поле, по которому связь с родительской, должно быть значение поля из родительской таблицы (то поле, которое указано во внешнем ключе).
Например:
ALTER TABLE DATA1 ADD CONSTRAINT FK_DATA2 FOREIGN KEY (DATA2_ID) REFERENCES DATA2 (ID)
Это значит, что в таблице DATA1 в поле DATA2_ID должно быть значение из поля ID таблицы DATA2

← →
Xmen (2005-07-04 11:28) [3]

2Johnmen © (04.07.05 10:05) [1]

Если уж и в хелпах не понял, то давание простого примера не поможет...:)
Проста в ..DB\IBX\.. примеры сложные на первы раз(может для меня). Поэтому нужен простой пример.

2Stakan ©
у меня база такая:
CREATE TABLE MAIN (
ID INTEGER,
ZNACH1 INTEGER,
ZNACH2 VARCHAR(10)
);
ALTER TABLE MAIN ADD CONSTRAINT PK_MAIN PRIMARY KEY (ID);

CREATE TABLE DATA1 (
DATA1_ID INTEGER,
ZNACH1 INTEGER,
ZNACH2 VARCHAR(10)
);

ALTER TABLE DATA1 ADD CONSTRAINT FK_DATA1 FOREIGN KEY (DATA1_ID) REFERENCES MAIN (ID) ON DELETE CASCADE ON UPDATE CASCADE;

Может в проге ошибка, может посмотрите код?

← →
Digitman © (2005-07-04 11:31) [4]

> Кто небуд сталкивался с такой проблемой?

Кто Небуд - он точно сталкивался.
Он с чем только не сталкивался

← →
Ярослав (2005-07-04 11:33) [5]

А когда вносишь запись в подчиненную таблицу, ID главной ей не забываешь присваивать?

← →
Stakan © (2005-07-04 11:33) [6]

Xmen (04.07.05 11:28) [3]
А почему в таблице DATA1 нет первичного ключа?
И зачем on update cascade? Ты что собираешся менять перв. ключ в MAIN?

← →
Ярослав (2005-07-04 11:35) [7]

>> Stakan © (04.07.05 11:33) [6]
??? Причем тут это?

← →
Stakan © (2005-07-04 11:39) [8]

Ярослав (04.07.05 11:35) [7]
Это я не про ошибку, а вообще.
Про ошибку я уже сказал, очевидно, что при добавлении в табл. DATA1, DATA1_ID не совпадает ни с одним ID из табл. MAIN

← →
Xmen (2005-07-04 11:52) [9]

2Ярослав (04.07.05 11:33) [5]

А когда вносишь запись в подчиненную таблицу, ID главной ей не забываешь присваивать?

В проги для этого делаю
procedure TForm1.qrData1NewRecord(DataSet: TDataSet);
begin
qrData1["Data1_id"]:=qrMain["id"];
end;

← →
Ярослав (2005-07-04 11:53) [10]

>> Stakan © (04.07.05 11:39) [8]
Ну тогда понятно

← →
Anatoly Podgoretsky © (2005-07-04 11:54) [11]

Stakan © (04.07.05 11:33) [6]
Что тебя так сильно испугало?

← →
Stakan © (2005-07-04 11:58) [12]

Anatoly Podgoretsky © (04.07.05 11:54) [11]
ИМХО не стоит так делать.

← →
Ярослав (2005-07-04 12:08) [13]

>> Xmen (04.07.05 11:52) [9]
Интересно в определении таблиц у тебя ни слова о DATA2 а в ошибке
violation of foregn key constraint "FK_DATA2" on table "DATA2"
в общем какую то DATE2 таблицу упоминает...
Может ты чего то не договариваешь?

← →
Anatoly Podgoretsky © (2005-07-04 12:26) [14]

Stakan © (04.07.05 11:58) [12]
То есть только твои личные неприязни, сущность оказывается не при чем.

← →
Stakan © (2005-07-04 12:44) [15]

Anatoly Podgoretsky © (04.07.05 12:26) [14]
Как мне кажется все на этом форуме высказывают лишь собственное мнение, на абсолютную истину никто не претендует. Что касается данного случая, то аргументы в поддержку моего мнения очевидны - неуникальность данных в подчинённой таблице, что противоречит теории РСУБД.

← →
Хьут (2005-07-04 12:49) [16]

Удалено модератором

← →
Xmen (2005-07-04 12:49) [17]

2Ярослав (04.07.05 12:08) [13]
У меня вобшета 3 таблицы, я проста не упоменул 3ю иза того что он таже похож на 2го
CREATE TABLE DATA2 (
DATA2_ID INTEGER,
ZNACH1 INTEGER,
ZNACH2 VARCHAR(10)
);

ALTER TABLE DATA2 ADD CONSTRAINT FK_DATA2 FOREIGN KEY (DATA2_ID) REFERENCES MAIN (ID) ON DELETE CASCADE ON UPDATE CASCADE;

2Anatoly Podgoretsky ©
Я вам в суботу отправил через маил письмо с кодом. Но не получил ответа. Если можно ответти пожалуста.

← →
Anatoly Podgoretsky © (2005-07-04 13:12) [18]

Xmen (04.07.05 12:49) [17]
Поддержка по электронной почте не обеспечивается и не акредитированя почта не принимается, а ответы я даю только в конференциях, при наличии желания.

← →
Anatoly Podgoretsky © (2005-07-04 13:15) [19]

Stakan © (04.07.05 12:44) [15]
Ты не высказывал мнения, а только религиозное убеждение - догмат веры.

Насчет уникальности - это где же ты видел не уникальные первичные ключи? Что за база такая странная?

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

← →
Ярослав (2005-07-04 13:19) [20]

>> Xmen (04.07.05 12:49) [17]
Ну вот ты и проверь в каком обработчике добавления новой записи, кокой из таблиц ты ID главной присваеваешь а то если при вставке в DATA2 ты делаешь qrData1["Data1_id"]:=qrMain["id"]; т.е. также как и при вставке в DATA1 то это мало чем поможет
Так же qrData1 вовсе не означает что ты вставляешь в DATA1
проверь SQL qrData1 и наверное qrData2 если он у тебя есть

← →
Stakan © (2005-07-04 13:32) [21]

Anatoly Podgoretsky © (04.07.05 13:15) [19]

> Ты не высказывал мнения, а только религиозное
> убеждение - догмат веры

При чём здесь религия, я как раз высказал мнение.

> Насчет уникальности - это где же ты видел не
> уникальные первичные ключи? Что за база такая странная?

Я как раз и сказал см. [6], что в таблице DATA1 отсутствует первичный ключ, что может привести к неуникальности значений в этой таблице.

> Данная настройка позволяет сохранить ссылочную
> целостность в случае изменения поля связи и это ее
> назначение, такая возможность есть во всех серверах и
> требуется стандартов.

Согласен, но я считаю что поле ID таблицы MAIN изменять не стоит, так как это первичный ключ.

← →
Anatoly Podgoretsky © (2005-07-04 13:54) [22]

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

Anatoly Podgoretsky © (04.07.05 13:54) [22]
Согласен с Вами, могу лишь заметить, что я ни на чём не настаивал, а лишь высказывал своё скромное мнение о том, что следует избегать по возможности изменения первичного ключа.

← →
Xmen (2005-07-04 14:34) [25]

ID поле таблицы MAIN первычный ключ, и он создаётся генератором, тоесть автоинкременант.
А разве нужно установит в других таблицах первычный ключ, и это как повляеет на событя. Я пробовал ставить первычные ключа к другим таблицам, но в моём случае нечего не изменил. Я обчно работаю с базами и создаю их в проге ИБЭкспрес, ключи тоже внем создавал, по моему внем недолжен быт ошибка.

2Ярослав (04.07.05 13:19) [20]
Обесни еще попроше, если вопросы есть на уточнения то задавай.

← →
Ярослав (2005-07-05 06:27) [26]

>> Xmen (04.07.05 14:34) [25]

Чем гадать кинь мне весь проект на мыло

Ярослав (05.07.05 06:27) [26]
Добрый Санта Клаус

← →
Ярослав (2005-07-05 09:13) [28]

>> Anatoly Podgoretsky © (05.07.05 08:56) [27]
Я то? А как же, надо же людям помогать иногда, просто мне так легче чем допытываться из человека что там у него не так

Ярослав (05.07.05 09:13) [28]
Ты это называешь помощью :-)

← →
Ярослав (2005-07-05 09:32) [30]

>> Anatoly Podgoretsky © (05.07.05 09:21) [29]
Я конечно понимаю что гораздо лучше когда человек сам добиваеться цели, но все же иногда можно и так

Я ему уже выслал исправленный и работающий исходник.
Сильно не судите, человек только начинает вникать в суть, надо помочь с азами

master-detail Найти похожие ветки