Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Пронумеровать записи [Access]

Страницы: < 1 2 3 4 5 6 7 8 9 10 11 >
Alex_C © (2011-12-07 16:06:00)
Так правильнопронумеровать записи в таблице при выводе пользователю? Делал на CalcFields
if LogTable.RecNo <> -1 then LogTableNumer.AsInteger := LogTable.RecNo else if LogTable.Bof then LogTableNumer.AsInteger := 1 else if LogTable.Eof then LogTableNumer.AsInteger := LogTable.RecordCount;
До использования ADO+Access работало. Сейчас первую и последнюю запись неправильно нумерует - первую как номер последней записи, последнюю - как 1

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

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

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

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

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

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

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

Anatoly Podgoretsky (2011-12-09 11:13:00) [44]
> DiamondShark (09.12.2011 01:37:48) [168]

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

Anatoly Podgoretsky (2011-12-09 10:48:00) [45]
> Ega23 (08.12.2011 23:48:42) [162]

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

Ega23 (2011-12-09 09:15:00) [46]

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

ORM

Ega23 (2011-12-09 09:14:00) [47]

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

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

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

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

DiamondShark (2011-12-09 01:37:00) [48]

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

ADO.NET

Германн (2011-12-09 01:22:00) [49]

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

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

DiamondShark (2011-12-09 01:20:00) [50]

> 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. Навигация, на которую плевать первым двум, и которой плевать на детали реализации первых двух.

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

Германн (2011-12-09 01:00:00) [51]

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

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

Inovet (2011-12-09 00:25:00) [52]
ТС уже на попкорн смотреть не может.

Ega23 (2011-12-08 23:52:00) [53]

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

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

Ega23 (2011-12-08 23:48:00) [54]

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

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

DiamondShark (2011-12-08 21:17:00) [55]

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

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

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

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

DiamondShark (2011-12-08 21:12:00) [56]

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

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

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

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

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

Inovet (2011-12-08 21:07:00) [57]
> [158] DiamondShark © (08.12.11 20:56)
> в стандартном дбгриде при прокрутке
> > не елозит так же ожидаемо для Мариванны, как он елозит,
> скажем, в листвью или в стрингриде.
>
> А вот это уже техношовинизм и инженерный кретинизм.

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

DiamondShark (2011-12-08 20:56:00) [58]

> > неспроста из дбгрида убрана нумерация

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

А вот это уже техношовинизм и инженерный кретинизм.

Спископодобные структуры ДОЛЖНЫ вести себя одинаково и предсказуемо для пользователя.
А то что там в дельфях с прошлого века шизофреничные компоненты -- так это половые трудности исключительно упоротых дельфистов.

sniknik (2011-12-08 17:27:00) [59]
> Ну так это же ты правил)
> А бестолковые пацаны из Борланда до этого ж не дотумкали))
ну, я бы тоже не стал, если бы "Мариванны" это как-то по своему понимали, и из-за разночтений появлялись бы проблемы...
т.е. нет знака равенства между "интефейсное поведение" и "непонятные данные, в которых для каждого свой смысл". для меня во всяком случае. хотя, если хотят, могут выгрузить в excel там нумерация есть.

Ega23 (2011-12-08 16:48:00) [60]

> Так а чем мешает дбгрид нумерации?
> Есть к примеру xml, загрузили его в клиентдатасет, подключили
> дбгрид, почему нумерация сразу же не пройдет?

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

Страницы: < 1 2 3 4 5 6 7 8 9 10 11 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »