Сортировка в DBGrid при нажатии на заголовок колонки
Grid в EhLib
//---------------------------------------------------------------------------
//Сортировка по столбцам
void __fastcall TForma1::DBGridEh1TitleClick(TColumnEh *Column)
{
if (Table1->Active)
{Table1->DisableControls(); //запретить отображение данных
try
{
Table1->Close(); //деактировать предыдущий запрос
Table1->SQL->Clear(); //очистить свойство SQL
//Оформить команду Select ... ORDER BY
String fldKon = Column->FieldName;
Table1->SQL->Add("Select * From ТблКонстр ORDER BY " + fldKon);
Table1->Open(); //Выполнить команду Select
}
__finally
{
Table1->EnableControls(); //разрешить отображение данных
}
}
}
ТблКонстр является источником данных для Table1.
При указании на столбец Grida меняется переменная
fldKon.
TIndexOptions Options;
Options << ixCaseInsensitive;
Table1->AddIndex("MostPaid", "CustNo;SaleDate;AmountPaid", Options, "SaleDate;AmountPaid");
А потом
Table1->IndexName = "MostPaid".
А вообще связка TClientDataSet + DBGridEh дает результат безо всякого когда.
Предыдущий же метод я использую для Query, поэтому по запросу информация один раз считывается на комп, а дальше делай с данными что хочешь.
Можно и так.
Предыдущий же метод я использую для Query, поэтому по запросу информация один раз считывается на комп, а дальше делай с данными что хочешь.
Вот по этому поводу я бы на библии клясться не стал, все зависит от настроек BDE и/или тому подобных настроек.А вариант с локальными индексами обеспечивает именно клиентскую сортировку.
Вот по этому поводу я бы на библии клясться не стал, все зависит от настроек BDE и/или тому подобных настроек.А вариант с локальными индексами обеспечивает именно клиентскую сортировку.
Индексы для Table как раз то, что нужно, но как быть с Query?
Индексы для Table как раз то, что нужно, но как быть с Query?
Дык, имхо, удобнее работать на связке TDataSet(TQuery, TStoredProc и иже с ними)<->TDataSetProvider<->TClientDataSet.
Тогда и данные у тебя в БД записываются когда тебе надо, а не тогда когда какой-нить BDE захотелось и проблем с локальными сортировками и прочими приблудами нет.
Дык, имхо, удобнее работать на связке TDataSet(TQuery, TStoredProc и иже с ними)<->TDataSetProvider<->TClientDataSet.
А можно, если не трудно ссылочку или простенький пример просмотровщика БД?
А можно, если не трудно ссылочку или простенький пример просмотровщика БД?
А можно вопросик уточнить?На что конкретно ссылочку или чего конкретно пример.
На что конкретно ссылочку или чего конкретно пример.
Пример использования этого способа доступа к БД (если не ошибаюсь это - midas?).
Пытался разобраться со стандартными примерами Борланда, но там получается, что для того что бы просмотреть базу (animals.dbf) нужен во-первых БДЕ, т.к. провайдер() обращается к Тable,во вторых сервер. Можно ли обойтись без БДЕ, если к примеру использовать DBASE? Если можете, посоветуте что почитать. Спасибо
Пример использования этого способа доступа к БД (если не ошибаюсь это - midas?).
Пытался разобраться со стандартными примерами Борланда, но там получается, что для того что бы просмотреть базу (animals.dbf) нужен во-первых БДЕ, т.к. провайдер() обращается к Тable,во вторых сервер. Можно ли обойтись без БДЕ, если к примеру использовать DBASE? Если можете, посоветуте что почитать. Спасибо
BDE, ADO, ODBC не важно в общем что, все равно понадобится, ну никуда тебе не деться без провайдера доступа к данным. А дальше никаких проблем.
Кидаешь на форму ADOConnection(к примеру) настраиваешь его на базу. Кидаешь ADOTable на коннекшн, кидаешь DataSetProvide - на тэйбл.ClientDataSet - на провайдера. DataSource - на клиентдатасет. DBGridEh на Датасурс. ВОт тебе и вся связочка.
PS Еще вопросик чем отличается подключение описанное тобою от подключения в котором задействованы только ADOTable и DataSource (зачем такая длинная цепочка из Connection Table Provider?)
Спасибо