У Delphi и PB вообще то разные принципы работы. Delphi - компонентно ориентированный язык - кидаем кучу компонент, связываем их и по всей форме размазываем бизнес-логику приложения в перемешку с логикой интерфейса. У PB есть DataWindow, который собой заменяет вкладки Delphi по доступу к данным, гридам, DBAware компонентам, отчетам и графикам. Плюс PowerScript и поддержка наследования в PB гораздо мощнее и удобнее ObjectPascal, в Delphi наследуются только формы, в PB все что угодно, в Delphi идет прямая работа с памятью с любимыми Access Violation и потерей памяти при неграммотном программировании, в PB есть сборщик мусора, готовый взять на себя все заботы по освобождению обьектов. Наконец в PB есть поддержка SQL в PowerScript, красивая событийная модель и поддержка очереди сообщений и функций. Все это реализуется на Delphi, но только при условии его хорошего знания и затрат на кодирование. Но как тут уже было правильно замечено - самый небольшой недостаток PB - это отсутствие русскоязычной документации по нему. Но и в Delphi, даже при наличие множества книг без изучения основ ObjectPascal и VCL каши не сваришь - иначе получится нагромождение формочек, компонент и разбросанной логики, в которой потом будет ой как сложно разобраться. Так что тут все зависит от Ваших знаний и поставленной задачи, если она маленькая, то вообще можно Access взять и быстро ее слепить без дополнительных усилий.

авторС этим соглашусь, а все остальное у тебя исходит из малого знания Delphi.
Я на PB работаю с весны 2003 года. До этого я с 1995 года сидел на Delphi, VCL назубок знаю, пакеты порядка 50 собственных визуальных компонент и черти скока классов :) Так что стоит мой совет с большого опыта работы на Delphi рассматривать.

авторНу на сколько я знаю, ASCRUS на Delphi программировал дольше, чем та PB. Но он является фанатом Sybase (наверное у них на пол ставки подрабатывает :) ).
Нет, не подрабатываю :) Мы просто помогаем друг другу - меня интересуют хорошие технологии, им специалисты тоже не помешают.

авторА вот на счет размазывания и перемешивания бизнес-логики и интерфейса я что-то не понял. Почему она размазывается в Delphi, и почему тогда она не размазывается в PB?
Потому что получение набора данных, правила его сохранения, фильтрация, сортировка, группировка и любое его визуальное отображение находится в одном флаконе: DataWindow. Теперь представьте себе Delphi: под все это придется как минимум вешать TDataSet, TDataSource, TUpdateSQL, TDBGrid (или нормальный коммерческий аналог), TDBEdit, плюс какой нибудь отчетник. Далее начнется катавасия - поля и различные правила на них описывать в событиях TDataSet и TField, контролировать изменение состояния редактирования легче в событиях TDataSource, чтобы раскрасить тот же самый грид придеться на его события вешаться и т.д. и т.п. Причем для каждого компонента нужно знать не только его архитектуру и какое свойство/событие за что отвечает, но и его принципы работы, с кем и как он связан, что и когда у него вызывается. Ну и т.д. В общем старый добрый ООП, который в принципе и не плох, и на нем много чего удобно можно писать (я например люблю на нем чего нибудь под себя делать: парсеры, макроязыки, какой нибудь визульный тулз), но который в моем понимании уступает специально заточенным под это дело средствам, таким как DataWindow. Это конечно же мое мнение, но я вот программируя год на PB и уже перенеся кучу своих различных решений с Delphi, которые считаю удачными для построения клиентских приложений, заметил одну особенность: кода и ошибок на PB меньше получается :)

