> Ega23 ©   (08.12.11 16:48) [156]
> Тем, что далеко не всегда данные зафетчены до конца.

А с какой стати это проблема?
Что мешает их зафетчить?
Что мешает пронумеровать только то, что зафетчено?


По этой же причине нету стандартного TDBTreeView, хотя казалось  бы...

По какой "этой же"? По причине недофетча? Почему эта причина помешала только борланду, а, например, девэкспресу не помешала?

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

> Inovet ©   (08.12.11 21:07) [159]


> В EhLib будет как везде - менять размер, положение и прочее
> стандартное поведение, если Dataset может показать количество
> записей и номер текущей.

Да я какбэ в курсе. В девэкспрессе так будет даже без последнего условия (ценой внутреннего кэша).

Сама вот эта отсылка: "А у нас Dataset такой" -- это кошмар-кошмар-кошмар.

> Спископодобные структуры ДОЛЖНЫ вести себя одинаково и предсказуемо
> для пользователя.


Тогда нужно вводить 2 абстрактных датасета. Один, фетчайший (или фетчеший?) записи до конца, и "какой-то другой", получающий записи по частям. Тогда проблемы никакой нет.
Если взять TClientDataSet в связке с DBGrid, то скролл будет ровно на том месте, где должен быть. Вроде. Или это TRxDBGrid? Проверять лень.

> По какой "этой же"? По причине недофетча? Почему эта причина
> помешала только борланду, а, например, девэкспресу не помешала?


потому что нет никакой гарантии, что НД будет отсортирован по ParentID.
Если такая гарантия есть, либо мы используем DataSet, который фетчит записи до конца - TDBGrid вполне возможен и даже православен.
Но на том уровне абстракции, который принят за основу в Борланд, это нереально.

ТС уже на попкорн смотреть не может.

> ТС уже на попкорн смотреть не может.

1. antonn' а забанить, ибо он вносит смуту.
2. Никакая нумерация в визуальном компоненте показывающем набор данных не нужна, ибо она неестественна и ведёт к путанице.
3. DiamondShark'а тоже забанить.
:)

> Ega23 ©   (08.12.11 23:48) [162]
> Тогда нужно вводить 2 абстрактных датасета.

Бинго!

Только не датасета. Первая вещь -- это курсор, причём, от него не требуется функциональности больше, чем FORWARD_ONLY READ_ONLY, вторая -- локальный кэш с произвольным доступом.

Локальный кэш, разумеется, получается независимым от источника данных. Так же, у него отсутствует вся эта навигационная лабуда, вроде "текущей записи", MoveNext, MoveFirst, MoveLast, MoveToGlanulaPerRectum и т.п.

Навигация выносится в третий компонент, который имеет смысл только при биндинге с навигационным юзер-интерфейсом.

Особую пикантность ситуации придаёт тот факт, что конкретные датасеты таки выфетчивают и кэшируют данные.
БДЕ -- кэширует. По крайней мере, при работе через SQL Links, как оно там с ДБФ работет -- не знаю, может шаромыжится по файлу.
АДО -- кэширует.
Кто там у нас ещё есть?

Борландовские компоненты доступа к данным -- шиза полная.


> Ega23 ©   (08.12.11 23:52) [163]
> потому что нет никакой гарантии, что НД будет отсортирован по ParentID.

Нет никакой необходимости сортировать НД по ParentID.


> Если такая гарантия есть, либо мы используем DataSet, который
> фетчит записи до конца - TDBGrid вполне возможен и даже
> православен.

Хоспиддя...
Ну какая разница, до чего фетчит DataSet? Это, вообще-то, деталь реализации, которая от пользователя абстрактного датасета скрыта.
Есть гарантия, что датасет вернёт запись, если она существует (это сродни утверждению, что вода -- мокрая). Этого достаточно.


> Но на том уровне абстракции, который принят за основу в
> Борланд, это нереально.

У борланда принята не абстракция, а шиза.
В одном компоненте густо замешаны разные вещи:
1. Общение с источником данных, которому, если по абстракции, должно быть плевать на способ дальнейшего использования данных
2. Локальный кэш, которому должно быть плевать на детали реализации источника данных
3. Навигация, на которую плевать первым двум, и которой плевать на детали реализации первых двух.

Вся эта мутотень затеяна с единственной сомнительной целью: упихать в одну "абстракцию" работу с локально-файловыми и клиент-серверными БД.

> Борландовские компоненты доступа к данным -- шиза полная.

Предложи лучшие компоненты.

