Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

ODAC/ запомнить и восстановить текущее положение в dataset [D7]

Страницы: 1 2 3 >
12 © (2010-03-23 16:26:00)
Как можно запомнить и восстановить текущее положение в dataset?
Пытаюсь избавится от последствий Refresh, которое использую
для отображения внесенных только что записей

А после refresh текущей становится в общем случае другая запись.

Можно: Запомнить запись, Refresh, отыскать ее, сделать текущей

Не работал с ODAC вообще, может как-то по-другому проще?

evvcom (2010-03-26 14:34:00) [1]
1. Как уже было сказано в [2] "Вноси данные через датасет - ничего рефрешить не надо."
2. Я копал внутренности букмарка одаковского датасета, это не что иное как номер строки датасета, поэтому добавляя новую запись (через грид или отдельную форму), вызывая метод Add, мы добавляем запись в конец набора, а после рефреша и order by в запросе эта запись становится уже далеко не последней (чаще всего).
3. Я немного модифицировал одаковский датасет, написав наследника, добавив туда KeyFieldName, и написал одну регулярную процедуру. После этого просто вызаваю DSRefresh(ADataSet):
procedure DSRefresh(DS: TDataSet; KeepPos: Boolean); var l_Values : array of Variant; l_FieldCount: Integer; l_FieldNames: string; l_FieldName : string; l_RecNo : Integer; l_RecCount : Integer; begin if (DS is TOraStoredProc) and (TOraStoredProc(DS).StoredProcName <> '') then begin if DS.Active and (DS is TMyOraStoredProc) and (TMyOraStoredProc(DS).KeyFieldName <> '') then begin l_FieldNames := TMyOraStoredProc(DS).KeyFieldName; l_FieldCount := 0; l_RecNo := 1; while True do begin l_FieldName := ExtractFieldName(l_FieldNames, l_RecNo); if l_FieldName <> '' then begin Inc(l_FieldCount); SetLength(l_Values, l_FieldCount); l_Values[l_FieldCount - 1] := DS.FieldValues[l_FieldName]; end else Break; end; DS.Close; DS.Open; if DS.Active then DS.Locate(l_FieldNames, l_Values, []); end else begin l_RecNo := DS.RecNo; DS.Close; DS.Open; l_RecCount := DS.RecordCount; if KeepPos and (l_RecCount > 0) then begin if l_RecNo > l_RecCount then l_RecNo := l_RecCount; if DS.Active then DS.MoveBy(l_RecNo - 1); end; end; end; end;
Противники RecNo могут поменять их на букмарки, но в хелпе явно написано, что букмарк после переоткрытия датасета становится невалидным! Это в общем случае. Таким образом, данная процедура отлично у меня работает уже несколько лет и с одним ключом, и с составным, и даже пытается работать, если я где-то забыл указать ключ.
Но следует понимать, что этот рефреш написан не для рефреша после изменений, т.к. см. пункт 1-й, а для работы после изменений значений входных параметров!

Правильный$Вася (2010-03-26 11:13:00) [2]

> Откуда взялось 10 полей? В связи как правило участвует одно поле.

если PK составной, то в связи не может быть его часть, верно ведь?

MsGuns (2010-03-26 09:07:00) [3]
>Anatoly Podgoretsky © (26.03.10 07:36) [46]
>Откуда взялось 10 полей? В связи как правило участвует одно поле.

Каждый "этаж" - одно поле. 10-этажный "небоскреб" - 10 полей в "пентхаузе" :)

Anatoly Podgoretsky (2010-03-26 07:36:00) [4]
> Правильный$Вася (25.03.2010 20:29:45) [45]

Откуда взялось 10 полей? В связи как правило участвует одно поле.

Правильный$Вася (2010-03-25 20:29:00) [5]

> Я не совсем понимаю - если нет referential ссылки на таблицу
> с естественным ключом из N полей, зачем вводить дополнительную
> сущность ?

