Вообщем вопрос скорее теоретический: Может ли такое сделать Акцесс?
Таблицы
Т1 - каталог деталей
поля
Код_детали(счетчик уникальный), название_детали.

Т2 - Размеры деталей
Ключ(счетчик уникальный), Код_детали, размер_детали, название_детали.
У одной детали могут быть разные размеры, скажем труба определенного диаметра может быть длиной 1,5,10,100 м.
Получается что в Т2 записей с кодом скажем 1265 4 штуки.

Т3 - Материал деталей
Ключ(счетчик уникальный), Код_детали, материал_детали.
Одна и та же деталь может быть изготовлена из разных материалов, скажем труба определенного диаметра может быть изготовлена из стали, меди, пластика.
Получается что в Т3 записей с кодом скажем 1265 3 штуки.

Теперь надо сделать запрос который выдаст
все записи из таблицы Т3 и название детали из таблицы Т2 где код детали совпадает с кодом детали в Т3, а длина = 1 (т.е. из таблицы Т3 выбирается уже только одна запись на деталь).

Запрос такой я сделал, но я хочу менять название таблицы Т3 из этого запроса, а он гоаворит, что запрос не редактируемый. (Что-то там про рекордсет)

ВОПРОС: Можно ли сделать его редактируемым.

Это сообщение отредактировал(а) Bes - 16.3.2005, 11:36

А что делает название_детали а Таблице 2? и как оно соотносится с названием из Таблицы 1?

Они разные, скажем в Т1 название для покупателей а в Т2 спецмаркировка для завода.
Ммм.... не пытайтесь менять условие задачи, ведь вопрос именно теоретический,т.е. возможно это или нет, а не как проще сделать.
Да, наверное можно еще так сформулировать:
Можно ли сделать
Т1 left join Т2 on Т1.код=Т2.код where Т2.длина=1 что-то в этом роде только коды и там и там могут повторяться, но в Т2 они отсортированы условием длина = 1, а в этом случае коды в Т2 уже единственные. т.е. нет двух записей на одну деталь с длинной 1.
Дак как можно или нет сделать такой запрос обновляемым?

Это сообщение отредактировал(а) Bes - 16.3.2005, 13:33

Видишь ли, у тебя что-то бредовое...

Если у тебя (как выше) 4 размера и 3 материала, то существует 12 видов этих труб - так?

Теперь по сабжу - то что они у тебя в результате наложения условия стали "единственные" - частный случай. Который вообще не рассматривается. А без него у тебя имеет место неоднозначность, следовательно запрос в принципе не может быть обновляем (как и любое перемножение таблиц).
Обновляемым может быть только рекордсет, у которого для каждой таблицы с одной стороны - цепь "много к одному", а с другой - "один ко многим".

Да, да, я тоже так подумал, но для этого я и запихал в пример таблицу Т1 у которой поле кода уникальное, чтобы завязывать через нее эти таблицы. Ведь если сконструировать связи таким образом, Т2->T1<-T3 тогда получится как ты и сказал для каждой таблицы с одной стороны много к одному, а с другой один ко многим. Я так попробовал - все равно необновляемый получается.
Даже на два запроса разбивал - все равно не катит.

Цитата

Видишь ли, у тебя что-то бредовое...

Первый пример - который пришел в голову, чтобы описать задачу. Вопрос ведь теоретический.

Цитата

Если у тебя (как выше) 4 размера и 3 материала, то существует 12 видов этих труб - так?

Кол-во размеров и материалов для кждой трубы может быть различным.

Цитата(Bes @ 16.3.2005, 15:25)

Кол-во размеров и материалов для кждой трубы может быть различным

Значит структура БД ошибочна. Не обсуждается.

Цитата(Bes @ 16.3.2005, 15:25)

если сконструировать связи таким образом, Т2->T1<-T3 тогда получится как ты и сказал для каждой таблицы с одной стороны много к одному, а с другой один ко многим.

