В качестве любого клиента (толстого, тонкого, 3-звеннки, Web-интерфейса) со всем необходимым в стандартном комплекте функционалом подходит Power Builder, который уже на протяжении порядка 20 лет тем и занимается, что создает клиентов под БД :)

Crip \r
Странно - у меня 2-звенная архитектура, сложная бизнес-логика и клиент, в котором максимум что из логики - проверка на заполнение обязательных полей и простых каких то условий правильности ввода информации (типа указанная дата должна быть не меньше текущего расчетного месяца). И то - даже если я и эту логику с клиента снесу, все будет прекрасно работать, так как чтобы там клиент в логике не проверял, все полные проверки по любому отрабатываются в БД.\r
\r
Уже собственно говоря это обсуждали в этой ветке. Пришли к мнению, что 3-звенная архитектура катит под супер сложные расчеты, которые накладно впихивать в БД и организацию распределенных приложений. Так что выбор C# не обоснован, тем более что эта штука еще и требует сторонних компонент для нормального построения GUI и накладывает солидные требования на аппаратные требования для клиентской части.\r
\r
Тот же VFP или PB в этом плане имеют изначально много всего, не требуют навороченных компов (не знаю как VFP, а вот приложение, написанное на PB спокойненько может крутиться даже на 486 с установленным Windows 3.1).

Petr Chulkov
Речь шла о GUI-клиентах. Я что то как то не помню, что в CLR в комплекте есть тот же нормальный грид или отчетник. Есть обрезанные версии продуктов, которые надо покупать за отдельные денюшки.

Насчет Web-клиентов вопрос спорный. Интересно мне было бы посмотреть, сколько сил, кода и времени ушло бы на создание более менее сложного удобного интерфейса ввода и просмотра данных на нем по сравнению с любым средством построения GUI-клиентов. Вопрос на засыпку - а у вас в ASP.NET есть приличный грид (не статическая страничка с данными в виде таблицы) ?

Crip
По ссылке которую я дал выше видно, что мою логику жестко прописанной назвать нельзя. Давайте определимся - на клиенте изначально будет логика управления визуалом, основанная на какой то бизнес-логике. Типа закрыта запись - кнопку редактирования гасим. Это по любому будет реализовываться даже на самом тонком клиенте, так как именно он управляет визуальными компонентами, а уж никак не 3-е звено. Думаю Вы со мной согласны. Теперь рассмотрим вопросы обеспечения целостности данных и проведения манипуляций над ними. Все это можно реализовать конечно и на клиенте, можно и на 3-ем звене, но кто мешает все это реализовать прямо в БД с помощью тригеров, ХП и UDF ? Чем продвинутость ООП языков поможет быстрее и правильнее реализовать бизнес-логику (т.е. фактически обработку данных), чем тот же TSQL (молчу про более продвинутые диалекты SQL) ? Даже наоборот - наличие того же динамического SQL позволит мне прямо в БД организовать более гибкие процессы, чем если бы это было реализовано на компируемых языках. Опять же клиент тут получается не причем. Так что я с Вами не согласен, во всяком случае пока не приведете пример такой логики, которая действительно бы привела к увеличению тяжести клиента, т.е. ее нельзя было бы красиво реализовать силами SQL.