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

← →
12 © (2010-03-23 16:26) [0]

Как можно запомнить и восстановить текущее положение в dataset?
Пытаюсь избавится от последствий Refresh, которое использую
для отображения внесенных только что записей

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

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

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

← →
Медвежонок Пятачок © (2010-03-23 16:38) [1]

стандартно. букмарками.

← →
Sergey13 © (2010-03-23 16:39) [2]

> [0] 12 © (23.03.10 16:26)

Вноси данные через датасет - ничего рефрешить не надо.

← →
12 © (2010-03-23 16:57) [3]

понятно.
просто там гораздо больше св-в у TOraххх чем у TADOххх
думал что-то есть такое

← →
Правильный$Вася (2010-03-24 00:27) [4]

> стандартно. букмарками.

фигня
букмарк после переоткрытия датасета в общем случае инвалидный

locate по первичному ключу в датасете

← →
Медвежонок Пятачок © (2010-03-24 09:16) [5]

этот общий случай происходит раз в тысячу лет.
у меня букмарки всю дорогоу были валидны.

кроме того, никто не запрещает делать проверку избукмарквалид.
и если валид, то делать гоуту букмарк.

← →
Anatoly Podgoretsky © (2010-03-24 10:25) [6]

> Медвежонок Пятачок (24.03.2010 09:16:05) [5]

В рубашке родился

← →
Правильный$Вася (2010-03-24 10:26) [7]

> у меня букмарки всю дорогоу были валидны.

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

← →
sniknik © (2010-03-24 10:32) [8]

> кроме того, никто не запрещает делать проверку избукмарквалид.
> и если валид, то делать гоуту букмарк.
зачем усложнять если можно просто
> locate по первичному ключу в датасете

← →
Медвежонок Пятачок © (2010-03-24 10:53) [9]

а потому что.

букмарки универсальнее. можно иметь библиотечный код и прикручивать его к любому датасету.
а в случае локейта надо каждый раз программировать конкретный датасет (массив имен и значений колонок первичного ключа)

← →
Anatoly Podgoretsky © (2010-03-24 11:37) [10]

> Медвежонок Пятачок (24.03.2010 10:53:09) [9]

Код с Locate даже короче и проще чем с букмарк

← →
Правильный$Вася (2010-03-24 11:39) [11]

> Медвежонок Пятачок © (24.03.10 10:53) [9]

а потом самолеты падают
и все потому, что кое-кто слишком боится перетрудиться

кстати, ТПервичныйКлюч ненамного сложнее ТБукмарк для использования в библиотеке

← →
Медвежонок Пятачок © (2010-03-24 12:09) [12]

объединение из трех таблиц.
присутствуют первичные ключи из всех трех.
все три ключа составные.

достаньте список колонок по которым надо делать локейт.

я понимаю, что это (как и все остальное) не намного сложнее чем букмарк.

← →
Правильный$Вася (2010-03-24 12:49) [13]

> объединение из трех таблиц.
> присутствуют первичные ключи из всех трех.

и чо? все три первичных ключа таблиц дают первичный ключ набора данных
если нет, то обрабатывать это бессмыссленно - плохое проектирование

> все три ключа составные.

и чо? ломает, что ли?

> достаньте список колонок по которым надо делать локейт.

и чо? 10 колонок с их значениями трудно запихать в класс ТПервичныйКлюч и обработать в библиотеке?

> я понимаю, что это (как и все остальное) не намного сложнее чем букмарк.

это РЕАЛЬНО так

как говорится: "кто хочет - ищет способы, кто не хочет - ищет причины"

← →
12 © (2010-03-24 14:15) [14]

TBookmark заюзал
не самолеты пишу, а собьется раз в пятилетку - фиг с ним

← →
MsGuns © (2010-03-24 16:43) [15]

За рекомендацию пользоваться букмарками при переоткрытии датасета медвежонку надо по тятачку
:)

← →
Правильный$Вася (2010-03-24 17:29) [16]

> собьется раз в пятилетку - фиг с ним

это рулетка
и далеко не всем в ней везет
иногда и застрелиться случайно можно

> MsGuns © (24.03.10 16:43) [15]

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

← →
Медвежонок Пятачок © (2010-03-24 18:33) [17]

и чо? все три первичных ключа таблиц дают первичный ключ набора данных
если нет, то обрабатывать это бессмыссленно - плохое проектирование

Речь шла о библиотечной функции, которая восстанавливает позицию в датасете после рефреша.

То есть это случай, когда библиотечная функция ничего не знает о конкретном датасете.

Я и говорю.
В датасете три таблицы со своими первичными ключами.
у всех они составные.

Вы ничего внутри функции не знаете о датасете.

Получите список имен полей праймари кеев, который будут заюзаны в вашем локейте.

В моем случае я сделаю гетбукмарк, затем проверю его на нил и проверю на букмарквалид. Если все ок, сделаю гоутубукмарк.

