drevПросто именно Clipper позволял строить такие системы с лёгкостью необычайной. Возможность хранения в базе кусков кода и преимущества возможности их лёгкой интерпретации.
Игорь, хранение в базе куска кода на PL/SQL ничем не отличается от хранения в базе куска кода на Clipper. Вернее, отличается только тем, что кусок кода на PL/SQL можно хранить не только полем в таблице, а еще и в виде ХП :)

Я делал и то, и другое, и избавившись от клиппера совершенно о том же жалел (точнее, жалел только об индексах по функции, которых в те времена практически ни у кого не было).

drevАлександр, я имел ввиду выполнение кода на "клиенте". Скажем, добавляем в хранимое описание "event listener" или "delegate". В спарке Delphi+Oracle так просто не получится.
Это бессмысленное желание. "Клиентский код" глупо настраивать такими маленькими кусками, гораздо удобнее хранить "формами целиком" - то есть dll-ками в случае Oracle+Delphi. Я согласен с тем, что интерпретатор дает более прямой путь для реализации "этой кривой схемы", но в любом случае не вижу смысла ее реализовывать.

Хранить "маленькие настроечные куски" удобно для серверного кода, а там это проблем не вызывает. Ну а поскольку на клиппере серверный код отсутствует - и приходилось выполнять его на клиенте.

tygraОбновлять ехе легко только тогда, когда он обновляется раз в пятилетку.
В пике - обновлялся несколько раз в день у пятисот и более пользователей. Без проблем.

tygraА обновление функционала на ходу гораздо быстрее, и надежнее
Вот насчет надежности - это смешно. "Начинали операцию с одной версией хранимого кода, заканчиваем с другой" - это замечательно надежно.

drevНу почему сразу глупо? :)
Из-за излишней детализации. Нарисовать форму редактирования, откомпилить ее, положить бинарник в БД, а где-то зарегистрировать, что "класс TFormXXXXX является редактором для документа XXXXX" - удобнее, чем распихивать по таблицам значения каждого свойства каждого компонента TFormXXXXX, класть туда же текст обработчиков событий, класть в сторонке "функции, которые ни к чему не привязаны, но вызываются из обработчиков событий" и пытаться со всем этим взлететь.

drevНапример, в случае редактируемых таблиц?
И? Не очень понял, что мешает редактировать таблицы без таких огрызков кода в базе.

drevКроме того, а если код ассоциируется с доменом?
Да какая разница, с чем? Все равно это не "обработчик события", не "делегат", а как минимум "класс".

drevЕсли Вы работали на Клиппере, и в Москве, то вроде по возрасту должны знать Ярцева? На Softools часом не ходили? Я там как раз показывал такую систему на Клиппере.
Ярцева, увы, не припомню. Думаю, в Москве не только мы двое работали на Клиппере :) тем паче, что я был тогда весьма молод. На софтулы ходил, правда в последний раз очень давно, году в 94-95, потом стало неинтересно.

tygraУ нас тоже так обновляется, другая система. Но это когда касается локальной сети или более-менее нормального канала. А когда канал такой, что ехе будет час качаться, то тут уже не пообновляешь
Пообновляешь, если не пытаться впихнуть все в один монстроидальный exe-шник. В нормальной системе потоки данных по объему на порядки превосходят "обновляющиеся exe-шники"; если по этому каналу не лезет exe-шник - не пролезет и репликация данных, нужных для работы. Если данные пролезают - значит, в exe-шник запихали прорву лишнего, что туда просто не нужно передавать, особенно - передавать каждый раз.

Любопытно, что за exe будет передаваться час и как. С детства мне запомнилось, что мегабайт на 19200 качается за шесть минут. Итого, для нормального exe-шника канал должен быть где-то между 2400 и 9600. У меня были такие каналы, но не было необходимости пересылать туда полную версию Основной Задачи - всего лишь маленькие ее куски.

tygraНу и к тому же я добавлял про удобства - достют постоянные компиляции, если нужно фигульку поправить
Чем может достать пара секунд компиляции по сравнению с например минутой проверки этой фигульки? Или Вы собираетесь каждый раз перекомпилировать всего монстра?

tygraЭто какого такого хранимого кода ? Весь хранимый код - на сервер, т.е. ХП. На клиенте нет никакого кода, влияющего на результаты работы системы. Ты же сам серверный код используешь :))
Что ж, давайте аккуратнее. Если Вы имеете в виду обновление данных, определяющих формирование клиента, то все выглядит еще замечательнее. У Вас была фраза про отсутствие разных версий - я понимаю ее так, что поправки начинают действовать сразу, в уже запущенных клиентах. Давайте посмотрим, что будет.

Допустим, я открыл расходную накладную в первом окне. Потом Вы обновили метаинформацию. Потом я открыл другую расходную накладную во втором окне. В результате у меня в программе - два окна, которые должны быть одинаковы, но которые различаются. Если я нажму в первом кнопку "сохранить" - что произойдет? Я вижу два варианта: либо таки выполнится устаревший код, что плохо и никак не "надежно", либо новый код сохранения выполнится над старыми данными (что может приведет к ошибке, может к кривости сохраненных данных), опять-таки плохо и никак не "надежно".

Вывод: как ни крути, а при апдейте надо учитывать многоверсионность и предусматривать механизмы для отключения пользователей, которых затронут результаты апдейта.

tygraЕсли бы все кончалось двумя секундами компиляции, то было бы хорошо :))
Тигра, если приводите аргументом компиляцию - давайте говорить о компиляции. Если приводите аргументом смайлик - это вообще не аргумент.