ну ты хоть ПОСМОТРИ, что ты сам нарисовал-то, ё моё!!! для каждой из таблиц условие НЕ выполняется. Для Т1 с обеих сторон один ко многим, для остальных с одной стороны ничего, а с другой по 1 типу каждого. Связи смотрятся не по соседу, а по ВСЕЙ схеме связей.

Цитата

Значит структура БД ошибочна. Не обсуждается

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

Цитата

Для Т1 с обеих сторон один ко многим, для остальных с одной стороны ничего, а с другой по 1 типу каждого

Тогда напиши еще раз, что ты хотел сказать этим:

Цитата

...для каждой таблицы с одной стороны - цепь "много к одному", а с другой - "один ко многим".

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

Цитата

...с одной стороны ничего...

Цитата

ну ты хоть ПОСМОТРИ, что ты сам нарисовал-то, ё моё

Спокойно, без нервов понимаю, что торможу, поэтому и спрашиваю.

Цитата(Bes @ 16.3.2005, 16:00)

предположим что Т2 - таблица покупок труб,т.е. код, дата, количество. а Т3 - таблица продаж т.е. код, дата, количество.

Правильная структура:

Покупки
ID
ТоварID
количество
прочее (дата, цена, ...)

Продажи
ID
ПокупкиID
количество
прочее (дата, цена, ...)

Связь один ко многим.

Цитата(Bes @ 16.3.2005, 16:00)

напиши еще раз, что ты хотел сказать этим

Т1 -> T2 -> T3

T1 - справа 2 шт. один ко много
T2 - справа один ко много, слева много к одному
Т3 - слева 2 шт. много к одному

Реально полная схема может и не ложиться в такое - могут быть сетки, множественные зависимости, зависимости на себя и пр... но схема данных КОНКРЕТНОГО ЗАПРОСА (включающая только обрабатываемые таблицы и представления) обязана отвечать вышеуказанному критерию.

У продаж точно ПокупкиID? Не ТоварID? Ны ничего не перепутал?
А как же я буду идентифицировать проданный товар? Только по связи с покупкой? Как-то странно.

Цитата(Bes @ 16.3.2005, 17:41)

У продаж точно ПокупкиID? Не ТоварID? Ны ничего не перепутал?

Точно, точно...

Цитата(Bes @ 16.3.2005, 17:41)

как же я буду идентифицировать проданный товар? Только по связи с покупкой?

угу...

Цитата(Bes @ 16.3.2005, 17:41)

Как-то странно

Чего странного? Продать ты можешь только тот товар, который купил, не так ли?

Цитата

Чего странного? Продать ты можешь только тот товар, который купил, не так ли?

Но купить товар-то (один и тот же) я могу несколько раз по немножку например т.е. закупок может быть несколько, а какой из записей я буду цплятся таблицей продаж?

Но идею-то я понял, ладно.

И все таки возвращаясь к теоретическому аспекту задачи...

Цитата

Теперь надо сделать запрос который выдаст все записи из таблицы Т3 и название детали из таблицы Т2 где код детали совпадает с кодом детали в Т3, а длина = 1 (т.е. из таблицы Т3 выбирается уже только одна запись на деталь). ВОПРОС: Можно ли сделать его редактируемым.

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

Это сообщение отредактировал(а) Bes - 17.3.2005, 09:47

Цитата(Bes @ 17.3.2005, 10:46)

Но купить товар-то (один и тот же) я могу несколько раз по немножку например т.е. закупок может быть несколько, а какой из записей я буду цплятся таблицей продаж?

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

Цитата(Bes @ 17.3.2005, 10:46)

возвращаясь к теоретическому аспекту задачи

Это вроде уже я тебе сказал до конца - обновляемым может быть только рекордсет, в котором отсутствуют неоднозначности. Частные случаи не рассматриваются - только общие, посему мало ли что фильтр оставил одну запись...

Цитата

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

Цитата

посему мало ли что фильтр оставил одну запись...

Понятно, спасибо.