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

← →
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 абсолютно одинаковые записи, после попробуй изменить одну из них(любое поле) получиш исключение.

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

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

Мы на рынке.
Вы покупаете арбузы (записи) у продавца (сервера) говоря продавцу : эй, продавец (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
- можно менять.

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

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

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

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

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

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

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

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

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

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

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

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

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

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