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

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

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

Сортировка ADODataSet [MSSQL]

Страницы: < 1 2 3 4 5 >
Ega23 © (2007-03-13 16:35:00)
Есть ADODataSet с открытым набором данных.
Как его сортировать по разным столбцам на клиенте, не переоткрывая? IndexDefs добавлять?

Kostafey (2007-04-17 16:00:00) [21]
> массив соответствий "имя поля"="русское название" по нему и заменить

А как же быть если этого поля не окажется в наборе данных?

Jan1 (2007-04-17 15:58:00) [22]
что профайлер говорит.

Jan1 (2007-04-17 15:58:00) [23]

> ADODataSetMeropr.Properties['Resync Command'].Value :=..
> .

что там?

Kostafey (2007-04-17 15:57:00) [24]
> [35] Jan1 (17.04.07 12:28)

> http://delphikingdom.ru/asp/viewitem.asp?catalogid=420

Странно. Сделал все как в статье.
Настроил
ADODataSetMeropr.Properties['Unique Table'].Value := 'Meropr';
ADODataSetMeropr.Properties['Resync Command'].Value :=...

А программа ведет себя как в случае (как сказано в статье) если бы не было
настроено свойство Resync Command.
Т.е. изменяю поле FK_id, а прочие поля не изменяюся.

Jan1 (2007-04-17 15:56:00) [25]

> а если требование именно такое?

но только на редактирование а не на просмотр! вот нужно данные для отчета выбрать - Вы что опять будете лукап-поля тулить?

Jan1 (2007-04-17 15:54:00) [26]

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

опять же неудобство делфийского лукап-поля при больших(даже на 100 записах) это делать ой как не юзабительно :(

Jan1 (2007-04-17 15:53:00) [27]

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

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

sniknik (2007-04-17 15:52:00) [28]
> Я надеялся, что есть болле простые решения.
убери вообще из грида предопределения столбцов, создадутся автоматом при открытии таблицы. а "дисплейлебел" можно заменить в событии afteropen таблицы... сделать массив соответствий "имя поля"="русское название" по нему и заменить (а то и вообще в таблице держать. и пусть юзеры сами переводят. а если посложнее структуру записи сделать то можно и основные настройки держать... и все при единообразном подходе)

Jan1 (2007-04-17 15:47:00) [29]

> Да никаких обид, только, имхо, это не от масштаба зависит,
> а от конкретной потребности пользователей и устройства
> БД.

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

Jan1 (2007-04-17 15:46:00) [30]

> Я надеялся, что есть болле простые решения. А от бывало
> делаешь что-то,
> а потом оказывается то же самое можно было бы сделать в
> 2 раза проще, в
> 3 раза быстрее и результат был бы эффективнее, я так получается
> удаление
> гланд через ухо и велосипедоизобретательство. Только и всего.
>

есть, но они денег стоят. или самим писать или купить...

sniknik (2007-04-17 15:46:00) [31]
> Скажите есть у Вас таблицы которые между собой завязаны и записей там по 100 тыс?
да, у меня и поболее есть (5-6 млн) и в них почти все поля берутся из справочников, поля "расшифровки признака", статус, адрес (город,область,регион), и т.д. по сравнению с размером основной все они мизер... (суть вся основная это просто различные комбинации ссылок на справочники)

> Показываете ли Вы такую связку пользователю, если да то как? Через лукап или нет?
по необходимости, и так и так бывает, внесение(/редактирование) полей обычно из лукапа, выбором (руками такие поля не даю забивать, вот те что принадлежат таблице пожалуйста (например адрес - "улица дом кв". они практически уникальны и в справочник не выносятся)).

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

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

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

Megabyte (2007-04-17 15:43:00) [32]

> Jan1 (17.04.07 14:54) [45]

2 Megabyte © (17.04.07 14:37) [44]
Для начального уровня создания приложений вполне, но никак не с промышленными базами. Так для курсовиков и небольших фирм... Без обид.

Да никаких обид, только, имхо, это не от масштаба зависит, а от конкретной потребности пользователей и устройства БД.

Kostafey (2007-04-17 15:32:00) [33]
> что ж трудно Вам прийдется...

<offtop>
Зря Вы так.
Автоматизация вообще появилась из-за человеческой лени.

Я надеялся, что есть болле простые решения. А от бывало делаешь что-то,
а потом оказывается то же самое можно было бы сделать в 2 раза проще, в
3 раза быстрее и результат был бы эффективнее, я так получается удаление
гланд через ухо и велосипедоизобретательство. Только и всего.
</offtop>

Jan1 (2007-04-17 15:26:00) [34]

> Лень.

что ж трудно Вам прийдется...

Kostafey (2007-04-17 15:22:00) [35]
> кто тебе мешает это сделать в рантайме?

Лень.

Да и вообще, программка того не стоит. Наверное...

Jan1 (2007-04-17 15:18:00) [36]

> А как? Мы насоздавали полей в наборе данных например все
> поля одной таблицы.
> Настроили их свойства.
> Открыли НД с полным набором полей, смотрим в DBGrid и радуемся.
>

кто тебе мешает это сделать в рантайме?

Kostafey (2007-04-17 15:12:00) [37]
> скакой это радости?

А как? Мы насоздавали полей в наборе данных например все поля одной таблицы.
Настроили их свойства.
Открыли НД с полным набором полей, смотрим в DBGrid и радуемся.
Открыли НД с не полным набором полей получаем ошибку про те заранее введенные TFiled,
для которых в этом запросе не получены данные.

Jan1 (2007-04-17 15:05:00) [38]

> Понятно, что нехорошо, но СУБД локальная практически нет
> требований к производительности.

Еще одно заблуждение :(

> Ведь если у нас в Наборе данных будет разное количество
> полей (в зависимости от запросов
> пользователя), то создавать TField в Наборе данных будет
> уже невозможно.

скакой это радости?

Kostafey (2007-04-17 14:55:00) [39]
> Очень плохое заблуждение. Очень. Нужно создавать поля по
> требованию и делать перезапрос если юзвер добавил новые
> поля, если убрал, то делать перезапрос не надо.

Понятно, что нехорошо, но СУБД локальная практически нет требований к производительности.
Кроме того делать перезапросы при изменении сиска полей само по себе добавляет ручной
работы, но так и не отвечает на вопрос как настраивать такие глупости как DiplayLabel.
Ведь если у нас в Наборе данных будет разное количество полей (в зависимости от запросов
пользователя), то создавать TField в Наборе данных будет уже невозможно.

Это что же предлагаете динамически настраивать DiplayLabel в DBEhGrid в зависимости от
получаемого списка полей? Неужели действительно проще нельзя ?

Jan1 (2007-04-17 14:54:00) [40]
2 Megabyte © (17.04.07 14:37) [44]
Для начального уровня создания приложений вполне, но никак не с промышленными базами. Так для курсовиков и небольших фирм... Без обид.

Страницы: < 1 2 3 4 5 >

Наверх

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