Как руками добавить вычисляемый столбец в TDBGrid?

Доброго времени суток. Собственно, возник вопрос, как сделать сабж. У меня, имеется древняя база на Кларионе, которую цепляю через ОДБЦ, данные из TQuery привязаны к TDataSource, а потом выводятся в TDBGrid. Но я столкнулся с проблемой, что в базе дата хранится черт-те как и чтобы ее нормально вывести, надо в начале натравить на нее функцию обработки. Далее, возникает следующая проблема... Если я определяю все столбцы, которые мне нужны и создаю вычисляемый столбец, то всё работает, но есть необходимость разрешить пользователю галочками выбирать какие столбцы нужны, а какие -- нет. Сформировать строку запроса не сложно, это я сделал, но если данные для описанного в запросе столбца в результате запроса отсутствуют, то при попытке их запихнуть в созданный столбик выскакивает ошибка. Если зарегистрировать только 2 столбца: тот, откуда данные берутся (дату в левом формате) и результат, то сколько бы данных не возвращал запрос, а отображаются только те, которые заданы явно.

Собственно, видится несколько вариантов решения:
- сделать, чтобы автоматически добавлялись все столбцы, которые есть в запросе, даже несмотря на то, что явно описаны остальные;
- добавить вычисляемый столбец после окончания формирования запроса;
- добавить все остальные столбцы, кроме вычисляемых, в момент запроса
- создать потомка от например TDataSource, который бы один столбик обрабатывал иначе.

Подскажите пожалуйста, как сделать хоть что-нибудь из вышеперечисленного? Или может быть есть другой метод?

P.S. Можно было бы реализовать функцию обработки в самом запросе, но TopSpeed ODBC драйвер таких сложных запросов не умеет.

0

Самый простой способ - не трогать запрос вообще (тогда все ваши Calc-поля будут весело плясать), а колонки просто прятать используя св-во TColumn.Visible

0

Сообщение от MsGuns Самый простой способ - не трогать запрос вообще (тогда все ваши Calc-поля будут весело плясать), а колонки просто прятать используя св-во TColumn.Visible

Это не тру. А что если 100500 человек дернет запрос, в котором 90% информации им нафиг не нужно? -- Не, реально не тру.

0

Ничего не понял.
Во-первых, состояние сетки можно сохранять перед закрытием и восстанавливать после запуска приложения (TDBGrid.Columns.SaveToFile, TDBGrid.Columns.LoadFromFile), т.е. каждый из "статыщ" может смастерить сетку "под себя".
Во-вторых, "дернуть" запрос может только один человек, второй будет "дергать" уже другой запрос с другого ПК. Для сервера это будут два разных запроса, при этом насколько они похожи друг на друга, он даже не посмотрит
В-третьих, кол-во колонок, включаемых в запрос влияет на загрузку сервера (и скорость выборок соответственно) в куда меньшей степени, чем кол-во возвращаемых записей. Другими словами, серверу много проще выбрать и отправить клиенту 100 записей с 1000 полей в каждой, чем 10 000 записей с 10 полями.
Если База не будет слишком большой (сотни тысяч записей), а кол-во полей не превысит 100, то можете забыть про слово "слишком", кларион должен работать достаточно шустро.

Добавлено через 4 минуты
Если Вас беспокоит проблема выборок и пересылок "лишних" колонок, то, поверьте,- это надуманная проблема. Вот "лишние" записи - это да, тут нужно найти решение избавить юзера от лишнего. Фильтрация, предотбор (например по периоду) - вот правильные решения. Пользователю всяко удобнее работать с 10 документами, пусть даже состоящими из сотни реквизитов (колонок), чем с 1000, но включающими только номер и дату.

0

Сообщение от MsGuns Если База не будет слишком большой (сотни тысяч записей), а кол-во полей не превысит 100, то можете забыть про слово "слишком", кларион должен работать достаточно шустро. Если Вас беспокоит проблема выборок и пересылок "лишних" колонок, то, поверьте,- это надуманная проблема.

Допустим, но в любом случае так не интересно =). Ну, возможно мой вопрос останется сугубо теоретическим, но всё-таки хочется узнать, как эти самые лишние колонки не перегонять.

Сообщение от MsGuns Добавлено через 4 минуты Вот "лишние" записи - это да, тут нужно найти решение избавить юзера от лишнего. Фильтрация, предотбор (например по периоду) - вот правильные решения. Пользователю всяко удобнее работать с 10 документами, пусть даже состоящими из сотни реквизитов (колонок), чем с 1000, но включающими только номер и дату.

Это в конечном счете пойдет на печать и результат должен входить на лист А4, как показывает практика, все нужные поля не влезают даже на А3. Но иногда пользователю нужен один кусок базы, а иногда -- другой. В итоге, возможность менять отображаемые данные на лету к сожалению незаменима.

0

Интереса в Вашем вопросе не более, чем в том, какой тапок быстрее, левый или правый. Вопрос вообще чисто "клиентский", поэтому имеет тучу решений. Я Вам рассказал про самый простой и надежный. Если требуется чесать ухо пяткой потому что так "интереснее", флаг в руки и ветер в ...

0