Здравствуйте!
Есть проблема:
используется FIB-FB 1.5.1
2 таблицы:
CREATE TABLE PERSON (
ID_HUMAN DNKEY ,
DATEEND DATE NOT NULL,
DATEBEGIN DATE NOT NULL,
... some other fields
);
ALTER TABLE PERSON ADD PRIMARY KEY (ID_HUMAN, DATEBEGIN, DATEEND);
=============
CREATE TABLE ABITURIENT (
ID_HUMAN DNKEY ,
DATEBEGIN DATE NOT NULL,
DATEEND DATE NOT NULL,
ID_ABITURIENT DNKEY
);
ALTER TABLE ABITURIENT ADD PRIMARY KEY (ID_ABITURIENT);
ALTER TABLE ABITURIENT ADD FOREIGN KEY (ID_HUMAN, DATEBEGIN, DATEEND)
REFERENCES PERSON (ID_HUMAN, DATEBEGIN, DATEEND);
datasetPerson - master, datasetAbiturient - detail
На сервере (RemoteDataModule) 2 TpFIBDataSet'a связаны через DataSource.
У datasetAbiturient в Select стоит
WHERE ID_HUMAN=:ID_HUMAN and DATEBEGIN=:DATEBEGIN and DATEEND=:DATEEND
у datasetAbiturient в AutoUpdateOptions выставлен генератор на поле
ID_ABITURIENT.
На клиенте 2 pFIBClientDataSet'a также связаны через MasterSource.
Теперь, если в MasterDBGrid попытаться встать на строку, отличную от первой
и для которой в detail _ничего нет_, то происходит ошибка "Key Violation".
Если на сервере обнулить AutoUpdateOptions, то ошибки нет!
Где копать?
Всего доброго,
Антон
master-detail on DataSnap
Модератор: kdv
Их смысл - период действия записи.
Например, человек поступает (либо пытается) во второй (третий,..) раз. Вынеся date за ключ, id будет разный, т.е. по сути это разные люди. а так, человек всегда один, и можно проследить историю.
Почему date не в abituriente, потому что на person завязано много других таблиц, в которых тоже имеет роль период действия
Например, человек поступает (либо пытается) во второй (третий,..) раз. Вынеся date за ключ, id будет разный, т.е. по сути это разные люди. а так, человек всегда один, и можно проследить историю.
Почему date не в abituriente, потому что на person завязано много других таблиц, в которых тоже имеет роль период действия
Дык всё просто - родился-умер, потом опять родился, опять умер, потом... Я сам аж четыре предыдущих жизни помню 
На самом деле - ошибка, которой я тоже в начале работы с SQL грешил. Типа по первому сегменту искать буду, по второму или третьему сортировать. Такие индексы на самом деле были весьма удобны при работе с BTrieve из DOS-овских приложений. Берёшь первую запись по сегменту ID индекса и начинаешь некстить по индексу же пока не найдёшь нужную или просто гнать на экран как бы в сортировке. А в SQL от таких индексов никакой пользы акромя вреда - дубликаты не контролируются, FK на такой PK это просто курам на смех, условия на непервые сегменты всё равно пойдут натуралом, при сортировке по ним индекс использоваться не будет... В общем, отвыкать надо от навигационно-индексных замашек.
На самом деле - ошибка, которой я тоже в начале работы с SQL грешил. Типа по первому сегменту искать буду, по второму или третьему сортировать. Такие индексы на самом деле были весьма удобны при работе с BTrieve из DOS-овских приложений. Берёшь первую запись по сегменту ID индекса и начинаешь некстить по индексу же пока не найдёшь нужную или просто гнать на экран как бы в сортировке. А в SQL от таких индексов никакой пользы акромя вреда - дубликаты не контролируются, FK на такой PK это просто курам на смех, условия на непервые сегменты всё равно пойдут натуралом, при сортировке по ним индекс использоваться не будет... В общем, отвыкать надо от навигационно-индексных замашек.Не надо смешивать сущности. Человек один? Один. Вот и запись о нём в таблице Человеков с атрибутикой человека должна быть одна. А пытаться поступать он может раз двадцать. И записи об этом, следственно, должны быть в таблице Попыток с атрибутами попыток, растущей как 1:n от таблицы Человеков.atg писал(а):Их смысл - период действия записи.
Например, человек поступает (либо пытается) во второй (третий,..) раз. Вынеся date за ключ, id будет разный, т.е. по сути это разные люди. а так, человек всегда один, и можно проследить историю.
Почему date не в abituriente, потому что на person завязано много других таблиц, в которых тоже имеет роль период действия
и причем, если на человека 1 попытка 1 раз в год, то тогда надо ПК как
DBEGIN INT
IDPERSON INT
то есть, год 4-мя цифрами, а не дату. А дальше уже конкретную дату приема документов, например, и т.д. и дата это просто атрибут, никак данную персону или попытку поступления не идентифицирующей.
В общем, ушли от темы, занявшись просветительством по поводу проектирования БД
DBEGIN INT
IDPERSON INT
то есть, год 4-мя цифрами, а не дату. А дальше уже конкретную дату приема документов, например, и т.д. и дата это просто атрибут, никак данную персону или попытку поступления не идентифицирующей.
В общем, ушли от темы, занявшись просветительством по поводу проектирования БД
А по теме и сказать-то нечегоkdv писал(а): В общем, ушли от темы, занявшись просветительством по поводу проектирования БД
Не знаю насчёт нонешнего Датаснапа, а в его предшественнике Мидасе вокруг мастер-деталей и обновлений такого навертели, пытаясь притянуть за уши клиент-серверную идеологию, да столько ошибок при этом напороли, что я на их потуги плюнул и построил свою технологию и для того и для другого.