Конференция "Базы" » ODAC/ запомнить и восстановить текущее положение в dataset [D7]
 
  • 12 © (23.03.10 16:26) [0]
    Как можно запомнить и восстановить текущее положение в dataset?
    Пытаюсь избавится от последствий Refresh, которое использую
    для отображения внесенных только что записей

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

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

    Не работал с ODAC вообще, может как-то по-другому проще?
  • Медвежонок Пятачок © (23.03.10 16:38) [1]
    стандартно. букмарками.
  • Sergey13 © (23.03.10 16:39) [2]
    > [0] 12 ©   (23.03.10 16:26)

    Вноси данные через датасет - ничего рефрешить не надо.
  • 12 © (23.03.10 16:57) [3]
    понятно.
    просто там гораздо больше св-в у TOraххх чем у TADOххх
    думал что-то есть такое
  • Правильный$Вася (24.03.10 00:27) [4]

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

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

    locate по первичному ключу в датасете
  • Медвежонок Пятачок © (24.03.10 09:16) [5]
    этот общий случай происходит раз в тысячу лет.
    у меня букмарки всю дорогоу были валидны.

    кроме того, никто не запрещает делать проверку избукмарквалид.
    и если валид, то делать гоуту букмарк.
  • Anatoly Podgoretsky © (24.03.10 10:25) [6]
    > Медвежонок Пятачок  (24.03.2010 09:16:05)  [5]

    В рубашке родился
  • Правильный$Вася (24.03.10 10:26) [7]

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

    значит тебе везет
    ибо это всего лишь адрес из той области памяти, которую занимали данные до переоткрытия датасета
    и нет никаких гарантий, что после переокрытия данные не окажутся в другой области памяти или по этому адресу будут другие данные
  • sniknik © (24.03.10 10:32) [8]
    > кроме того, никто не запрещает делать проверку избукмарквалид.
    > и если валид, то делать гоуту букмарк.
    зачем усложнять если можно просто
    > locate по первичному ключу в датасете
  • Медвежонок Пятачок © (24.03.10 10:53) [9]
    а потому что.

    букмарки универсальнее. можно иметь библиотечный код и прикручивать его к любому датасету.
    а в случае локейта надо каждый раз программировать конкретный датасет (массив имен и значений колонок первичного ключа)
  • Anatoly Podgoretsky © (24.03.10 11:37) [10]
    > Медвежонок Пятачок  (24.03.2010 10:53:09)  [9]

    Код с Locate даже короче и проще чем с букмарк
  • Правильный$Вася (24.03.10 11:39) [11]

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

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

    кстати, ТПервичныйКлюч ненамного сложнее ТБукмарк для использования в библиотеке
  • Медвежонок Пятачок © (24.03.10 12:09) [12]
    объединение из трех таблиц.
    присутствуют первичные ключи из всех трех.
    все три ключа составные.

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

    я понимаю, что это (как и все остальное) не намного сложнее чем букмарк.
  • Правильный$Вася (24.03.10 12:49) [13]

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

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

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

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

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

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

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

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

    как говорится: "кто хочет - ищет способы, кто не хочет - ищет причины"
  • 12 © (24.03.10 14:15) [14]
    TBookmark заюзал
    не самолеты пишу, а собьется раз в пятилетку - фиг с ним
  • MsGuns © (24.03.10 16:43) [15]
    За рекомендацию пользоваться букмарками при переоткрытии датасета медвежонку надо по тятачку
    :)
  • Правильный$Вася (24.03.10 17:29) [16]

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

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

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

    симметричное клеймо с противоположной стороны поставить, чтоб всем видно было, куда метить
  • Медвежонок Пятачок © (24.03.10 18:33) [17]
    и чо? все три первичных ключа таблиц дают первичный ключ набора данных
    если нет, то обрабатывать это бессмыссленно - плохое проектирование


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

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

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

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

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

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

    А что сделаете вы?
  • Игорь Шевченко © (24.03.10 19:00) [18]

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


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

    А что, собсна, она ДОЛЖНА знать ?
  • MsGuns © (24.03.10 19:22) [20]
    К комментариям-"отмазкам" Медвежонка:

    Если НД РЕДАКТИРУЕТСЯ, то, надо полагать, редактируется ОДНА таблица, а не несколько (иначе - "старуха с клюкой" (с))
    А если таблица ОДНА, то и с идентификаторм проблем быть не должно.
  • Медвежонок Пятачок © (24.03.10 20:15) [21]
    А что, собсна, она ДОЛЖНА знать ?

    Да ничего.
    Есть TDataSet
    Нужно закрыть его и открыть. После чего восстановить текущую запись которая была перед закрытием
  • Игорь Шевченко © (24.03.10 20:44) [22]

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


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

    Е-е-ето как ето ?
  • Медвежонок Пятачок © (24.03.10 21:14) [24]
    В общем случае невозможно. Ее могут удалить

    Ядерного взрыва не произойдет.
    Либо букмарквалид будет false, либо датасет отпозиционируется не совсем туда куда хотелось бы.
    Так как сама фича из области бантиков и рюшечек, на приложение это никак не повлияет. Ткнет юзер мышкой куда ему надо если курсор не там где он ожидает. И все.
  • Медвежонок Пятачок © (24.03.10 21:15) [25]
    Е-е-ето как ето ?

    Это встать курсором на ту же запись, на которой стоял курсор перед рефрешем датасета.
  • Игорь Шевченко © (24.03.10 21:22) [26]
    Медвежонок Пятачок ©   (24.03.10 21:14) [24]


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


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


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


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


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


    Мы из этих соображений не позиционируемся на последнюю запись, где оно стояло. Обновляет пользователь, так обновляет, сам, его никто не заставляет, поэтому попадает на начало Dataset-а.
  • Медвежонок Пятачок © (24.03.10 21:34) [27]
    А откуда оно узнает, false ему надо становиться или не false ?

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

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

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

    Если я и не применял эту фичу, то не потому что не работало, а потому что либо это было ненужно, либо излишне напрягало сервер.
  • MsGuns © (24.03.10 22:58) [28]
    Сыр-бор оттого, что при редактировании в гриде нехило б было сделать юзеру банально приятно,- чтоб он после завершения редактирования (вставки, удаления) записи не терял то место, где он редактировал. Желание, кстати, вполне понятное, вопреки мнению некоторых тут. В самом деле, представьте, что после вставки в исходник новой строки вас перебрасывали бы в начало кода :)

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

    Закладываться на метод, работающий только "по погоде" - это подставить юзера. Причем, как обычно, "глюк" вылезет в самый неподходящий момент.
    Не проще ли сразу делать правильно и надежно, не полагаясь на пресловутое "я так всегда делал - и ничего" ?
  • Медвежонок Пятачок © (25.03.10 01:27) [29]
    правильно и надежно - это кто вообще определил?
    редактируем запись.
    меняем значения полей.
    в том числе возможно и ключевых.
    и чем локейт в этом случае правильнее букмарка?
  • Anatoly Podgoretsky © (25.03.10 05:21) [30]
    > Медвежонок Пятачок  (24.03.2010 21:14:24)  [24]

    После позиционирования куда не надо, произойдет редактирование чего не надо.
  • Anatoly Podgoretsky © (25.03.10 05:23) [31]
    > Медвежонок Пятачок  (25.03.2010 01:27:29)  [29]

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

    Если редактируется праймари, то это и есть "старуха с клюкой".
    Использование UID поможет предводителю дворянства
  • Медвежонок Пятачок © (25.03.10 10:06) [34]
    то есть естественные праймари кей не имеют права на существование?
  • MsGuns © (25.03.10 10:35) [35]
    Я бы не смешивал понятие "праймари" (первичный) и "нативный" (естественный, сущностный)
  • Медвежонок Пятачок © (25.03.10 11:02) [36]
    и я не смешиваю.
    праймари кей может редактироваться.
    особенно если он естественный а не искусственный
  • Правильный$Вася (25.03.10 13:03) [37]

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

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

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

    короче, проще 10 лет облеплять кизяком стену, чтоб не упала, чем за месяц построить новую, так?
  • Игорь Шевченко © (25.03.10 14:01) [38]

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


    почему это ?
  • MsGuns © (25.03.10 14:34) [39]
    Можно, конечно, использовать в качестве первичного нативные реквизиты.
    На простых структурах. Но в "этажерках" такая технология приводит к многочисленным проблемам, связанным с необходимостью после изменения ключа в мастере править в дочерних таблицах поля-связки.
    Или я не верно понимаю политику партии и правительства ?
  • Правильный$Вася (25.03.10 18:17) [40]

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

    потому что кроме гипотетической экономии памяти никаких плюсов больше нет
    да и в сторону мы уходим, это уже десятки раз перетирали и каждый остался при своем
    я предпочитаю суррогатные первичные ключи, а то, что может претендовать на натуральный первичный ключ, просто делаю уником
    гораздо гибче во многих случаях - можно и на то опереться, и на это, зависит от логики конкртной задачи
    и даже если вдруг окажется, что натуральный ключ уже не совсем ключ, ничего не развалится, в отличие от противников суррогата
  • Anatoly Podgoretsky © (25.03.10 19:59) [41]
    > Медвежонок Пятачок  (25.03.2010 10:06:34)  [34]

    Да никакие изменения первичного ключа не являются проблемой. Надо чтобы форма редактирования/вставки возвращала правильный номер. Это еще один плюс в пользу редактирования в отдельной форме.
  • Anatoly Podgoretsky © (25.03.10 20:00) [42]
    > MsGuns  (25.03.2010 14:34:39)  [39]

    Не приводит, если использовать cascade updates, а я не вижу причины не использовать их
  • Anatoly Podgoretsky © (25.03.10 20:01) [43]
    > Правильный$Вася  (25.03.2010 18:17:40)  [40]

    И у тебя получается дублирование
  • Игорь Шевченко © (25.03.10 20:11) [44]
    Правильный$Вася   (25.03.10 18:17) [40]


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


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

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

    Телега хорошо едет с четырьмя колесами.
  • Правильный$Вася (25.03.10 20:29) [45]

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

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

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

    лучше продублировать 1 поле GUID, чем  ссылаться на 10 полей из многих разных таблиц
    экономия памяти, нервов и времени огромная
  • Anatoly Podgoretsky © (26.03.10 07:36) [46]
    > Правильный$Вася  (25.03.2010 20:29:45)  [45]

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

    Каждый "этаж" - одно поле. 10-этажный "небоскреб" - 10 полей в "пентхаузе" :)
  • Правильный$Вася (26.03.10 11:13) [48]

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

    если PK составной, то в связи не может быть его часть, верно ведь?
  • evvcom © (26.03.10 14:34) [49]
    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-й, а для работы после изменений значений входных параметров!
 
Конференция "Базы" » ODAC/ запомнить и восстановить текущее положение в dataset [D7]
Есть новые Нет новых   [134433   +22][b:0.001][p:0.003]