MaratIskу тебя рудиментарные представления о трехзвенке :)
Все мы рано или поздно станем рудиментами )))

Поэтому и спрашиваю что и где можно почитать про современные решения.
Повторюсь - все что попадалось для тестов из трехзвенки давало кратные (в разы) провалы по быстродействию как по чтению так и по записи и лишало всей прелести возможностей FB сервера.

Можно спорить, где должна жить математика - в сервере базы или сервере приложений, но однозначно могу сказать, когда реакция системы на действие пользователя падает с 0,2 секунды до 2-3 секунд, то такой продукт улетит в помойку...
Современные интерфейсные технологии славятся своей "дружелюбностью" и "быстрым откликом" (как вы понимаете - это сарказм), но когда дело доходит до нормальных производственных задач, где гламур не важен, меня убедительно просят сохранить старый дельфийский софт, просто потому что интерфейс быстрее...
Вот и вопрос - что лучше - рудименты или ждать ответа глядя на красивое колесико...

[quot DmSer]Поэтому и спрашиваю что и где можно почитать про современные решения.

Очень много материала по современным решениям есть на habr.com . Причём "современные" не означаю "хорошие". Как правило это что-то лучшее из бесплатных технологий и это задаёт трэнд в программировании, адаптирует образовательный процесс в ВУЗах и позволяет работодателю без проблем находить новых специалистов. На сегодня тренд - это интерфейс пользователя на react-js и бэкенд на node-js / golang / php / aspnet core и т.п.
Разработка фронта на Sencha ExtJS и бэкенда на Delphi может даже будет более эффективна, но это совсем не тренд.

без обид, но "тренды" это жертва современного маркетинга.
"тренд" это то что сейчас ЛЕГКО продается, желательно без мозгов.
А задавали ли вы вопрос ЧТО продается?
Если взять меня - обожаю js (и 1С))) во всех ипостасях, когда нужно продать часы - быстро лепим дерьмо из готовых шаблонов, потом выкручиваем из заказчика много "часов" для приведения "этого" в рабочий вид, да еще убеждаем его, что ему нужно поменять весь парк железа, потому что новый фреймворк не поддерживается "современным" браузером.
Другой вариант - нужен "Продукт" для широкого круга заказчиков - нужна предсказуемость и стабильность. Нужно законченное решение, которое заказываться/покупается у разработчика. Заказчик не хочет платить за часы, ему нужно решение, которое будет работать на его паре тысяч компьютеров, часть из которых давно пора отправить в помойку.
Можно это слепить на js (для простых задач так и делаю, но приходится таскать с собой хромиум, чтобы хоть как-то обеспечить стабильность), но если задача сложная и еще ориентирована на пользователя с точки зрения ГУИ (в ...опу красоту - важна скорость, минимизация ошибок, целостность ввода информации) - вот тут, если сравнивать js и Delphi то скорость разработки (и цена) будет не в пользу js.
Увы, сегодняшний маркетинговый тренд - все в "облако", все на иглу "техподдержки", ширяйте мышкой до опупения, и пофигу, что очередь стоит. Меня как пользователя это бесит страшно, но это тренд.
Вопрос хорошо ли это?
Но это тема другой дискуссии.
Вопрос был о современных решениях в области трехзвенки под FB

kdvФэйтл Эра,

я бы сказал, "да и х с ним". Есть два типа коннектов, live и stateless. У Firebird/Interbase коннекты live. Это значит, что при обрыве коннекта контекст не сохраняется, надо делать переконнект и восстанавливать статус.
Stateless коннекты - это типа браузера по http, когда делаешь запрос, получаешь ответ, и дальше пофиг. Аналогично всякие модели briefcase, и прочее.
Автору топика надо stateless. Но это чревато, т.к. там всё по другому (в отличие от клиент-сервера) делается. Запросы надо целиком выфетчивать, показывать их по частям, и прочее.
В общем, автор топика опоздал лет на 20 с изучением трехзвенки.

Вы почти в точку попали.
Изучать трехзвенку начал лет двадцать назад, а с терминальными сессиями работал еще лет за десять до этого.
Правда никогда не считал терминальное подключение трехзвенкой. Да и тому, кто сможет поднять 200-300 терминальных ГУИ-сессий можно памятник поставить (из реальных подобных задач, только IKEA в голову приходит, да и то, кажется, они уже сдулись и на "толстого" клиента перешли)...

И насчет "живых" и "не живых" коннектов тоже - абсолютно в тему.
Естественно, понятны плюсы и минусы каждой из моделей.

Вопрос был в том, есть ли сейчас какие-то современные модели, которые позволяются обеспечить "условный live коннект" к ФБ при условии нестабильной связи.
Почему "условный" - потому что стабильность соединения хотелось бы контролировать на уровне клиента или сервера приложений - по принципу Stateless коннектов, но при этом не фетчить лишнего.

kdvДля Дельфи можно использовать и DataSnap. Но к нему претензии при большом количестве коннектов (клиентов, не к БД).
Можно использовать трехзвенку в виде веба - PHP и всякое. И т.д.

DataSnap - пробовали - к претензиям по стабильности на больших нагрузках полностью присоединяюсь
PHP - это тормоз, и рушит ФБ при большой нагрузке (гоняли на модели Classic 2.1-2.5)
и т.д. пока не пробовали, а хочется )))

Сисдба МастеркеевичИгорь-PicoMed PHP - это тормоз, и рушит ФБ при большой нагрузке (гоняли на модели Classic 2.1-2.5)Можно поподробнее ? Каким образом рушит ?
Пытаюсь добиться повторяемости ошибки. Как будет готов код и условия при которых падает база - напишу.
Хочу предварительно исключить косяки настроек операционки (в частности - на виртуально Window 2012 сервере ошибка проявляется в 15 раз чаще, чем на "железке") и иные, не зависящие от ФБ факторы

kdvИгорь-PicoMed которые позволяются обеспечить "условный live коннект" к ФБ
нет такого в принципе. Если такой коннект есть, то не к ФБ, а к серверу трехзвенки. Соответственно, к ФБ оно не имеет никакого отношения.

Очень жаль...
Хоть самому туннель писать.
Глупая идея - сервер (условно-трехзвенки или Proxi) держит пул коннектов/курсоров, а клиент подключается к нему по необходимости по принципу сессий. Обрыв связи не критичен - переподключение при сохранении сессии - всегда попадаем в нужное соединение/транзакцию.
Вроде и неживое и живое, одновременно...
Почему никто такого для ФБ не сделал? (для MS SQL о таких решениях слышал, но сам не копал, так как утверждалось, что заточено строго под мелкософт)