модПо соображениям 1-4 в качестве альтернативы Delphi oracle forms - можно W32, можно браузерный.
Сами понимаете, публиковать полный список требований было бы немного длинным - он порядка двух печатных страниц; я отметил только ключевые моменты принятия решения.

В моем случае формсы не имели шансов по нескольким причинам, почему и не рассматривались вообще, даже на стадии "а давайте вообще перечислим возможные варианты". Наиболее объективная причина - необходимость в существенно динамическом (конструируемом в ран-тайме) интерфейсе, с чем, по словам людей в форуме Oracle, у формсов большие проблемы.

kittn2При переходе с дельфы на сидиез.нет приходится отказаться от некоторых любимых приемов работы. Зато появляются другие, не менее эффективные приемы.
Если для этого перехода требуется переписать БД-ядро с учетом "сидиез не умеет" - нафиг такие приемы, имхо.

kittn2Попробуй еще раз. Почти уверен, что тебя, как и меня, тянуло блевать от интерфейсов NF
1.Х. Однако времена изменились.
Хм. В 2007-м году было бы странно смотреть FW1, isn't it?

"Блевать" - не то слово. Я бы сказал, пробивало на слегка истеричное "хи-хи".

kittn2Это особенно хорошо, когда на экран выводится вьюха и нужно вставить/обновить только поля в одной таблице из всех присутствующих во вьюхе. В дельфях это тоже можно, но механизм менее прозрачен. Нужно делать перехват события и подменять действия по умолчанию своими, а в нет просто сразу пишутся свои обработчики.
Подчеркнутое - чушь, простите. Скорее всего, вместо "в дельфях" следует читать "в [эпитет пропущен] наборе бд-компонент, которым Вы пользовались в дельфях"

kittn2Сидиез умеет посылать запросы и принимать рекордсеты. Что еще нужно для написания клиента?
Ну, дорабатывать напильником Dataset и DataAdapter я еще был готов. Остановился я, обнаружив большие проблемы в работе с объектами; точнее, обнаружив, поковырявшись, и наковыряв среди прочего "официальный ответ от Oracle" парню, обнаружившему то же самое несколькими месяцами ранее - "нет, мы не знаем, когда это будет работать в .NET, меняйте параметры своей процедуры на те, с которыми .NET умеет работать". Мне честно говоря не очень интересно, почему есть такая проблема, виноват ли в этом Билли или Ларри, но как факт - серверная часть, к которой пишется новый клиент, использует объекты как основу идеологии; переписывать ее.... может, через годик этим и займемся.

kittn2Но это не является непреодолимым препятствием.
Хм. Видишь ли, хочется работать, делать что-то полезное, а не преодолевать препятствия.

kittn2Из твоего постинга не следует, что ты пытался что-то сделать в 2007 году.
Там было употреблено слово "недавно". Любопытно, какой временной период, по-твоему, покрывает это слово.

Блок А.Н.Скажите, каких элементов интерфейса нельзя сделать в веб?
Если по большому счету, то практически никаких. Для достаточно наглядного сравнения я бы предложил Вам сравнить DevExpress-овский QuantimGrid и их же ASPxGridView (то и другое доступно на сайте). Вебовский - две секунды выполняет операцию "перетащить колонку на другое место", а изменение размера колонки ему вообще недоступно.

С последним, кстати, вообще весело, проявляются все традиционные глюки веба. Скажем, знакомство с ним я начал с того, что попробовал отредактировать запись. Щелкнул на одну из записей грида, нажал Backspace - и очутился на предыдущей странице (Go back one page). Очень интуитивно и удобно :)

Прошу учесть, что:

1. Задача - работать и делать программу, а не бороться с трудностями, искать компромиссы и выдвигать дополнительные требования к пользователям.

2. "GUI через веб" - то есть апплеты, ActiveX и так далее - безусловно, могут то же самое, что и гуй без веб - просто лишние напряги, лишние проблемы и лишнее звено в цепочке.

Блок А.Н.и нужно требовать одного браузера(что для интранет несложно),
Угу. А заодно потребовать от всех ездить на работу на машинах одной модели.

Блок А.Н.но пока мне кажется, что во многих случаях создания интерфейса веб удобнее.
Это ни в каком случае не удобнее для пользователя. Что же до удобства программиста - в конечном счете все упирается во-первых в наличие и качество API, во-вторых в готовность жертвовать интересами пользователя.

Думаю, java-девелоперов радует необходимость сопрягаться с "логикой на Си".

Блок А.Н.Кстати, в моей практики не встречалась необходимость переставить колонки, да c шириной столбцов пока получается бороться другими способами. Может, слишком давно работаю в вебе?
Не знаю. В моей практике это в последний раз случилось в субботу.

Блок А.Н. авторGUI через веб
В целом согласен, но в случае отчетов или чего такого без него тяжело будет.
Та ни капли :) GUI без веб - никаких проблем :)

Блок А.Н. авторпотребовать от всех ездить на работу на машинах одной модели
Угу, если машину предоставляет организация, то можно и потребовать.
Угу, можно попробовать. Вот только у меня, например, если мне не нравится предоставляемая организацией клавиатура, вопрос решается просто - приношу свою.

Ну а потом "так и живем". Как Oracle, например, официальный сайт которого ломается в половине браузеров, позорище.

Блок А.Н.Впрочем, на вебе я не настаиваю, просто стало обидно, что так без разбора откинули в сторону.
Отчего же без разбора? Если я не рассматриваю велосипед как средство скоростной доставки пассажиров из Москвы в Петербург - это не значит, что он отброшен без разбора.

Блок А.Н.Можно сделать хороший интерфейс и на вебе,
Сомневаюсь, если честно; "героическое преодоление трудностей" волей-неволей подразумевает значительные потери. Так или иначе, на сегодняшний день это вряд ли целесообразно. В целом я также сомневаюсь в том, что стиль "html cо вкраплениями кода" хоть когда-нибудь будет эффективен для построения нетривиальных интерфейсов; конечно, браузеры рано или поздно научатся показывать продвинутые формы, но это будет тогда, когда будет стандартизован некий web-аналог dfm-ов.

Осака ВестингаузужЕ, WPF

Осака Вестингаузтак плугин ставить надо
Кому? "Плагин ставить надо" - синоним "недостандартизированности" как минимум.