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

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

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

Ширина столбцов в DBGrid. [D5, Win2k]

Андрей © (2004-07-07 10:44:00)
Простой, но жутко важный для меня вопрос. Подскажите, как заставить DBGrid устанавливать ширину поля (отображаюшего строковую запись) в соответствии с длинной самой большой записи в нём, а не по количеству знакомест, зарезервированых в таблице.

evvcom (2004-07-07 12:53:00) [1]

> вполне возможно использовать и DataSet.Next.

Возможно, да, а возможно и нет. Я сталкивался с запросами, которые возвращают несколько тысяч записей (ФИО, отсортированные по алфавиту, и прочие связанные с этим поля). Если здесь пробегать по всем записям Next-ом, то к тормозам сервера добавятся значительные тормоза клиента.

Sandman25 (2004-07-07 12:29:00) [2]
[8] evvcom © (07.07.04 12:27)

Что неверный подход - это понятно. Но я о том и говорю, что при верном подходе уже будет вполне возможно использовать и DataSet.Next.
Отключить обработчики "ненужных" событий типа OnCalcField и Before/AfterScroll и "отображатели", а затем пробежаться по 50 записям займет оченьмало времени. Незачем лишний раз сервер нагружать, если вся инфо и так уже на клиенте есть.

evvcom (2004-07-07 12:27:00) [3]

> Простейший пример - в датасете 1-2 записи.

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

Sandman25 (2004-07-07 11:34:00) [4]
[6] evvcom © (07.07.04 11:32)

>А пробегать по Dataset Next-ами это неверно

Необязательно. Простейший пример - в датасете 1-2 записи.

evvcom (2004-07-07 11:32:00) [5]
DBGrid выбирает из возвращенного курсора только те записи, которые ему надо отобразить. После скроллинга он fetch-ем выбирает дополнительные. Если

> время перебора стремится к 50-60 сек

то что-то неверно в подходе. Может долго отрабатывать запрос, но опять же 50-60 сек...? Возможно, не оптимизирован сам запрос. Для меня 5-6 сек. уже долго. А пробегать по Dataset Next-ами это неверно. Если нет желания лишний Query кидать на форму, для разовой операции его можно создать динамически, использовать и тут же удалить.

Sandman25 (2004-07-07 11:23:00) [6]
>Ибо записей много, время перебора стремится к 50-60 сек.

Если Вы показываете в DBGrid больше 100 записей, пересмотрите свой подход.

Андрей (2004-07-07 11:11:00) [7]
to StarWolf
Видимо, это самое правильное решение. Хотя очень не хотелось связываться с ещё одним Квери, но по-видимому прийдётся. Спасибо.

StarWolf (2004-07-07 11:08:00) [8]
Ну если речь идет о поиске строки с макс.длиной, то я бы посоветовал завести еще одну Query и там SQL'ем выбрать запись с максимальной длиной (правда смотря какая СУБД).

Андрей (2004-07-07 11:01:00) [9]
Тогда как максимально заоптимизировать поиск? Ибо записей много, время перебора стремится к 50-60 сек.
В смысле через
DataSet.Next
читаем, сравниваем с самой большой, делаем выводы
ПОКА not eof

Sandman25 (2004-07-07 10:58:00) [10]
Андрей (07.07.04 10:44)

Как найти максимальную длину поля? Наверное, пересмотреть все записи и найти самую большую.

Наверх

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