Как сделать Refresh для одной записи ClientDataSet

← →
OlkaGTS © (2003-08-07 13:49) [0]

Уважаемые!
Есть трехуровневое приложение. На клиенте ClientDataset получается joinом из нескольких таблиц. В приложении-сервере у DataSetProvider в BeforeUpdateRecord вызывается хр пр, которая это все сохраняет. Но после всего этого я не вижу поле типа identity на клиенте, а делать Refresh всему dataset не хочется, потому что изменения на сервере должны сохраняться после каждого post. Можно ли каким-то другим способом получить значение этого поля?

← →
clickmaker © (2003-08-07 13:58) [1]

Попробуй RefreshRecord

← →
OlkaGTS © (2003-08-07 14:00) [2]

RefreshRecord не получается по той же причине. Нет первичного ключа, по которому он мог бы его сделать

← →
Nikolay M. © (2003-08-07 14:04) [3]

БД какая?
В IB делалось так: создавалась хранимая процедура, которая при каждом вызове возвращала автоинкрементное значение генератора (можно и просто табличку для этого завести) и которое потом уже использовалось во всяких
INSERT INTO table (ID, ...) VALUES (:ID, ...)
и тп.
Очень удобно, когда редактируется одна из нескольких связанных таблиц.

← →
OlkaGTS © (2003-08-07 14:06) [4]

БД MSSQL. Там не генераторов

← →
Nikolay M. © (2003-08-07 14:30) [5]

Тогда можно завести таблицу CREATE TABLE (id_value INTEGER, table_name VARCHAR(255)) и сваять под нее маленькую процедурку, которая по имени таблицы будет возвращать каждый раз автоинкреметное id_value.
Кстати, раз уж у тебя трехзвенка, то можно вообще ID на уровне RemoteDataModule генерировать :) Только не забыть генерацию в критической секции делать - многопоточность все-таки. Ну или любой другой способ синхронизации потоков, какой больше нравится.

← →
OlkaGTS © (2003-08-07 14:37) [6]

Проблема не в этом. Значение поля генерирует сам сервер, но после сохранения я не вижу это значение на клиенте, пока не сделаю Dataset.Refresh. При этом обновятся все записи, а мне нужно только одна конкретная, которую только что вставили.
У провайдера в options есть poAutoRefresh и poPropagateChanges, которые вроде бы должны это делать. Но они этого почему-то не делают

← →
Nikolay M. © (2003-08-07 14:53) [7]

Как раз проблема именно в этом. Кто тебе сказал, что после INSERT провайдер будет сразу делать SELECT только что вставленной записи? И опции тут не помогут. А если будешь делать одним из методов, как я сказал в
> Nikolay M. © (07.08.03 14:30)
, тогда и проблемы не будет. Для MS SQL можно рискнуть вытянуть @@IDENTITY или как она там зовется, не помню точно - ID последней вставленной записи, но есть вероятность нарваться...
Короче, мой совет - вставлять запись с уже известным на уровне провайдера ID. Вот тогда poAutoRefresh и poPropagateChanges вернут это значение назад на клиент. Но от БД на провайдер значения придут только после Refresh-а.

← →
OlkaGTS © (2003-08-07 16:53) [8]

Я не могу изобретать никакие новые методы. База должна работать по классической технологии. Отсюда следует, что вытягивание @@Identity ничего не дает, поскольку я его потом никуда не могу записать, так как автоинкрементные поля Read Only.
Т.е. насколько я понимаю, получить ID только что вставленной записи невозможно никак, кроме как Refresh всему DataSet?

← →
Nikolay M. © (2003-08-07 17:15) [9]

> Отсюда следует, что вытягивание @@Identity ничего не дает,
> поскольку я его потом никуда не могу записать, так как автоинкрементные
> поля Read Only.

SET IDENTITY_INSERT MyTable ON
еще никто не отменял.

> получить ID только что вставленной записи невозможно никак,
> кроме как Refresh всему DataSet?

В таблице есть еще первичные ключи? Скажем, уникальное название или еще что-то... По нему можно вытянуть ID.

> База должна работать по классической технологии.

Диплом???!

← →
OlkaGTS © (2003-08-07 17:27) [10]

CREATE TABLE TT ([ID] int identity(1,1) PRIMARY KEY и т.д.) - этот первичный ключ и имелся ввиду.
А по классической технологии в том смысле, что все первичные ключи - это поля identity и никак иначе и генерироваться значения должны сервером, поскольку с базой работает не одно приложение

