Мы просто всем сомневающимся клиентам демонстрируем работу нашего ПО на низких каналах связи. Приезжаем с ноутбуком, на нем установлено клиентское приложение с 2 типами подключений - одно напрямую через хост нацелено на консолидированную БД в нашей конторе, другое на локальную СУБД, связанную с консолидированной через оффлайн-репликацию по FTP, опять же в нашей конторе. Втыкаем BlueTooh-Adapter, соединяем через GRPS, демонстрируем, как работает клиент с консолидированной БД через хранимки, проводим изменения сверху данных узла, принадлежащих ноутбуку. Конечно не быстро, но достаточно удовлетворительно. Дальше подрубаем того же клиента, но к локальной СУБД, так же проводим изменения, запускаем репликацию, показываем что в обоих версиях клиента что в консолидированной, что в удаленной изменения были проведены и отображены. Таким образом демонстрируем, что на низких и даже не постоянных каналах доступа можно спокойно организовывать работу удаленных точек, причем работа может вестись в смешанном режиме, например у удаленного узла все клиентские приложения работают напрямую с консолидированной, а локальная БД периодически реплицирует на себя изменения. В случае падения канала будет достаточно перевести клиентские приложения на локальную БД и работа не будет остановлена, только что появится задержка в обмене данных между центром и удаленным узлом, равная периоду проведения репликации. Дальше уже достаточно показать, как с помощью ХП и триггеров организована система доступа прав от самих обьектов БД до бизнес-логики, централизованное администрирование удаленных узлов, автоматическое обновление структуры БД через репликацию и легкость сопровождения клиентского приложения и вопросы отпадают сами собой. Дальше обычно клиенты начинают упираться в платформу клиентского приложения, настаивая на веб-интерфейсе, чтоб было круто, но это уже другая тема разговора :)

Ну а к Locky я бы добавил:
7. Облегчение логики клиентского приложения, увеличивает легкость его сопровождения
8. Так как FB поддерживает SELECT FROM ХП(), то это позволяет скрывать от клиента сложную структуру БД, но не обрезать его в использовании SQL и плодить ХП
9. Возможность наращивать функциональность (логирование, репликация через вызовы ХП и т.д.)

авторпотом подключаете одновременно 10% от 200 тысяч пользователей
и начинаете сильно удивляться :)
Может быть сразу от миллиона пользователей ? Чего уж там мелочиться то с нашей широкой душой, а вдруг столько у клиента пользователей лет так через сто появится ? :)

ЗЫ: Да и пожалуйста, 2 штуки коннектов ASA нормально выдерживает, если сервак и ОС правильные :)

RЗабугорные специ правы, никогда не делай бизнесс логику на сервере
баз данных он для этого не предназначен.
Можно сделать если есть корпаративный сервак процессоров на 8 XEON MP
минимум. А если пользователей человек 200 будет....

НУЖНО логику делать на сервере приложений, но это уже не подьёная задача
для средней организации.

Для мелких кантор....
Крутиться на локальной машине твоя логика и берёт данные для работы
из базы (хранилище данных) и ВСЁ !!!!!!!!!!!!!!!!!!!!!!!!!!!
Можно подумать, что сервер приложений не ту же тучу запросов будет на тех же 200 пользователей слать на СУБД, что и ХП. Другое дело, если "спецы" окромя алгоритмического программирования, то есть ветвления, циклов и курсорчиков по другому никак бизнес-логику делать не умеют, тогда ДА - лучше пусть они ее в клиентских приложениях или 3-ем звене делают.