zinpubПыталась родиться идея - Хранить исходники(pas) в базе, а исполнять в paxScript'е...

Зачем вообще исполнять на клиенте? Надо исполнять все на сервере, а клиенту кидать видео интерфейса )))) ну и мышку-клаву от него ловить и на сервер передавать.

softwarerВасилий 2Обоснуй
Подход подразумевает невозможность открыть датасет в дизайн-тайме. Следовательно, многие возможности отладки и настройки в дизайн-тайме тоже недоступны, плодится куча тупейшего кода, для отлова тривиальных ситуаций типа "поле на десять пикселей уже, чем значение" или там "опечатка в названии поля" требуется запуск программы, а для проверки исправления - ещё один запуск. Итого медленная неэффективная разработка и тупой код в результате.
Я тоже в юношестве таким баловался. Когда задолбался переключать DB.Connected, сохраняющийся в True после развлечений в дизайнере и пытающийся восстановиться при запуске программы у клиента, как-то остыл. К тому же не все запросы отображаются визуально, бывает и внутренняя кухня, которую надо генерить динамически. У меня в проекте штук двадцать разных внутренних запросов - что же, на каждый добавлять TQuery? А если необходимо юзать несколько разных db-логинов (к примеру, интерфейс у них различается), то дизайнер тоже в пролете. Опять же при изменении схемы БД я быстро найду старые запросы поиском по проекту, а тебе придется ворошить компоненты.
В общем, все зависит от структуры и задач программы.
roschinspbВасилий 2- Не хранить тексты запросов в свойствах компонентов - dfm файлы часто исключены из фильтра поиска, и в случае чего искать текст придется долго. Я в одном проекте (всё на ХП, запросов немного) выделил все тексты в секцию констант одного юнита, а в другом (клиентский софт для БД с кучей таблиц) задаю их константами внутри методов, но обязательно добавляю к имени суффикс SQL, чтобы облегчить поиск в случае чего.
Т.е. не любите Вы визуальное программирование. Ну, это дело вкуса. Я так наоборот считаю, что надо максимально использовать db-aware компоненты и DataSet`ы на DataModu`лях. Открывать тут холивары на тему лениво, но вот что бесспорно так это то, что по возможности надо придерживаться одного подхода. Потому, что когда исправляешь что-то в dfm-ке, а потом где-то глубоко в коде пара символов исправляется на нечто иное, то это печаль, особенно в большихстарыхчужих проектах.
Я к нему спокойно отношусь. Кидать контролы удобно, но вот копошиться с пикселами, выравниванием и прочим меня задалбывает.
Насчет свойств компонентов как раз тоже из опыта. Неоднократно бывало, что по полчаса ищу некоторую опцию, которую нужно добавить в другой компонент или наоборот изъять. Особенно весело, когда это нечто монструозное типа грида или virtualtreeview.

softwarerУгу. Это как раз иллюстрирует разницу в наших подходах. Ты идёшь наиболее очевидным путём: попробовал, увидел проблему, решил, что надо переключать. Переключал, переключал, переключал, переключал, переключал, переключал, переключал, переключал, переключал, переключал... задолбался и ушёл целиком в рантайм. Я же, попробовав и увидев проблему, чуть-чуть пораскинул мозгами и сделал так, чтобы дизайн-таймовый DB.Connected не мешал. Он у меня годами остаётся в true, просто не пытается восстанавливаться в ран-тайме, вот и все :)
Я тоже сделал, но это было мне неудобно. Сейчас я сделал так, как удобно.
На самом деле я бы мог сейчас задвинуть про модели и контроллеры, про отделение гуя от бизнес-логики и прочее, но не вижу смысла. Данный аспект не аксиома, пусть каждый делает так, как ему привычно и удобно. Ну а лично тебе желаю делать поменьше категоричных выводов, ибо когда они уходят в молоко, ты выглядишь очень бледно.

roschinspbспорить о предпочтительности того, или иного подхода можно только применительно к конкретной задаче. Для одного случая уместно одно, для другого случая уместно другое.
Именно! У меня коллега вообще отказался от сторонних компонент, потому что не хочет морочиться с установкой :). Но для его целей хватает. Мне же, например, без VTV было бы очень тоскливо.
roschinspbИ кстати говоря, для больших коммерческих проектов хорошо бы по-реже упоминать местоимение Я и по чаще использовать местоимение ОНИ (кто будет править твой код).
Приложение пишут несколько лет, несколько людей (иных уже нет, а те далече). У каждого свой уровень познаний, свои предпочтения, свои девиации сознания наконец. Кто-то скажет "нафига мне db-компоненты, я сам умею добавлять итемы в комбобоксы", кто-то скажет "да я привык использовать отличную библиотеку XXX, 20 лет пользуюсь ни разу не подводила", кто-то начнет всё переписывать и уйдет в запой... в итоге каждый оставляет свой неповторимый след в истории. Так что лучше уж использовать стандартные подходы, ограниченный набор библиотек пусть он даже в каком-то частном случае хуже чем можно было бы написать самому, чтобы твои последователи меньше тратили времени и сил на осознание твоей гениальной задумки, а больше уделяли времени на исправление логики в соответствии с новыми задачами.
Большие проекты, как правило, не начинаются в одиночку. И кодинг стиль у компании должен быть устоявшийся и закрепленный в мануалах, также как и любое привлечение сторонней библиотеки не может быть решением рандомного джуниора Пети. Ну а если речь о проектах одиночек, то нет смысла ужиматься - либо он так и останется собственным проектом, либо перейдет в категорию крупных и по-любому придется все переписывать и подгонять.

alekcvpИли всё как у взрослых и установлена своя системная служба-обновлятор? :)
Ох уж эти "взрослые" со своими службами-обновляторами... придушил бы. Каждая сволочь норовит в сервисы пролезть.