← →
Nikolay M. © (2003-08-07 17:59) [11]

Ну и создай хранимую процедуру, которая эти PRIMARY KEY будет тягать из таблицы. Только блокировку на уровне записи не забыть наложить. И чем это не генерация ID на уровне БД?
Нет, ну если очень хочется, тогда
CDS.Active := False;
CDS.Active := True;...
Пользователи спасибо скажут :)

← →
Polevi © (2003-08-07 18:29) [12]

procedure TRDM.BeforeUpdateRecord_(Sender: TObject; SourceDS: TDataSet;
DeltaDS: TClientDataSet; UpdateKind: TUpdateKind; var Applied: Boolean);
begin
if UpdateKind=ukInsert then
begin
qry:=TADOQuery.Create(nil);
try
qry.Connection:=SomeAdoConnection;
qry.SQL.Add("EXEC bla-bla-bla);
qry.SQL.Add("SELECT @@IDENTITY");
qry.Open;
DeltaDS.FieldByName("ID").ReadOnly:=false;
( "ID") procedure TRDM.BeforeUpdateRecord_(Sender: TObject; SourceDS: TDataSet;
DeltaDS: TClientDataSet; UpdateKind: TUpdateKind; var Applied: Boolean);
begin
if UpdateKind=ukInsert then
begin
qry:=TADOQuery.Create(nil);
try
qry.Connection:=SomeAdoConnection;
qry.SQL.Add("EXEC bla-bla-bla);
qry.SQL.Add("SELECT @@IDENTITY");
qry.Open;
DeltaDS.FieldByName("ID").ReadOnly:=false;
DeltaDS.FieldByName("ID").NewValue:=qry.Fields[0].Value;
finally
qry.Free
end;
Applied:=true;
end;
end;

← →
Romkin © (2003-08-07 18:57) [13]

Опять счетчики... Так надоело...
>А по классической технологии в том смысле, что все первичные ключи - это поля identity и никак иначе
Мдя, что за классика? Явно форма выше НФБК. Насчет получения уникальных значений см http://rsdn.ru/article/db/midas_migration.xml
в частности,
http://rsdn.ru/article/db/midas_migration.xml#XSLTSECTION124143120120
Все описано, все работает.

← →
Polevi © (2003-08-07 20:38) [14]

2Romkin © (07.08.03 18:57)
например мне нужно выполнить SP на сервере которая сделает INSERT нескольких записей - при таком подходе это будет не просто сделать, если в таблице есть уникальное поле

← →
Nikolay M. © (2003-08-07 23:04) [15]

> Насчет получения уникальных значений см http://rsdn.ru/article/db/midas_migration.xml
> в частности,
> http://rsdn.ru/article/db/midas_migration.xml#XSLTSECTION124143120120

Именно это и пытаюсь втолковать, пока не очень получается :(

← →
corte ™ (2003-08-08 07:50) [16]

А букмарками не пользовался ?

2Nikolay M. © (07.08.03 23:04)
есть таблица шапок документов и их содержимого
в таблице содержимого кластерный индекс
напиши мне XP которая сделает копию документа

БД MS SQL сервер

>напиши мне XP
сорри, SP конечно

> Polevi © (07.08.03 20:38)
> например мне нужно выполнить SP на сервере которая сделает
> INSERT нескольких записей - при таком подходе это будет
> не просто сделать, если в таблице есть уникальное поле

А зачем пользоваться этим методом там, где он себя не оправдывает?

> есть таблица шапок документов и их содержимого
> в таблице содержимого кластерный индекс

Таблиц все-таки одна или две?

2, отношение 1 ко многим

при твоем способе придется писать курсор
если поле AutoInc все делается одним
INSERT INTO .. SELECT FROM

если стоит задача независимости от БД, тогда всю логику нужно реализовать на middleware, а БД использовать только как набор таблиц и индексов, и никаких SP, ф-ий, курсоров и тд, только SQL 92

если такой задачи нет - незачем отказываться от функциональности СУБД и сочинять велосипеды

> при твоем способе

Это совсем не мой способ :)
Хоть я сначала и придумал его, а потом уже только прочитал статью на rsdn.

Можно поизвращаться, искуственно ввести дополнительно временный Primary Key, который будет генерироваться случайным образом из очень широкого диапазона... Но красотой такой вариант не блещет :(

Как сделать Refresh для одной записи ClientDataSet Найти похожие ветки