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

← →
DiamondShark © (2011-12-08 21:12) [160]

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

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

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

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

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

← →
DiamondShark © (2011-12-08 21:17) [161]

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

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

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

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

← →
Ega23 © (2011-12-08 23:48) [162]

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

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

← →
Ega23 © (2011-12-08 23:52) [163]

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

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

← →
Inovet © (2011-12-09 00:25) [164]

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

← →
Германн © (2011-12-09 01:00) [165]

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

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

← →
DiamondShark © (2011-12-09 01:20) [166]

> 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:22) [167]

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

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

← →
DiamondShark © (2011-12-09 01:37) [168]

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

ADO.NET

← →
Ega23 © (2011-12-09 09:14) [169]

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

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

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

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

← →
Ega23 © (2011-12-09 09:15) [170]

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

ORM

← →
Anatoly Podgoretsky © (2011-12-09 10:48) [171]

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

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

← →
Anatoly Podgoretsky © (2011-12-09 11:13) [172]

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

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

← →
sniknik © (2011-12-09 12:57) [173]

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

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

← →
Alex_C (2011-12-11 22:43) [174]

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

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

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

← →
Inovet © (2011-12-11 23:12) [175]

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

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

← →
DiamondShark © (2011-12-11 23:36) [176]

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

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

← →
DVM © (2011-12-11 23:46) [177]

> Alex_C

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

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

← →
Inovet © (2011-12-12 00:00) [178]

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

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

← →
sniknik © (2011-12-12 01:00) [179]

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

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

← →
Alex_C (2011-12-17 00:35) [180]

> Пока что в "Начинающих" спрашиваешь ты.

Тут отвечают лучше и меньше хамят.

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

Использую версию 3... какую-то еще бесплатную. Там есть, не в курсе? Но если что - и в новых посмотрю.

> "установлено правилами" и т.д. не принимается в логическом
> споре...

Установлено правилами любительской радиосвязи о ведении аппаратного журнала. Установлено еще для бумажного образца. Но от сюда и все ноги растут.
Теперь реально: наверное у нас радиолюбителей из тех, давних времен пошла привычка, что у связи длжен быть номер. И ОСНОВНАЯ сортировка - по времени.

> p.p.s. для международного уровня слабоват... простейшая
> задача, в одну строку, и так долго "решаешь".

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

← →
Inovet © (2011-12-17 00:55) [181]

> [180] Alex_C (17.12.11 00:35)
> давних времен пошла привычка, что у связи длжен быть номер

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

← →
Alex_C (2011-12-17 01:00) [182]

> Повторяю в непоню какой раз

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

← →
Андреевич (2011-12-17 09:42) [183]

> как неотъемлемово атрибута связи

а если не неотъемлемого? навроде того как иногда раскрашивают строки в зависимости от данных в них хранящихся :)

← →
Inovet © (2011-12-17 10:20) [184]

> [183] Андреевич (17.12.11 09:42)
> > как неотъемлемово атрибута связи
>
> а если не неотъемлемого?

Автор сказал - неотемлемый, только другими словами. Оно так и есть - в аппаратном журнале каждый сеанс связи должна быть под своим порядковым номером. Как там насчёт пропусков номеров - не знаю, вообще-то не должно быть.

← →
Андреевич (2011-12-17 10:27) [185]

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

← →
Inovet © (2011-12-17 10:44) [186]

> [185] Андреевич (17.12.11 10:27)
> Мне кажется он это имел ввиду

Нет, речь о номере в журнале.

> [180] Alex_C (17.12.11 00:35)
> что у связи длжен быть номер. И ОСНОВНАЯ сортировка - по времени.

Вчера уже не стал спрашивать. Номер вообще-то логически лишний, раз есть время, но это номер документа, значит надо его хранить в базе. А вопрос такой: из отцитированоого можно заключить, что порядок по номеру может не совпадать с порядком по времени?

← →
Alex_C (2011-12-17 11:35) [187]

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

Это очень обсуждаемая тема у радиолюбителей. Раньше каждая проведенная радиосвязь в журнале на бумаге должна была иметь номер. Как правильно было сказано - как номер документа. Конечно, раньше же нельзя было на бумаге пересортировывать связи)))
Теперь есть 2 варианта:
1. Динамимеский номер - зависит от сортировки. Пересортируем - номер уже другой. Но он есть
2. Статический номер - типа id связи - но тут есть много проблем, допустим как быть при слиянии нескольких логов, если человек из разных мест работает.
В результате вроде как пришли к мнению пусть будет 1.

Ну да ладно. Я вчера вообще эту котонку убрал и номер связи вывожу на статусбаре. Но даже в этом случае проблема то осталась: при вводе новой связи ее номер высвечивается как -1. Чтоб номер стал правильным, ножно скроллинг сделать.

← →
Inovet © (2011-12-17 11:58) [188]

> [187] Alex_C (17.12.11 11:35)
> 1. Динамимеский номер - зависит от сортировки. Пересортируем
> - номер уже другой. Но он есть
> 2. Статический номер - типа id связи - но тут есть много
> проблем, допустим как быть при слиянии нескольких логов,
> если человек из разных мест работает.
> В результате вроде как пришли к мнению пусть будет 1.

Значит чётких требований нет, есть только привычка юзеров видеть такую колонку с номером, а то что в ней цена на дрова, так лишь бы что было. Убрал - и правильно, они поймут, что им это не надо.

← →
Андреевич (2011-12-17 12:01) [189]

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

вот я и говорю - лишь для наглядности

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

Не прошло и недели, как ты сподобился поделиться деталями предметной области.

Реально твой номер -- это атрибут данных. Он должен быть реальным полем.

> Но даже в этом случае проблема то осталась: при вводе новой
> связи ее номер высвечивается как -1.

Как высвечиваешь -- так и высвечивается.
Не нравится "-1" высвечивай "Новая запись".

> Чтоб номер стал правильным, ножно скроллинг сделать.

Врёшь. Чтоб номер стал правильным, нужно Post сделать, что, вообще говоря, логично: невведённая запись ещё не существует.

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

> Как правильно было сказано - как номер документа.
номер документа <> номер записи.

> и номер связи вывожу на статусбаре.
фигню ты выводишь, а не номер связи.

p.s. почему спрашивая про одно имеют ввиду совсем другое? а на попытки выяснить, что, начинается всякая хрень, но не раскрытие темы.

← →
Андреевич (2011-12-17 19:23) [193]

> 2. Статический номер - типа id связи - но тут есть много
> проблем, допустим как быть при слиянии нескольких логов,
> если человек из разных мест работает.

может тогда уникальным полем сделать guid? разумеется нет смысла его отображать, но и в разных базах его не будет (теоретически), выборка по дате и все такое..

> Inovet (17.12.2011 10:20:04) [184]

Именно поле НомерСвязи, а не нумерация в гриде. Может быть автоинкриментное
поле. Пропусков в принципе быть не может - записи не удаляются никогда, а
заносятся только по окончанию связи, то есть только завершенные связи, а
завершенной связь считается после обменая информацией о сигнале (RST).

> Андреевич (17.12.2011 10:27:05) [185]

Возможности удаления записи не должно быть!

> Inovet (17.12.2011 10:44:06) [186]

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

> Alex_C (17.12.2011 11:35:07) [187]

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

> Inovet (17.12.2011 11:58:08) [188]

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

> sniknik (17.12.2011 18:52:12) [192]

Удаление равносильно подделке журнала.

← →
Андреевич (2011-12-17 19:59) [200]

> Возможности удаления записи не должно быть!

это ТС сказал?

Пронумеровать записи Найти похожие ветки