Можно ли вносить изменения...

← →
PrettyFly (2003-08-29 14:34) [0]

Можно ли как-нибудь вносить изменения в DataSet организованный из двух таблиц, например:

SELECT A.*, B.Name
FROM A INNER JOIN И ON(B.IDA = A.ID)

т.е. так, чтобы и в базе всё правильно менялось?

← →
Карелин Артем (2003-08-29 14:39) [1]

Да, только надо самостоятельно реализовывать логику на изменение таблиц с помощью IbDataSet или IBUpdateSQL в виде соотв. запросов.

← →
GRAND (2003-08-29 15:58) [2]

PrettyFly © (29.08.03 14:34)

Если юзать FIBPlus, то там с этим гемора на порядок меньше.

← →
Bless (2003-08-29 16:19) [3]

А тот же вопрос, только применительно к MSSQL через ADO-шные компоненты?

← →
Bless (2003-09-01 09:24) [4]

Что, никто не знает? Или нельзя никак?

← →
Reindeer Moss Eater (2003-09-01 09:34) [5]

А тот же вопрос, только применительно к MSSQL
MSSQL позволяет редактировать такие наборы данных.

← →
Sergey,Masloff (2003-09-01 09:39) [6]

GRAND © (29.08.03 15:58) [2]
>Если юзать FIBPlus, то там с этим гемора на порядок меньше.
Никаких проблем нет даже если FIBPlus не использовать

← →
Bless (2003-09-01 11:02) [7]

>MSSQL позволяет редактировать такие наборы данных.

В гриде отображается результат запроса
SELECT t1.*, t2.* FROM t1, t2 WHERE t1.kod=t2.kod

При попытке изменить в гриде что-нибудь, возникает ошибка

Project Project1.exe raised exception class EOleException with message "Insufficient key column information for updating or refreshing". Process stopped. Use Step or Run to continue.

В чем может быть проблема?

← →
Bless (2003-09-01 11:04) [8]

А с запросом
SELECT t1.* FROM t1, t2 WHERE t1.kod=t2.kod
редактируется без проблем.

← →
Reindeer Moss Eater (2003-09-01 11:05) [9]

Тебе же сказали по-русски: недостаточно информации о ключевых полях таблиц, входящих в объединение

← →
Bless (2003-09-01 11:10) [10]

Гм... На русский я и сам перевести могу. Но яснее от этого не стало. Зачем этому запросу нужна информация о ключевых полях объединяемых таблиц? И как определить, что ее уже достаточно? А если у меня нет ни одного ключа в таблице?

← →
Reindeer Moss Eater (2003-09-01 11:14) [11]

А если у меня нет ни одного ключа в таблице?
Обновление "нужных записей" станет невозможным.

← →
Bless (2003-09-01 11:25) [12]

>Обновление "нужных записей" станет невозможным.

Вот мои вышеприведенные примеры:
1)SELECT t1.*, t2.* FROM t1, t2 WHERE t1.kod=t2.kod
2)SELECT t1.* FROM t1, t2 WHERE t1.kod=t2.kod

Но ведь во втором моем примере обновление работает. Хотя нет ни одного ключа в таблице! А ведь данные из таблицы t1 выбраны точно те же, что и в первом примере запроса!
Так почему в первом случае инфирмации о ключевых полях не достаточно, а во втором - хватает?

← →
Reindeer Moss Eater (2003-09-01 11:29) [13]

Но ведь во втором моем примере обновление работает.

SELECT t1.* - все поля присутствуют, значит и ключевые там есть.
Когда "все работает" обновляются поля из обеих таблиц или одной?

← →
Bless (2003-09-01 11:38) [14]

>SELECT t1.* - все поля присутствуют, значит и ключевые там есть.

В запросе SELECT t1.*, t2.* тоже все поля присутствуют, а не работает

Может, мы понимаем разные вещи под словом ключевое поле?
Если под "ключевым" имеется ввиду поле, по которому создан индекс, то в таблице t1 таких полей нет.

>Когда "все работает" обновляются поля из обеих таблиц или одной?

Из одной наверное. Ведь данные, отображенные в гриде- t1.* -выбираются только из одной таблицы.

← →
Reindeer Moss Eater (2003-09-01 11:53) [15]

Из одной наверное. Ведь данные, отображенные в гриде- t1.* -выбираются только из одной таблицы.

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

← →
Zacho (2003-09-01 11:56) [16]

> Bless (01.09.03 11:38) [14]
> Если под "ключевым" имеется ввиду поле, по которому создан
> индекс, то в таблице t1 таких полей нет

Что, и первичного ключа нет ? Нехорошо. Черевато аномалиями.

← →
Bless (2003-09-01 12:25) [17]

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

О, это уже что-то. Спасибо.
Так что, если мне кровь из носу надо обновлять данные из нескольких таблиц, то надо извращаться? А никаких механизмов, облегчающий жизнь вроде RequestLive или UpdateSQL или их аналогов/заменителей нету?

>Что, и первичного ключа нет ? Нехорошо. Черевато аномалиями.

Да это тестовые таблицы по 5 записей в каждой :)

← →
HSolo (2003-09-01 14:26) [18]

Зачем же извращаться? Напишите процедуру вставки/обновления, вполне себе штатный способ. Откуда дергать - я пользую FIBPlus, там есть для таких вещей TpFIBUpdateObject

← →
Bless (2003-09-01 14:40) [19]

>Зачем же извращаться? Напишите процедуру вставки/обновления,
>вполне себе штатный способ.
А где эти процедуры пишутся? Напоминаю, речь идет об MSSQL и ADO
>Откуда дергать - я пользую FIBPlus,
>там есть для таких вещей TpFIBUpdateObject

Если буквы IB в слове FIBPlus обозначают InterBase, то это не подходит. А если нет - то что это такое и где его взять.

← →
HSolo (2003-09-01 15:08) [20]

Извините, проморгала, что речь идет уже об MSSQL. FIBPlus - да, это для IB.
А процедуры пишутся средствами SQL-сервера. Имеются в виду хранимые процедуры.

← →
Bless (2003-09-03 09:22) [21]

В общем, добавил ключи в таблицу и все заработало.
Вот бы еще понять, ПОЧЕМУ без ключей работает не всегда и ПОЧЕМУ работает с ключами...

← →
Danilka (2003-09-03 10:08) [22]

Bless (03.09.03 09:22)
Ключ это не индекс, ключ - это поле или набор полей однозначно идентифицирующие запись.
А проблемы из-за отсутствия ключей, например такие:

Когда ты изменяешь в датасете какую-нибудь запись делается запрос к серверу, типа:
update ИМЯ_ТАБЛИЦЫ
set ИЗМЕНЯЕМОЕ_ПОЛЕ = НОВОЕ_ЗНАЧЕНИЕ
where КЛЮЧЕВОЕ_ПОЛЕ = ЗНАЧЕНИЕ_КЛЮЧА_ИЗМЕНЯЕМОЙ_ЗАПИСИ

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

← →
sniknik (2003-09-03 10:21) [23]

Bless (03.09.03 09:22) [21]
> Вот бы еще понять...

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

так что ключ нужен, даже если вам он не нужен!

← →
Reindeer Moss Eater (2003-09-03 10:34) [24]

Вот бы еще понять, ПОЧЕМУ без ключей работает не всегда и ПОЧЕМУ работает с ключами...

Мы на рынке.
Вы покупаете арбузы (записи) у продавца (сервера) говоря продавцу : эй, продавец (SQL сервер), дай мне вон тот круглый зеленый арбуз (вон ту запись в таблице). На что продавец (SQL сервер) резонно отвечает: они у меня все зеленые и все круглые (ключ короче говоря давай).

← →
Bless (2003-09-03 12:30) [25]

Прошу прощения. Я сказал, что добавил ключи. Имел ввиду, что ввел еще одно UNIQUE-поле в каждую таблицу.
Но до введение нового уникального поля у меня и так не было повторяющихся записей, то есть был "набор полей, однозначно идентифицирующих запись", а значит, был ключ!
А не работало для запроса 1) и работало для запроса 2)
( см. [12] )
Но ведь количество строк в обеих случаях одинаково. Просто меньше столбцов!

Если должно работать с ключом (не путать с индексом!), то почему не работает в случае 1)? Ведь ключ есть в обеих таблицах, если понимать под ключом набор полей, однозначно идентифицирующих запись.
Если должно НЕ работать без индекса, то почему работает в случае 2)?

>Reindeer Moss Eater © (03.09.03 10:34) [24]
>Мы на рынке.
>Вы покупаете арбузы (записи) у продавца (сервера) говоря
>продавцу : эй, продавец (SQL сервер), дай мне вон тот круглый
>зеленый арбуз (вон ту запись в таблице). На что продавец (SQL
>сервер) резонно отвечает: они у меня все зеленые и все круглые
>(ключ короче говоря давай).

:) Это, конечно, правильно. Но я понимал под ключом индекс. И потому говорил, что в таблицах нет ключа. В свете нового (для меня ) определения ключа, данного Danilka-ой, говорю: ключ есть. И ситуация с арбузами теперь приблизительно такая:

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

Если захотите проверить, привожу свои таблицы

t1
-------------------
kod(int) name (char(10))
1 qqq
1 b
2 k
2 b
3 c
3 d
4 e

t2
---------------------
kod(int) ChildKod(int) name(char(10))
2 22 bbb
3 33 c
4 44 d

Индексов нет.

SELECT t1.*, t2.* FROM t1, t2 WHERE t1.kod=t2.kod
- нельзя менять.

SELECT t1.* FROM t1, t2 WHERE t1.kod=t2.kod
- можно менять.

← →
Danilka (2003-09-03 12:45) [26]

Bless (03.09.03 12:30)
Дело в том, что сервер должен знать, какое поле у него является ключевым.
Для этого тебе надо исполнить скрипт:

alter table ИМЯ_ТАБЛИЦЫ
add constraint ИМЯ_КЛЮЧА
primary key (ИМЯ_КЛЮЧЕВОГО_ПОЛЯ)

← →
Danilka (2003-09-03 12:46) [27]

Если в ключе несколько полей, то надо их перечислить через запятую.

← →
Bless (2003-09-03 15:38) [28]

А сам сервер не определяет, какие у таблицы поля ключевые?

← →
Danilka (2003-09-03 15:43) [29]

Bless (03.09.03 15:38)
нет. это определяет тот, кто проектирует таблицы - какие поля у него ключевые, какие нет.

← →
Bless (2003-09-03 15:46) [30]

Так почему работает
SELECT t1.* FROM t1, t2 WHERE t1.kod=t2.kod?

← →
Danilka (2003-09-03 15:57) [31]

Bless (03.09.03 15:46)
Это глюк такой. :))
На самом деле, если ключа нет, то какие-то запросы будут работать. Иногда. :))
Для полноценной работы с сервером ключи нужны обязательно. Почитай Мартина Грубера "Понимание SQL", есть на сайте Анатолия Подгорецкого в вордовском формате:
http://www.podgoretsky.com/

← →
Reindeer Moss Eater (2003-09-03 16:02) [32]

Так почему работает
SELECT t1.* FROM t1, t2 WHERE t1.kod=t2.kod?

Потому что обновляются поля только одной таблицы.

← →
Bless (2003-09-03 16:19) [33]

Всем спасибо.

Можно ли вносить изменения... Найти похожие ветки