Определение реального текущего номера записи таблицы

← →
msguns © (2005-12-07 10:21) [40]

>Gem (07.12.05 06:46) [25]
>Под текущим номером подразумевается номер записи, которая на настоящий момент обрабатывается
>А нужно мне это, чтоб знать сколько уже обработано записей из общего числа

Ну вот, теперь ясно..
Тебе нужен не "реально текущий номер записи таблицы" (сабж), а порядковый номер записи полученного НД (клиентского курсора). Но ведь это же - совсем другое дело !
Во-первых, поищи в архивах - относительно недавно хдесь была достаточно обширная ветка на эту тему.
Во-вторых, проблема такая есть и она полностью целесообразна, хотя и кажется некоторым форумчанам (тому же АП, к примеру) надуманной.
Сформулировать проблему можно так:
"Контроль позиции в курсоре НД". Для чего обычно надо две вещи:
1. Текущий № записи внутри текущего курсора
2. Количество записей в текущем курсоре

Выделение сделано умышленно, т.к. это - суть и ядро решения, которым ты, видимо, манкировал в своей программе.

← →
Gem (2005-12-07 10:28) [41]

> evvcom © (07.12.05 10:14) [37]
И где-то говорили про Last и снова First.
>

ты об этом?
With DataSet do begin Open; First; Last; StatusBar1.Panels[0].Text := "Всего записей - "+IntToStr(RecordCount); First; end;
а разве для RecordCount имеет значение, где находится курсор? зачем переходить из начала в конец, потом определять число записей, потом опять перемещаться в начало.

← →
evvcom © (2005-12-07 10:35) [42]

> Open;
> First;

Ну здесь First - лишний, так как Open и так на первую запись встает.

> а разве для RecordCount имеет значение, где находится курсор?
> зачем переходить из начала в конец, потом определять число
> записей, потом опять перемещаться в начало.

Для RecordCount имеет значение, сколько записей было получено с сервера. После Open различные реализации DataSet могут тянуть различное количество записей с сервера. Посмотри SQL Monitor вроде показывает, что происходит с наборами. Каждый Fetch - это одна запись. И только по необходимости выполняются остальные Fetch-и, увеличивающие RecordCount. Last заставляет профетчить все записи с сервера, устанавливая RecordCount в "правильное" значение.

← →
msguns © (2005-12-07 10:52) [43]

Итак, мы ввели понятие текущего курсора, под которым понимается ничто иное, как подмножество инф-ции из таблиц БД, полученное по запросу к БД НА МОМЕНТ ВЫПОЛНЕНИЯ ЗАПРОСА.
Другими словами, курсор НД показывает "клиенту" не текущее (актуальное) состояние БД, а то, которое БЫЛО на момент открытия запроса. След-но, НЕТ НИКАКИХ ГАРАНТИЙ, ЧТО СОСТАВ И СОДЕРЖИМОЕ ЗАПИСЕЙ ОТКРЫТОГО НА КЛИЕНТЕ КУРСОРА НЕ ИЗМЕНИЛОСЬ В ЛЮБОЙ МОМЕНТ ВРЕМЕНИ !!!
Это - раз.
Теперь - о "два". А именно о изменении "клиентом" записей курсора и реакции на это самого объекта доступа.
При удалении (вставке,изменении) записей в текущем курсоре мы имеем как минимум 2 проблемы: "синхронизации" изменений непосредственно с физической БД и адекватное отображение сделанного изменения в текущем курсоре. Т.е. надо не только "отослать" и проконтролировать "исполнение" изменений в таблице БД, но и отобразить сделанное изменение собственно у себя на клиенте. А вот тут-то и возникает первая трабла: при "обратной" связи может обнаружиться, что наш НД устарел и отличается от того, что был у нас ДО проведения изменения (а фактически на момент открытия).
Здесь важно учесть одну особенность: как "клиент" выполняет отображение изменений в курсоре, ведь он может делать это по-разному: либо извлечь из БД только измененную (добавленную) запись, либо просто переоткрыть весь запрос, по сути выполнив его по-новому.
В случае "одиночного выстрела" мы имеем высокую вероятность "лживости" данных в тек. курсоре ибо объект доступа не "затруднился" сделать полную ревизию ВСЕХ данных в курсоре. Зато мы не узрели никаких тормозов, что делает такую технологию весьма привлекательной при частых коррекциях данных курсора. Особенно если спроектировать интерфейс таким образом, чтобы максимально снизить вероятность межклиентских конфликтов. Как, например, в учетно-складских приложениях, работающих с ДОКУМЕНТАМИ на базе концепции "коррекция документа только с одного РМ".
В случае переоткрытия запроса мы очевидно получаем тормоза. Однако вместе с ними имеем и гарантию того, что непосредственно после изменения увидим актуальное состояние информации в БД. Такая технология предпочтительна в тех же складских программах при работе со справочниками или таблицами текущих остатков товаров. И то, и другое может меняться с неограниченного кол-ва РМ в любой момент времени, в то же время для нас важна актуальность данных.

