kaktus1983,

А пинг сервака что дает? Может там в принципе доступ такой тугой?

Хоть плюсы почили в бозе тихо и естественно, но вполне себе рабочие форки для (сравнительно) новых версий все же есть. Там никто не запрещает на уровне исходников выключить это самое кэширование по умолчанию :)
И вообще... в свое время плюсы были вполне достойнейшими компонентами. Зачем ругать тех, кто ушел на покой?!... Кощунство жеж :).

Не были. На изначальную кривизну FIBC они наворотили этот самый интеллект чтобы
пользоваться ими смогли даже идиоты. И это всё.
Окей. А тогда что на замену то ? Чтоб прям достойно было. И не для всех, а кто в теме.

ЗЫ: И кстати, почему автор IBEXPERT'a использует эти не вполне достойные компоненты по сей день? Странно...

Ну это у него надо спрашивать. Полагаю, изначально купился на простоту
использования, а потом они превратились в чемодан без ручки, как это обычно и
бывает.
Таки что Отцы используют (и рекомендуют) в трудах ежедневных в качестве коннектора с FB ? :)

Эту песню (библиотеку) я и сам отгадал с первой ноты :)
Однако не про библиотеку ведь спрашивал, а про компоненты для связи с базой FB. Самописное нечто, я полагаю?

Это чтобы мышкой на форму кидать и клац-клац? Не, такой фигнёй пусть чайники маются.
Да как бы можно ничего не кидать, в рантайме все, но ведь упрощают же жизнь компоненты ж...

Или Дмитрий сторонник подхода: абсолютли все свое, ибо чем низкоуровневее, тем лучше? Оно понятно, но баланс ведь должен быть. А так исходя из вашей концепции получается всякие сторонние обертки\фреймворки\компоненты - зло что-ли?

Вы это как бы про все компоненты априори??? То есть вот взять всех и под одну гребенку?


Это ж какой длинный тернистый путь (без компонентов\оберток\фреймворков) должны пройти будут новички, чтобы скажем, лет за 5 написать хоть что то вменяемое. На мой взгляд, это время прошло еще в начале нулевых, если не сказать даже 90-х. Сейчас куда практичнее баланс - берешь компонент, прогоняешь на нем десяток-другой тестов и вперед - в разработку сразу, если приемлемый результат по: 1) финансовым затратам на покупку\время разработки; 2) по количеству некритичных багов, которые можно быстро править в исходниках; 3) по скорости получения данных\парсинга\рендеринга;
2й пункт самый непростой, да, но я вообще по началу покупал компоненты без исходников и в целом, меня устраивало. Сейчас, по прошествии 10 лет в Delphi, покупаю по возможности с исходниками конечно.

В довершение добавлю такой момент: когда в 2010м мне занадобился инструментарий для проектирования и, собственно, кодинга бизнес-приложения, я выбрал Delphi как раз из за большого количества всяких готовых штук. На тот момент как раз по отзывам, мне как нубу (точнее полному чайнику) больше всего подошли\понравились FIbplus. Никаких особых нареканий за все 10 лет к ним у меня не было. Совсем.

Сейчас у меня ровно такая же картина маслом. Прям один в один. Оглядываясь с ужасом на легаси-проекты с сотней датасетов в датамодуле, приходишь к полному переосмысливанию подхода. Теперь она сводится к написанию своей многопотоковой модели фреймворка, но с использованием асинхронно-событийных компонент (для работы с почтой, sip-телефонией, БД в облаке и пр.). И таки да, "велосипедить" свой MVC как то тоже вынуждает общая ситуация.

P.S: Однако, подытожу - новичкам сразу в MVC и во всякие многопоточные, да асинхронно-событийные модели все равно нырять рановато - это уже открытое море практически, пусть "в лягушатнике поплавают" для начала :)

А в Унидаке (и прочих даках) от Деварта?

Если это так, почему вам не запилить свои даки, с конкретным конкурентным преимуществом, актуальным ныне ? И будет эдакий пассивный доход в итоге.

Вы из Великих. А они знают альтернативные пути, я полагаю :)

Я сейчас местами в качестве грида использую широко известный в узких кругах VirtualTreeView. На данный момент пока в основном потоке использую подгрузку данных из БД ровно того количества записей, которые помещаются в видимые пределы контрола VT + несколько записей до и несколько после (что то вроде кэша в памяти получается). В этом мне помогает событие OnAfterPaint. В общем, я подгружаю ровно то, что хочет видеть пользователь, и немного еще.
В общем, оно и так не тормозило никогда доселе (выкачать с сервака 20-50 записей единовременно не проблема), но в идеале мне ничего не мешает эту подгрузку засунуть в другой поток. Чтоб уж наверняка все было максимально "антифризно" и мягко.

P.S: Поскольку порядок узлов мне известен, мне не составит труда вычислить первый и последний видимые узлы:

Ну а дальше, вычислить несколько предшествующих и последующих - дело техники.

Короче, это нечто похожее на "Background fetch, без тормозов на прокрутке грида" для меня решение.

Хмм... А зачем ему висеть в памяти сервера то? Вытащил на клиента с сервера данные через запрос - передал в мемори-датасет (я к ним сейчас питаю самые теплые чувства:)), отключил соединение и работаешь уже с данными в мемори-датасете. А оные чем еще хороши - они в оперативке вполне себе джойнятся как тебе нравится, читай полноценный SQL + скорость выборки молниеносная:
http://www.components4developers.com/products_kbmMemTable.html