Локшин Марк
Я не спорю, что на Delphi при достаточном желании/упорстве/времени можно написать полный аналог DataWindow, а заодно и сам PB, причем с более качественным, навороченным и устойчивым IDE. Остается только любезно узнать, где же взять это желание/упорство/время. Вы рассуждаете как опытный программист, поэтому Вам ближе средство, не ограничивающее Вас ни в чем. Я же рассуждаю как руководитель проектов. На PB я могу пересаживать людей реально работать после небольшой предварительной подготовки и демонстрации уже отработанной иерархии визуальных и невизуальных обьектов. Поначалу для начинающего кодера будет достаточно начать рисовать формочки и отчеты DataWindow, что уже для проекта будет большим делом. В Delphi мне для проектов придеться искать квалифицированных и более дорогостоящих программистов, которые все таки разбираются в ООП, наследовании, VCL, куче сторонних компонент и могут хотя бы внятно рассказать, зачем обьект создается, как он живет, оповещает другие обьекты и удаляется, иначе вместо кода мне будут рисовать лабуду на формочках. Все это выйдет мне дороже, не факт что качественнее по коду (я бы сказал даже наоборот), и главное с "бурной фантазией" в коде, которая отличает многих дельфийцев от переизбытка возможностей или недостатка опыта. Частенько мне их приходилось контролировать на предмет усложнения кода, что не прибавляло скорости и надежности проектам. Лично мне это для построения клиентской части только мешалось и послужило одной из главных причин перехода на PB, так как я всегда поддерживал девиз "Чем проще, тем лучше".

авторПросто это версия 2.0 :)
И кстати я работал начиная с Delphi 2.0 и начиная с него прошел все версии включительно 7-ой, на которой до сих пор и работаю, в числе моих последних работ парсер TSQL с MSSQL2000 и на его основе конвертор баз данных с MSSQL2000 на ASA9 (причем все на чистых классах VCL по желанию заказчика). Так что намеки на то, что я "давненько" не видел Delphi абсолютно безосновательны. Хотя не скажу, что я с удовольствием этот конвертор писал на Delphi - на Java или C# было бы гораздо меньше геммороя и больше толку, но клиент к сожалению всегда прав.

Ну а супер-пупер движков на Delphi с собственными парсерами, Run-Time дизайнерами форм и инспекторами обьектов и т.д. и т.п. я за свою жизнь насмотрелся выше крыши (одно время даже помогал в исправлении ошибок и доработке классов FastReport, когда на нем работал). Видел я и отличные движки, видел и ужасные. Но это все равно по большему счету кустарные подделки, какие бы они хорошие или плохие не были. Лично я считаю, что потеря времени и ничего больше. Когда нам заказчик заказывает автоматизировать его работу, он вообще то ждет программу, а не универсальный супер-пупер инструмент, который чтобы еще хоть как то заработал, придеться долго и нудно расширять, отлавливая ошибки. Я уже молчу о его зависимости от приемственности версий Delphi, ни разу не было, чтобы при смене ее версии не пришлось бы ручками править свои пакеты, каждый раз Borland умудрялась корежить иерархию VCL, впихиваю туда нужную для маркетинговой раскрутки функциональность, и кстати игнорируя существующие баги из версии в версию (я уже молчу про доступ к данным аля собственный движок BDE, далее кривой в 5-ой версии ADO и в дальнейшем работающий для избранных DBExpress, резвый прыжок на Линукс и тут же обратный на Windows и т.д. и т.п.). Все эти навороты в виде супер-движков, приколы Borland и баги VCL по любому увеличивают время разработки проектов, что с точки зрения финансового благополучия довольно печально отражается на самих нас (если конечно мы не на окладе и нам готовы "простить" сто лет писать один проект).

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

авторК слову, специалисты, кто программирует на Delphi, насколько я помню, не рекомендуют использовать компоненты, подобные TDBEdit вообще...
Ну это вообще No Comments. Читал я их забавный топик в форуме Delphi. Все дружно сошлись во мнении, что DBAWARE компонентами пользоваться не стоит и нужно ручками переносить все в TEdit, потом после редактирования ручками же все переносить в TDataSet и тогда сохранять. Первым сильным аргументом в пользу TEdit перед TDBEdit была фраза "А мне ручками прикольнее писать". И куча других не менее забавных аргументов, которые честно говоря я слабо очень понял. Наверное Borland зря придумал TDataSet, TDataSource и TDBEdit, TDBMaskEdit, TDBChechbox, TDBListBox и т.д., так как настоящие специалисты предпочитают все делать сами и для них главное не какое то время разработки или кол-во допущенных ошибок, а глубокое моральное удовлетворение от собственно разработанных решений, пусть и выглядящих немножко кособоко.