> Германн ©   (09.12.11 01:22) [167

ADO.NET

> Нет никакой необходимости сортировать НД по ParentID.


Нет никакой гарантии, что ParentNode придёт раньше, чем его Child.


> У борланда принята не абстракция, а шиза.


С альтернативами как-то не айс.
Я что-то вообще разочаровался во всех этих датасетах. Особенно, пристально поизучав DB.pas

> Предложи лучшие компоненты.


ORM

> Ega23  (08.12.2011 23:48:42)  [162]

Для того что бы курсор был там где надо, требуется клиентский курсор и
полная загрузка
С TClientDataSet это гарантировано, поскольку in memory
С АДО по вышеуказаным правилам, с БДЕ не возможно, поскольку клиентского
курсора нет, поэтому только три положения.

> DiamondShark  (09.12.2011 01:37:48)  [168]

Меня там смущает их терминология, то что называется датасет, на самом деле
схема данных и запросы
То что называется datasource у нас датасет

> Меня там смущает их терминология
а меня еще смущает "урезаность" этого эталона, вроде позже делали на основе ADO, а ничего не добавили, только убрали все схемы работы кроме одного. (оставленная ближе всего, в ADO/Delphi похожа на "спарку" TClientDataSet + TADODataSet через провайдер данных, т.е. серверный курсор у ADODanaSet-а чтобы быстро открывалось, и докачка в локальный клиентский чтобы "обеспечить номера записей"(в данном случае, в общем конечно объяснение будет другое))

ситуация похожа, ИМХО, на внедрение коробок автоматов в авто... насильно, то что профи с ним не смогут добиться того, что им нужно, выжать всех возможностей, не выиграют гонку... пофигу. и вообще все знающие "идут лесом", пользуйтесь как все, и не выделывайтесь.

Все это конечно ребят я прочитал. И конечно вроде как нашел как нумерацию в самом запросе делать - тормозит ужасно если делать так, как в инете пишут. Теперь конкретно - есть условие. ОБЯЗАТЕЛЬНОЕ. Установлено правилами - нумерация должна быть. Долго советовался с народом - все сказали - нам плевать на правила "программирования" - МЫ пользуем твою программу. Нам нумерация нужна. Согласен с ними на 100% - если пишешь программу для пользователей подход типа "я тут накодил, а вы тупые, не понимаете что так правильно" - не катит.


> Только что кинул на форму ADOTable, открыл в ней таблицу
> "Товары" из базы данных "Борей", создал вычисляемое поле:
>
>
> procedure TForm1.ADOTable1CalcFields(DataSet: TDataSet);
>
> begin
>  ADOTable1RCNO.AsInteger := ADOTable1.RecNo;
> end;
>
> Всё нормально нумеруется.
>
> У вас какой-то непраильный ADO+Access.


Без обид - давай все же друг друга не будем считать идиотами. И если моей программой пользуются во многих странах мира - то значит я знаю, что пишу.
Сделай пару сотен записей в базу, а потом по PageUp/PageDown по ним поперемещайся.

> [174] Alex_C   (11.12.11 22:43)
> есть условие. ОБЯЗАТЕЛЬНОЕ. Установлено правилами - нумерация должна быть.

По правилам в логе должна быть, я думаю так, а это значит добавить поле Integer в таблицу лог и всё - и это правильное решение. О чём тут и дискутировали. Иначе я не понимаю зачем.

> И если моей программой пользуются во многих странах мира
> - то значит я знаю, что пишу.

Пока что в "Начинающих" спрашиваешь ты.
Если ты такой крутой, то не ходи в "Начинающие", а иди лесом. По слогам: "ле-сом", первая буква "Х".

> Alex_C  

в DbGridEh есть нумерация. И работает.

Только она не нужна как уже правильно сказали.

> [174] Alex_C   (11.12.11 22:43)
> Долго советовался с народом - все сказали - нам плевать
> на правила "программирования" - МЫ пользуем твою программу.
> Нам нумерация нужна.

Они явно о другой нумерации говорили. Это не по "правилам программирования", а из простой логики не нужна такая нумерация, другая нужна.

> есть условие. ОБЯЗАТЕЛЬНОЕ. Установлено правилами - нумерация должна быть.
это не объяснение для "технической  интеллигенции"... это скорее "красная тряпка", чтобы "по бодаться". ты мне так менеджеров этим напоминаешь. не доходит что ли? никаких "так надо", "юзер так хочет" , "установлено правилами" и т.д. не принимается в логическом споре... только логические аргументы.
особенно когда у народа ОПЫТ, и он часто плачевный, т.как стоит сделать "именно так" так сразу "что за фигня? мы имели в виду не это". или это, но тогда до первой проблемы,  и "а ты что не мог настоять? мы то не местные, мы не понимаем...", а то что сделать чуть ли не с пистолетом "уговаривали", сразу "забывается".  

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