Итак, мы имеем две технологии, принципиально по-разному контролирующими курсор (а след-но, и его параметры RecNo и RecordCount)
. При этом в большинстве случаев мы не можем знать точно, как отслеживает этот курсор тот объект, который мы используем в качестве метода доступа. Часто мы даже не имеем возможность явно им управлять в этом контексте. Именно поэтому многие предпочитают "ручками" делать как изменения, так и переоткрытия датасета после этих изменений. Такая технология хоть и несколько громоздка, зато обеспечивает полный контроль программы над курсором и, след-но, над его параметрами.

← →
msguns © (2005-12-07 10:56) [44]

>Gem (07.12.05 10:28) [41]
>а разве для RecordCount имеет значение, где находится курсор?

ДА !!!
Ибо далеко не всегда после открытия НД объект доступа "утруждается" самостоятельео "перебрать" и подсчитать полученные запросом записи.

>зачем переходить из начала в конец, потом определять число записей,

Затем, чтобы "заставить" TDataSet пересчитать полученніе записи курсора и записать в RecordCount верное для текущего курсора значение.

>потом опять перемещаться в начало.

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

← →
msguns © (2005-12-07 11:05) [45]

>Gem (07.12.05 10:28) [41]
>а разве для RecordCount имеет значение, где находится курсор?

Более того, под "ГДЕ" нужно понимать не только отосительную локацию курсора (смещение относительно базового адреса, по которому расположен в ОП буфер полученных данных), но и абсолютную ! Т.е. ГДЕ ИМЕННО находится этот самый буфер: непосредственно на "клиенте" или на "сервере". От этого очень зависит технология (и скрость соответсвенно) получения очередной записи курсора и, как следствие, значение параметров RecNo и RecordCount.
Одно технологии (например ADO) позволяют управлять выбором абсолютного местонахождения курсора, другие (BDE) делают это сами как считают нужным, оставляя нам право ругать или хвалить их за качество ;))

msguns © (07.12.05 10:21) [40]
Я посмотрю как это будет для хBase где порядковый номер записи в курсоре, как таковой отсутствует и именно о нем и идет речь, хоть автор это и усиленно скрывает. Есть реальный порядковый номер записи, но не в наборе, а в самой таблице, но от него нулевая польза для указаной задачи.

И второй момент установленый фильтр, опять же не приходится говорить ни о каком порядковом номер.

Зато вижу смутное упоминание об сколько записей обработано значит есть это знание и это не RecNo. Вот его и надо использовать для обработано N записей из RecordCount.
Если это значение не хранится в переменной, то самое время ввести эту переменную и наращивать ее по мере обработки записей.
RecordCount для xBase работает правильно и не требует перемещения в начало/конец.

А так как наезды не прекратились [36], не смотря на предупреждение, то тема закрывается до исправления политики автора в части задавания вопрос и ведения дисскуссии.

Определение реального текущего номера записи таблицы Найти похожие ветки