Стиль "я все равно знаю, что так надо, и раз придуманный на ходу аргумент не сработал - придумаю следующий" годится для удовлетворения эго, но не для информативных бесед.

tygraНо до этого нужно еще поправить то, что компилировать, открыв Дельфи.
Ага. А сталбыть Query Analizer (или что там) открывается божьим духом и все поправляет сам, я правильно понимаю?

tygraПотом нужно это куда-то отправить, чтобы это стало доступным пользователям, потом это должно уйти пользователям,
Ох, как страшно. Да... если я правильно Вас понял, правите на живом production, потом смотрите, что получилось. Если поправили неправильно, мило улыбаетесь тем пользователям, у которых из-за этого "неправильно" возникли проблемы.

Или все-таки правите где-то отдельно, может быть даже тестируете, и только потом "нужно это куда-то отправить, чтобы стало доступно пользователям"?

tygraпотом пользователь должен прервать работу, закрыть ехе,
Зачем?

tygraДа и потом, не надо приводить разнообразные расчеты скорости скачивания и т.д., здесь же не дети :))
Детей нет, а детские аргументы есть? Однако, диссонанс.

tygraЕсть много причин, почему неудобно обновлять ехе 20 раз в день.
А обновлять что-то другое 20 раз в день они совершенно не мешают :)

tygraНо если кому-то нравится это - я не против :))
Я все же предпочитаю делать что-то более значимое.
Угу. Любимую игрушку, которую можно дописывать и усовершенствовать, переложив на кого-нибудь другого решение мелких пользовательских проблем.

tygraПотому все стандартные вещи сделал автоматом, чтоюы на них не тратить ни мое время, ни пользователей.
Начало откровенной демагогии воспринимается как окончание осмысленной аргументации.

tygraПроблему несоответствия данных можно решить многими способами, но делать тогда, когда проблема есть. Сейчас ее нет и пока не предвидится.
А конкретнее? Можно ли описание тех изменений, которые Вы проводите и при которых "пока не предвидится"? Что-нибудь типа "чаще всего мы делаем вот это, потом еще вот это и вот это, и других изменений почти и не бывает".

Я так сходу вижу только один пример - поправить опечатку в названии поля/колонки.

tygraПроблемы нужно решать по мере их приближения, а не все на всю вечность вперед.
Правильные слова, пытающиеся "в связке" вытянуть крайне сомнительное утверждение насчет "не предвидится".

tygraЯ не склонен отвечать на демагогию чистой воды :))
Тем более для Вас оснований не ограничивать оной свои ответы. Попробуйте привести хоть что-то реальное. А то до сих пор беседы протекают по одной и той же странной схеме - фреймы Вы готовить не умеете, dll-ки Вы готовить не умеете, exe-шники... обсуждается, а кто умеет - так тот "самый умный, почему шляпу не одел" и следовательно демагог.

Однако, логика.

tygraЯ внимательно слушаю, можно продолжать :))
Вы бы лучше отвечали хотя бы на прямо заданные вопросы - например, про то, какие изменения у вас проводятся, ничего не затрагивая. А то как переходим от общих слов к конкретике - так в кусты.

Mainframeзнание SQL + примитивный внутренний язык + простая среда разработки. И это работало!
Угу. Вот к этому все в итоге сводится - "маленькая примитивная дельфа". Без нормального редактора, без нормального отладчика и с примитивным результатом. При этом программисты жутко довольны - поскольку они занимаются НАСТОЯЩИМ ДЕЛОМ, разрабатывают КРУТОЕ ЯДРО, а для реальной работы - набираются толпы неграмотных невесть кого, поскольку "они дешевые, а у нас все примитивно".

Надо сказать, сейчас вожусь ровно с такой же системой. И пока что не вижу гениальности в этом подходе; как только нужен интерфейс сложнее "списка колонок в столбик", так хоть плачь.

tygraЭто бессмысленно.
Отчего же? Приведете реальные примеры - "все увидят", что я пыжащийся идиот, мне придется выкручиваться и не внешне конечно, но внутри себя сожалеть, что я полез критиковать незыблемо правильную идею. Возможно, в следующий раз я вспомню этот печальный опыт и не буду мешать Вам излагать достижения.

tygraЯ, по-моему, не видел ни одного вашего поста, где бы вы кого-то не критиковали.
Они есть даже в этом топике. Насколько тщательно Вы закрываете глаза - не знаю, не готов судить.

tygraлюбая мысль. которая не нравится лично вам, неважно правильная она в принципе или неправильная,
То есть: Вы абсолютно уверены, что некая мысль "правильная или неправильная". Во-вторых, выше Вы ярко иронизируете по поводу моих гипотетических претензий на абсолют. Выглядит так, словно Вы полагаете право на абсолют эксклюзивно своим.

tygraглавное, что идет в разрез с вашими мыслями, вами считается ложной и неправильной.
tygra, если Вы не умеете обосновывать - не беритесь. Здесь же, на форуме, меня в последний раз убедили изменить точку зрения всего несколько дней назад. Для этого надо всего лишь хорошо знать обсуждаемую тему и быть правым.

tygraА то мы все развиваемся,
Да вот незаметно, признаться. Это скорее регресс; всего несколько лет назад Вы собирались писать книгу по искусству программирования, а сейчас делаете то же, что начинает делать любой активный ламер как только научится динамически создавать компоненты.