Тут даже вопроса не стоит. PB будет однозначно эффективнее Access как и в разработке/сопровождении (ООП, встроенный SQL, большие возможности DataWindow и т.д.), так и по качеству работы самого движка, так как Access может эффективно работать или с родным Jet движком или с MSSQL через ADP. Работа через ODBC и в частности присоединенные таблицы с другими СУБД это один большой глюк и сплошные тормоза - говорю со слов людей, прекрасно знающих Access.

Обьясните пожалуйста, что Вы подразумеваете под словом эффективность: скорость и качество разработки приложения, скорость работы с БД, еще чего то ... ?

Отвечаю по пунктам:
1. Благодаря ООП (повторно-наследуемые формы, контролсы и т.д.) и технологии DataWindow скорость разработки высокая.
2. Глюкавость в основном в самой IDE. В runtime все работает нормально, проблем с получением и изменением информации не наблюдается. С учетом того, что DataWindow работает через отложенные изменения можно спокойно закачать данные (и даже отцепиться от БД), менять их, а потом сохранить все изменения. Причем DataWindow может сам автоматически генерить скрипт на изменение данных (Table update), или же можно указать ему проводить изменения через собственные ХП, что во многих случаях позволяет обновлять данные со сложных запросов или ХП, полученные со многих таблиц, где с точки зрения Access они бы выглядели как необновляемые. Ко всему прочему DataWindow централизованно позволяет перехватывать все выполняемые SQL команды к СУБД и даже изменять их по ходу выполнения, когда команда уже подготовленна, но еще не послана на сервер.
3. Скорость работы ODBC зависит от конкретного драйвера СУБД. PB может работать с СУБД через многие интерфейсы доступа (ODBC, OLEDB, OpenClient), причем логика приложения не страдает при его переключении с одного интерфейса на другой. С другой стороны DataWindow в PB является аналогом многомерного массива, в который закачивается информация и уже дальше работа с данными ведется через собственный высокоскоростной и эффективный движок DataWindow в PB. А Access пользуется стандартным механизмом курсоров ODBC (или ADO), и естественно существенно проигрывает по скорости.
4. Глюкавости при работе с ODBC с серверами MSSQL и Sybase ASA я ни разу не видел. Даже встроенный SQL вполне прилично позволяет писать в коде довольно специфичные для СУБД конструкции, разрешенные драйвером СУБД и нормально их выполняет. Плюс в PB существует куча настроек транзакционного обьекта, через которого ведется работа с драйвером СУБД. Я бы сказал, что PB полностью отвечает требованиям прозрачного доступа к любым СУБД и через любые интерфейсы доступа.
5. Не очень понял, что имеется в виду. В PB фактически для организации форм ввода вывода информации из БД отсутствует такое понятие, как интерфейсные элементы. Все это заменяет собой DataWindow, который фактически является не обьектом проекта, а описанием набора данных, его правил получения, изменения и сохранения информации и визуального отображения. Такое описание можно хранить в проекте, в БД, файле или вообще динамически генерить, фактически DataWindow чем то сродни XML, содержит в себе описание всего обьекта и имеет способы получения аттрибутов всех его контролсов, их изменения, создания и т.д. При желании вообще можно слепить собственный дизайнер DataWindow и рисовать формы и отчеты прямо в рунтайме.
6. Говорят 9-ка даже с китайским работает. Ну а так как русский и украинский вообще работает прекрасно и в обоих странах вроде как никто пока не жаловался.
7. Самый печальный пункт - книг на русском нет. Выпускались ограниченным тиражем и давно. Тут в форуме давалась ссылка на FTP, откуда их можно выкачать, причем книги отсканенные в jpg и по старым версиям PB (хотя основные все принципы не поменялись, в основном добавились просто новые возможности и изменился интерфейс IDE).
8. Проектов на PostgreSQL я не делал, но PB на самом деле всеяден и поддерживает любую СУБД, лишь бы драйвер доступа были стандартным. Sequiensed я так понимаю прекрасно настраиваются так же, как и написано в FAQ для Interbase или Access. Рекомендую просканировать данные форум по различным решенным/нерешенным проблемам взаимодействия PB с Ораклом и погонять их на своей СУБД, так как насколько я понимаю они все таки родственники.

P.S. В основном я рассказал о достоинствах PB 9 с собственного годовалого опыта общения с ним. Конечно же существует и куча недостатков, но с точки зрения именно сравнения PB с Access, на мой взгляд он одно большое достоинство :)