А что сделаете вы?

← →
Игорь Шевченко © (2010-03-24 19:00) [18]

> Как можно запомнить и восстановить текущее положение в dataset?
>
> Пытаюсь избавится от последствий Refresh, которое использую
>
> для отображения внесенных только что записей

что-то не так в консерватории.

← →
MsGuns © (2010-03-24 19:19) [19]

>Медвежонок Пятачок © (24.03.10 18:33) [17]
>То есть это случай, когда библиотечная функция ничего не знает о >конкретном датасете.

А что, собсна, она ДОЛЖНА знать ?

← →
MsGuns © (2010-03-24 19:22) [20]

К комментариям-"отмазкам" Медвежонка:

Если НД РЕДАКТИРУЕТСЯ, то, надо полагать, редактируется ОДНА таблица, а не несколько (иначе - "старуха с клюкой" (с))
А если таблица ОДНА, то и с идентификаторм проблем быть не должно.

← →
Медвежонок Пятачок © (2010-03-24 20:15) [21]

А что, собсна, она ДОЛЖНА знать ?

Да ничего.
Есть TDataSet
Нужно закрыть его и открыть. После чего восстановить текущую запись которая была перед закрытием

← →
Игорь Шевченко © (2010-03-24 20:44) [22]

> После чего восстановить текущую запись которая была перед
> закрытием

В общем случае невозможно. Ее могут удалить

← →
MsGuns © (2010-03-24 20:58) [23]

>Медвежонок Пятачок © (24.03.10 20:15) [21]
>После чего восстановить текущую запись которая была перед закрытием

Е-е-ето как ето ?

← →
Медвежонок Пятачок © (2010-03-24 21:14) [24]

В общем случае невозможно. Ее могут удалить

Ядерного взрыва не произойдет.
Либо букмарквалид будет false, либо датасет отпозиционируется не совсем туда куда хотелось бы.
Так как сама фича из области бантиков и рюшечек, на приложение это никак не повлияет. Ткнет юзер мышкой куда ему надо если курсор не там где он ожидает. И все.

← →
Медвежонок Пятачок © (2010-03-24 21:15) [25]

Е-е-ето как ето ?

Это встать курсором на ту же запись, на которой стоял курсор перед рефрешем датасета.

← →
Игорь Шевченко © (2010-03-24 21:22) [26]

Медвежонок Пятачок © (24.03.10 21:14) [24]

> Ядерного взрыва не произойдет.

Не произойдет.

> Либо букмарквалид будет false

А откуда оно узнает, false ему надо становиться или не false ?

> Ткнет юзер мышкой куда ему надо если курсор не там где он
> ожидает. И все.

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

← →
Медвежонок Пятачок © (2010-03-24 21:34) [27]

А откуда оно узнает, false ему надо становиться или не false ?

узнает через метод датасета.

Честно говоря вообще не догоняю из чего весь сыр бор.
Я этот метод применял на всем от парадокса до оракла и от бдешных tquery до одаковских ораквери.

Везде это работало. Везде.

Если я и не применял эту фичу, то не потому что не работало, а потому что либо это было ненужно, либо излишне напрягало сервер.

← →
MsGuns © (2010-03-24 22:58) [28]

Сыр-бор оттого, что при редактировании в гриде нехило б было сделать юзеру банально приятно,- чтоб он после завершения редактирования (вставки, удаления) записи не терял то место, где он редактировал. Желание, кстати, вполне понятное, вопреки мнению некоторых тут. В самом деле, представьте, что после вставки в исходник новой строки вас перебрасывали бы в начало кода :)

Твой метод работает в случае, если таблица на все время редактирования не изменяется более никем

Закладываться на метод, работающий только "по погоде" - это подставить юзера. Причем, как обычно, "глюк" вылезет в самый неподходящий момент.
Не проще ли сразу делать правильно и надежно, не полагаясь на пресловутое "я так всегда делал - и ничего" ?

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

> Медвежонок Пятачок (24.03.2010 21:14:24) [24]

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

> Медвежонок Пятачок (25.03.2010 01:27:29) [29]

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

ну да, правильно.
локейт вернул файлсе потому что юзер отредактировал праймари кей и это правильно.

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

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

то есть естественные праймари кей не имеют права на существование?

Я бы не смешивал понятие "праймари" (первичный) и "нативный" (естественный, сущностный)

и я не смешиваю.
праймари кей может редактироваться.
особенно если он естественный а не искусственный

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

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

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

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

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

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

почему это ?

Можно, конечно, использовать в качестве первичного нативные реквизиты.
На простых структурах. Но в "этажерках" такая технология приводит к многочисленным проблемам, связанным с необходимостью после изменения ключа в мастере править в дочерних таблицах поля-связки.
Или я не верно понимаю политику партии и правительства ?

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

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

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

ODAC/ запомнить и восстановить текущее положение в dataset Найти похожие ветки