у меня практически всегда есть (98%), так что не вижу смысла ради 2% делать исключение из своего правила

> Anatoly Podgoretsky © (25.03.10 20:01) [43]
> > Правильный$Вася (25.03.2010 18:17:40) [40]И у тебя получается
> дублирование

лучше продублировать 1 поле GUID, чем ссылаться на 10 полей из многих разных таблиц
экономия памяти, нервов и времени огромная

Игорь Шевченко (2010-03-25 20:11:00) [6]
Правильный$Вася (25.03.10 18:17) [40]

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

Джо Целко зовет таких IDиотами :)

Я не совсем понимаю - если нет referential ссылки на таблицу с естественным ключом из N полей, зачем вводить дополнительную сущность ?

Телега хорошо едет с четырьмя колесами.

Anatoly Podgoretsky (2010-03-25 20:01:00) [7]
> Правильный$Вася (25.03.2010 18:17:40) [40]

И у тебя получается дублирование

Anatoly Podgoretsky (2010-03-25 20:00:00) [8]
> MsGuns (25.03.2010 14:34:39) [39]

Не приводит, если использовать cascade updates, а я не вижу причины не использовать их

Anatoly Podgoretsky (2010-03-25 19:59:00) [9]
> Медвежонок Пятачок (25.03.2010 10:06:34) [34]

Да никакие изменения первичного ключа не являются проблемой. Надо чтобы форма редактирования/вставки возвращала правильный номер. Это еще один плюс в пользу редактирования в отдельной форме.

Правильный$Вася (2010-03-25 18:17:00) [10]

> Игорь Шевченко © (25.03.10 14:01) [38]

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

MsGuns (2010-03-25 14:34:00) [11]
Можно, конечно, использовать в качестве первичного нативные реквизиты.
На простых структурах. Но в "этажерках" такая технология приводит к многочисленным проблемам, связанным с необходимостью после изменения ключа в мастере править в дочерних таблицах поля-связки.
Или я не верно понимаю политику партии и правительства ?

Игорь Шевченко (2010-03-25 14:01:00) [12]

> и нахрен не нужен натуральный первичный ключ из 2 десятков
> полей

почему это ?

Правильный$Вася (2010-03-25 13:03:00) [13]

> праймари кей может редактироваться.

может, конечно
но не пользователем

и нахрен не нужен натуральный первичный ключ из 2 десятков полей

короче, проще 10 лет облеплять кизяком стену, чтоб не упала, чем за месяц построить новую, так?

Медвежонок Пятачок (2010-03-25 11:02:00) [14]
и я не смешиваю.
праймари кей может редактироваться.
особенно если он естественный а не искусственный

MsGuns (2010-03-25 10:35:00) [15]
Я бы не смешивал понятие "праймари" (первичный) и "нативный" (естественный, сущностный)

Медвежонок Пятачок (2010-03-25 10:06:00) [16]
то есть естественные праймари кей не имеют права на существование?

MsGuns (2010-03-25 09:53:00) [17]
>Медвежонок Пятачок © (25.03.10 09:19) [32]
>локейт вернул файлсе потому что юзер отредактировал праймари кей и это правильно.

Если редактируется праймари, то это и есть "старуха с клюкой".
Использование UID поможет предводителю дворянства

Медвежонок Пятачок (2010-03-25 09:19:00) [18]
ну да, правильно.
локейт вернул файлсе потому что юзер отредактировал праймари кей и это правильно.

Anatoly Podgoretsky (2010-03-25 05:23:00) [19]
> Медвежонок Пятачок (25.03.2010 01:27:29) [29]

Тем что правильно работает.

Anatoly Podgoretsky (2010-03-25 05:21:00) [20]
> Медвежонок Пятачок (24.03.2010 21:14:24) [24]

После позиционирования куда не надо, произойдет редактирование чего не надо.

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »