-
Как можно запомнить и восстановить текущее положение в dataset?
Пытаюсь избавится от последствий Refresh, которое использую
для отображения внесенных только что записей
А после refresh текущей становится в общем случае другая запись.
Можно: Запомнить запись, Refresh, отыскать ее, сделать текущей
Не работал с ODAC вообще, может как-то по-другому проще?
-
стандартно. букмарками.
-
> [0] 12 © (23.03.10 16:26)
Вноси данные через датасет - ничего рефрешить не надо.
-
понятно.
просто там гораздо больше св-в у TOraххх чем у TADOххх
думал что-то есть такое
-
> стандартно. букмарками.
фигня
букмарк после переоткрытия датасета в общем случае инвалидный
locate по первичному ключу в датасете
-
этот общий случай происходит раз в тысячу лет.
у меня букмарки всю дорогоу были валидны.
кроме того, никто не запрещает делать проверку избукмарквалид.
и если валид, то делать гоуту букмарк.
-
> Медвежонок Пятачок (24.03.2010 09:16:05) [5]
В рубашке родился
-
> у меня букмарки всю дорогоу были валидны.
значит тебе везет
ибо это всего лишь адрес из той области памяти, которую занимали данные до переоткрытия датасета
и нет никаких гарантий, что после переокрытия данные не окажутся в другой области памяти или по этому адресу будут другие данные
-
> кроме того, никто не запрещает делать проверку избукмарквалид.
> и если валид, то делать гоуту букмарк.
зачем усложнять если можно просто
> locate по первичному ключу в датасете
-
а потому что.
букмарки универсальнее. можно иметь библиотечный код и прикручивать его к любому датасету.
а в случае локейта надо каждый раз программировать конкретный датасет (массив имен и значений колонок первичного ключа)
-
> Медвежонок Пятачок (24.03.2010 10:53:09) [9]
Код с Locate даже короче и проще чем с букмарк
-
> Медвежонок Пятачок © (24.03.10 10:53) [9]
а потом самолеты падают
и все потому, что кое-кто слишком боится перетрудиться
кстати, ТПервичныйКлюч ненамного сложнее ТБукмарк для использования в библиотеке
-
объединение из трех таблиц.
присутствуют первичные ключи из всех трех.
все три ключа составные.
достаньте список колонок по которым надо делать локейт.
я понимаю, что это (как и все остальное) не намного сложнее чем букмарк.
-
> объединение из трех таблиц.
> присутствуют первичные ключи из всех трех.
и чо? все три первичных ключа таблиц дают первичный ключ набора данных
если нет, то обрабатывать это бессмыссленно - плохое проектирование
> все три ключа составные.
и чо? ломает, что ли?
> достаньте список колонок по которым надо делать локейт.
и чо? 10 колонок с их значениями трудно запихать в класс ТПервичныйКлюч и обработать в библиотеке?
> я понимаю, что это (как и все остальное) не намного сложнее чем букмарк.
это РЕАЛЬНО так
как говорится: "кто хочет - ищет способы, кто не хочет - ищет причины"
-
TBookmark заюзал
не самолеты пишу, а собьется раз в пятилетку - фиг с ним
-
За рекомендацию пользоваться букмарками при переоткрытии датасета медвежонку надо по тятачку
:)
-
> собьется раз в пятилетку - фиг с ним
это рулетка
и далеко не всем в ней везет
иногда и застрелиться случайно можно
> MsGuns © (24.03.10 16:43) [15]
симметричное клеймо с противоположной стороны поставить, чтоб всем видно было, куда метить
-
и чо? все три первичных ключа таблиц дают первичный ключ набора данных
если нет, то обрабатывать это бессмыссленно - плохое проектирование
Речь шла о библиотечной функции, которая восстанавливает позицию в датасете после рефреша.
То есть это случай, когда библиотечная функция ничего не знает о конкретном датасете.
Я и говорю.
В датасете три таблицы со своими первичными ключами.
у всех они составные.
Вы ничего внутри функции не знаете о датасете.
Получите список имен полей праймари кеев, который будут заюзаны в вашем локейте.
В моем случае я сделаю гетбукмарк, затем проверю его на нил и проверю на букмарквалид. Если все ок, сделаю гоутубукмарк.
А что сделаете вы?
-
> Как можно запомнить и восстановить текущее положение в dataset?
>
> Пытаюсь избавится от последствий Refresh, которое использую
>
> для отображения внесенных только что записей
что-то не так в консерватории.
-
>Медвежонок Пятачок © (24.03.10 18:33) [17]
>То есть это случай, когда библиотечная функция ничего не знает о >конкретном датасете.
А что, собсна, она ДОЛЖНА знать ?
-
К комментариям-"отмазкам" Медвежонка:
Если НД РЕДАКТИРУЕТСЯ, то, надо полагать, редактируется ОДНА таблица, а не несколько (иначе - "старуха с клюкой" (с))
А если таблица ОДНА, то и с идентификаторм проблем быть не должно.
-
А что, собсна, она ДОЛЖНА знать ?
Да ничего.
Есть TDataSet
Нужно закрыть его и открыть. После чего восстановить текущую запись которая была перед закрытием
-
> После чего восстановить текущую запись которая была перед
> закрытием
В общем случае невозможно. Ее могут удалить
-
>Медвежонок Пятачок © (24.03.10 20:15) [21]
>После чего восстановить текущую запись которая была перед закрытием
Е-е-ето как ето ?
-
В общем случае невозможно. Ее могут удалить
Ядерного взрыва не произойдет.
Либо букмарквалид будет false, либо датасет отпозиционируется не совсем туда куда хотелось бы.
Так как сама фича из области бантиков и рюшечек, на приложение это никак не повлияет. Ткнет юзер мышкой куда ему надо если курсор не там где он ожидает. И все.
-
Е-е-ето как ето ?
Это встать курсором на ту же запись, на которой стоял курсор перед рефрешем датасета.
-
Медвежонок Пятачок © (24.03.10 21:14) [24]
> Ядерного взрыва не произойдет.
Не произойдет.
> Либо букмарквалид будет false
А откуда оно узнает, false ему надо становиться или не false ?
> Ткнет юзер мышкой куда ему надо если курсор не там где он
> ожидает. И все.
Мы из этих соображений не позиционируемся на последнюю запись, где оно стояло. Обновляет пользователь, так обновляет, сам, его никто не заставляет, поэтому попадает на начало Dataset-а.
-
А откуда оно узнает, false ему надо становиться или не false ?
узнает через метод датасета.
Честно говоря вообще не догоняю из чего весь сыр бор.
Я этот метод применял на всем от парадокса до оракла и от бдешных tquery до одаковских ораквери.
Везде это работало. Везде.
Если я и не применял эту фичу, то не потому что не работало, а потому что либо это было ненужно, либо излишне напрягало сервер.
-
Сыр-бор оттого, что при редактировании в гриде нехило б было сделать юзеру банально приятно,- чтоб он после завершения редактирования (вставки, удаления) записи не терял то место, где он редактировал. Желание, кстати, вполне понятное, вопреки мнению некоторых тут. В самом деле, представьте, что после вставки в исходник новой строки вас перебрасывали бы в начало кода :)
Твой метод работает в случае, если таблица на все время редактирования не изменяется более никем
Закладываться на метод, работающий только "по погоде" - это подставить юзера. Причем, как обычно, "глюк" вылезет в самый неподходящий момент.
Не проще ли сразу делать правильно и надежно, не полагаясь на пресловутое "я так всегда делал - и ничего" ?
-
правильно и надежно - это кто вообще определил?
редактируем запись.
меняем значения полей.
в том числе возможно и ключевых.
и чем локейт в этом случае правильнее букмарка?
-
> Медвежонок Пятачок (24.03.2010 21:14:24) [24]
После позиционирования куда не надо, произойдет редактирование чего не надо.
-
> Медвежонок Пятачок (25.03.2010 01:27:29) [29]
Тем что правильно работает.
-
ну да, правильно.
локейт вернул файлсе потому что юзер отредактировал праймари кей и это правильно.
-
>Медвежонок Пятачок © (25.03.10 09:19) [32]
>локейт вернул файлсе потому что юзер отредактировал праймари кей и это правильно.
Если редактируется праймари, то это и есть "старуха с клюкой".
Использование UID поможет предводителю дворянства
-
то есть естественные праймари кей не имеют права на существование?
-
Я бы не смешивал понятие "праймари" (первичный) и "нативный" (естественный, сущностный)
-
и я не смешиваю.
праймари кей может редактироваться.
особенно если он естественный а не искусственный
-
> праймари кей может редактироваться.
может, конечно
но не пользователем
и нахрен не нужен натуральный первичный ключ из 2 десятков полей
короче, проще 10 лет облеплять кизяком стену, чтоб не упала, чем за месяц построить новую, так?
-
> и нахрен не нужен натуральный первичный ключ из 2 десятков
> полей
почему это ?
-
Можно, конечно, использовать в качестве первичного нативные реквизиты.
На простых структурах. Но в "этажерках" такая технология приводит к многочисленным проблемам, связанным с необходимостью после изменения ключа в мастере править в дочерних таблицах поля-связки.
Или я не верно понимаю политику партии и правительства ?
-
> Игорь Шевченко © (25.03.10 14:01) [38]
потому что кроме гипотетической экономии памяти никаких плюсов больше нет
да и в сторону мы уходим, это уже десятки раз перетирали и каждый остался при своем
я предпочитаю суррогатные первичные ключи, а то, что может претендовать на натуральный первичный ключ, просто делаю уником
гораздо гибче во многих случаях - можно и на то опереться, и на это, зависит от логики конкртной задачи
и даже если вдруг окажется, что натуральный ключ уже не совсем ключ, ничего не развалится, в отличие от противников суррогата
-
> Медвежонок Пятачок (25.03.2010 10:06:34) [34]
Да никакие изменения первичного ключа не являются проблемой. Надо чтобы форма редактирования/вставки возвращала правильный номер. Это еще один плюс в пользу редактирования в отдельной форме.
-
> MsGuns (25.03.2010 14:34:39) [39]
Не приводит, если использовать cascade updates, а я не вижу причины не использовать их
-
> Правильный$Вася (25.03.2010 18:17:40) [40]
И у тебя получается дублирование
-
Правильный$Вася (25.03.10 18:17) [40]
> я предпочитаю суррогатные первичные ключи, а то, что может
> претендовать на натуральный первичный ключ, просто делаю
> уником
Джо Целко зовет таких IDиотами :)
Я не совсем понимаю - если нет referential ссылки на таблицу с естественным ключом из N полей, зачем вводить дополнительную сущность ?
Телега хорошо едет с четырьмя колесами.
-
> Я не совсем понимаю - если нет referential ссылки на таблицу
> с естественным ключом из N полей, зачем вводить дополнительную
> сущность ?
у меня практически всегда есть (98%), так что не вижу смысла ради 2% делать исключение из своего правила
> Anatoly Podgoretsky © (25.03.10 20:01) [43]
> > Правильный$Вася (25.03.2010 18:17:40) [40]И у тебя получается
> дублирование
лучше продублировать 1 поле GUID, чем ссылаться на 10 полей из многих разных таблиц
экономия памяти, нервов и времени огромная
-
> Правильный$Вася (25.03.2010 20:29:45) [45]
Откуда взялось 10 полей? В связи как правило участвует одно поле.
-
>Anatoly Podgoretsky © (26.03.10 07:36) [46]
>Откуда взялось 10 полей? В связи как правило участвует одно поле.
Каждый "этаж" - одно поле. 10-этажный "небоскреб" - 10 полей в "пентхаузе" :)
-
> Откуда взялось 10 полей? В связи как правило участвует одно поле.
если PK составной, то в связи не может быть его часть, верно ведь?
-
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-й, а для работы после изменений значений входных параметров!