Ну если он так много жрёт выкинуть его.

Незнаю как ты производишь запись на диск.
Если данные хранятся в записи то это отдельная запись именно иконок.

1)Если ты посмотришь на мою программу (сделанную на делфи) то там увидишь что данные сортируются непосредственно в файле и только потом выводятся.
Там есть есть и Алгоритм сортировки.
2)Опять же если данные хранятся в записи то их можно читать с любого места хоть задом наперёд
так как для каждой ячейки есть свой индекс(номер ячейки) , если по другому то не знаю.

Если я буду писать и читать с диска, то это будут тормоза еще похлеше, чем сейчас. Посмотри, как реализован StringTable -- все хранится в памяти. Увеличение оперативной памяти для этого и сделано, чтобы держать все, или большую часть информации, в памяти. Дисковые файловые операции очень медленные и их применять нецелесоообразно. Зачем скатываться в каменный век? ИМХО, конечно. А чем SQL не устраивает, он как раз и занимается записями и операциями с ними? Я подцепил Grid'er к SQLight'y и убедился, что это очень перспективное направление. Единственное, что надо, так это увеличить быстродействие вывода инфорации.
Есть предложение -- адаптировать все это к нашим компонентам баз по наикратчайшему пути, максимально выкинув внешние элементы. Я думаю воткнуть внутрь компонента MT-потоки по аналогии с нашими, тем самым убрав промежуточные линки. Вот тогда можно будет строить простые, но быстродействующие схемы.

[size=-2]------ Добавлено в 22:44
Tad, ты можешь улучшить свой пример, чтобы реализовать запись в базу отредактированных данных по индексу строки (или полю id, но лучше через строку).
Еще вопрос. Можно ли реализовать параллельное считывание(запись) параметров и данных из двух таблиц одной базы, естественно, имеющих разные поля, или читать одну таблицу распараллелив поток данных и параметров? Я думаю ты понял, что я имел в виду.

Полностью согласен если читать с диска 10000 строк.
Если же читать только 100(нужных в данный момент) разница вряд ли будет заметна.
Да и вряд ли кому нибудь понадобится редактировать все 10000 строк сразу.
А используя поиск и вывод только нужной информации можно этот процесс реально ускорить.

На это есть простой ответвопрос
Сколько ты тут видел человек которые знают язык SQL
Так писал Dilma

Все же хотят всё и сразу.

Любой каприз за ваши деньги.
А если серьёзно .
Конечно надо если это увеличит быстродействие.

Вячеслав, не думаю, чтобы этим компонентом воспользовались начинающие. Ой, не думаю. Многие ли применяют StrTblProc? А те, кто применяет (или будет применять XLStrGrid'er), запросто может разобраться в базах, ничего там особенно сложного нет.
а если надо их просто просмотреть, а не редактировать, быстро перемещаясь по строкам, что тогда? Вот у меня, например, стоит сейчас задача быстро загрузить около 45000...50000 тысяч строк и затем по ним перемещаться. В ListBox схема от Tad'a загрузила 45000 строк за, примерно, одну минуту; StringTable -- за две, а вот Grid'er грузил в десять раз медленнее. Вот тебе и "Мдааа".

Да нет ,я ни в коем случае не против применения оперативной памяти ,даже за двумя руками.
Но задуманный Грид
1)имеет многострочность (в отличии от остальных)
2)имеет контролы (в отличии от остальных)
3)полностью настраиваемую цветовую гамму (в отличии от остальных)
И за это хочешь или нет прийдётся платить быстродействием.

Если ориентировать компонент на продвинутого пользователя то конечно.

А вот для этого как раз и есть SQLite .
Специализированный компонет для продвинутых пользователей работающих с большим объёмом данных.
И красявости тут никчему.
ИМХО конечно.

[size=-2]------ Добавлено в 23:43

Если я правильно понял в AnalisSHA так и сделано.

Все это останется (правда, хочу максимально упростить количество контролов. Наверное оставлю Edit и, возможно, ComboBox. Насчет остальных контролов -- а может ну их на...?)

nesco, пример чтения из нескольких таблиц:

насколько я понял, то по индексу id в одной таблице будет выбираться ul -- в другой?
Button, DatePicker, ComboBoxEx, ChekBox и ChekBox3St.
пока, из одной строки StringTabl'a, но а если не сложно, то показать пример с записью одной конкретной ячейки через матрицу, а можно и то и -- другое.
А для реализации двух потоков надо два синхронных запроса двумя компонентами Query, правильно я понял, если -- нет, то поправь?

Согласен. Но версию с ними сохрани (чем чёрт не шутит)

Это -- само собой

Будет выбираться в одну строку tab1.name, tab1.kod, tab2.gorod, tab2.zar из таблиц tab1,tab2 если условие True т.е., например, id в tab1= "Москва" и ul в tab2= тоже "Москва"

[size=-2]------ Добавлено в 01:19
Посмотри в схемах AnalisSHA и сразу все встанет на свои места

одно дело смотреть (это никуда е денется), другое дело -- вразумительный ответ по вопросу.

[size=-2]------ Добавлено в 02:03
Tad, а немного сложнее задачу можно сделать? Из одной таблицы вибирать записи и поля для отображения, а из другой -- только записи для установки параметров. Или можно выбрать значение поля из таблицы, без вывода самого поля в список полей?

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

что-то типа того. Я конечно попробую подготовить таблицы, но не так быстро. А задача довольно простая -- есть поля значений(например: id, name,tel,adr), нам надо их вывести в таблицу, но есть еще поля параметров (например: idxbmp, color, colorline, wline и тд) для графической инициализации таблицы и нам их надо получить, но не выдавать в поля таблицы, а использовать только для внутренней инициализации.

Tad, а как создать таблицу с N количеством столбцов -- каким компонентом? И как в нее записывать данные, а не читать их? Честно, я не нашел в SQLight-компонентах точек для ввода данных (может плохо искал). Заранее извини за тупой вопрос