Кину в общую корзину еще про PB:
1. Доступ к данным DataWindow организован в виде 2-мерного массива

Что это дает ? Получается, что у DataWindow можно получить или записать значение любого поля и записи (даже для множества полей и записей) очень элементарным путем и никаких движений курсором по нему. Понятие текущей записи - это только для визуального представления DataWindow и оно указывает что конкретно сейчас видит и редактирует пользователь.

2. Expression в DataWindow - очень похоже на принципы Crystal Report. То есть на любое свойство контрола или поля DataWindow спокойненько можно впихнуть скрипт, который в зависимости от условий будет определять значение свойства. Допускается использование функций, написанных вами. Простой пример мощности такой технологии -берем поле Name, на свойство Background Color вешаем следующий Expression:

В итоге в представлении DataWindow поле Name будет выделятся красным цветом, если значение поля Value предыдущей строки меньше нуля (!!!). Думаю если иметь фантазию, то Expression применение не малое найдется как в формах, так и отчетах DataWindow. С учетом того, что DataWindow позволяет программе подсунуть любой Expression и он его выполнит, он еще является некоторым подобием легендарной макроподстановки фокса.

3. DataWindow изначально работают по технологии кэшированных изменений, причем самое похожее к нему, что я видел по принципам работы - это DataSet из .NET . Хотя на самом деле мне в PB больше нравиться - все гораздо умнее сделано, особенно если вспомнить вышеуказанные здесь буфера. Радует, что PB изначально очень граммотно получает данные и отсылает их изменения на сервер. Можно ручками настроить принципы сохранения измененных данных даже для сложных, казалось бы не редактируемых запросов. Identity поддерживается нормально. Также есть возможность проводить изменения в БД посредством указанных хранимых процедур. Все SQL скрипты элементарно перехватываются в специально созданных для этого событиях, так что сделать для клиента SQL монитор - пару строк кода, еще можно перехватывать SQL скрипт изменения записи, который PB уже сформировал, но еще не послал и даже его поменять или дописать по необходимости.

4. Поддержка зашаренных DataWindow очень мощная технология, которая позволяет какому то DataWindow ссылаться на данные, содержащемся в другом DataWindow. Что мы с этого имеет - легко можно на форму кинуть DataWindow в виде представления Grid, плюс сделать возможность вызывать дополнительное окно редактирование с представлением FreeForm для определенной записи. Причем данные для обоих DataWindow будут общие, а вот текущая запись у каждого своя и можно спокойненько для каждой требуемой записи создавать свое окно редактирования. Еще плюсик - делаем 2 DataWindow на один источник данных - один в виде грида, другой в виде отчета. Отчет шарим на грид. В итоге меняем данные в гриде, отчет (или график например) на автопилоте тут же пересчитывается. Получили редактируемый отчет. Данные кстати прекрасно экспортяться, так что никто не мешает сохранить записи на диск, потом в любой момент восстановить.

5. О встроенном SQL уже упоминали, что он пишется прямо как код программы и соотвествующе компилируется и проверяется на синтаксис, что является несомненным преимуществом. Однако еще замечательно, что SQL в PB позволяет писать скрипты без описания параметров запросов:

Теперь представьте, что можно с этим сделать, особенно если вспомнить, что помимо явного описания скрипта PB поддерживает динамический SQL и работу с курсорами.

6. PowerScript забавный конечно язык - этакая помесь Basic и Java (да да, больше во многом похоже на Java, а не Си). Непривычный сначала, но как оказывается очень удобный. Писать на нем графические приложения или визуальные компоненты конечно не стоит, зато вот под создание клиентских частей он очень даже неплохо продуман. Тут не только языки до кучи смешаны, но и технологии тоже - ООП мирно уживается с процедурными элементами программирования, сборщик мусора не мешает самому программисту по необходимости удалять обьекты, массивы мирно уживаются и так же часто используются как коллекции, данные можно хранить как в структурах, так и полях обьектов.

Однако хотелось бы обратить внимание на 2 самых замечательных вещи: это безразмерные массивы и события. Думаю все согласяться что работать с массивами все таки легче, чем с коллекциями, особенно если массивы позволяют динамически менять свой размер и автоматом поддерживают операцию присваивания. А уж если массивы участвуют как свойства в базовых компонентах PB, так это вообще приятно.

События это отдельный разговор - во всех языках программирования событие - это оповещение подписчиков от некоего класса о произошедшем действии. В PB событие - это с точностью до наоборот - действие некоего класса на вызов его события кем то. События могут наследоваться, однако в отличие от наследований в методах классов порядок выполнения события идет от предка к наследнику. Второе отличие событий от методов класса - разрешается их динамический вызов, который в отличие от динамического вызова метода класса (он тоже есть, правда его правильней назвать отложенный вызов) не приведет к ошибке выполнения. Пример:

Теперь самое главное - в PB для выполнения функций и событий поддерживается очередь (!!!), т.е. их отложенное выполнение. Так что если например во время выполнения кода события из него необходимо вызвать некое действие или событие, которое противоречит выполяемому событию и должно выполниться только после окончания всех текущих действий, пишем:

и гарантированно получаем нужный результат без всяких заморочек.

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

a. Проектирование библиотек общего назначения, служащих хранилищем расширенных по функционалу решений (например у меня свой унаследованный от стандартного DataWindow контрол, позволяющий много чего, вплоть до записи в ini их настроек).
б. Проектирование библиотек маштаба предприятия (или каркасов для приложения). Если проект крупный, разработчиков много, то без такого шага не обойтись - все общие для проекта решения должны быть выделены в макеты и именно наследуя их, разработчики должны строить свои частные решения
в. Проектирование модулей - тут уже реализуются конкретные решения.

Так же если проект очень крупный, тиражный и предполагается его быстрое динамическое развитие для каждого клиента, то имеет смысл этап "Б" усложнить до уровня системы, имеющей свою IDE с дизайнерами DataWindow (легко реализуется засчет того, что DataWindow спокойно можно создавать во время выполнения и хранить где угодно, хоть в БЛОБах). Так же такая система должна поддерживать систему plug-in (легко реализуется засчет возможностей динамического подключения библиотек и исследования их содержимого).

Вот вроде и все по PB с точки зрения его основных достоинств по сравнению с другими инструментами построения клиентских частей. В принципе я конечно еще не упомянул о 3-звенке, быстрой разработке web-приложений и других интересных возможностях, но достаточно сказать, что это есть, легко программируется и надежно работает.

P.S. Для описания использовался PB версии 8.0 . Что там они придумали в 9-ой версии, понятия не имею.

Тем кто постоянно проектирует клиентов БД для сложных и больших проектов настоятельно рекомендую посмотреть в сторону PB. Самое плохое, что документации почти ноль. Для московских программистов или бывающих здесь проездом могу поделиться компактом с 2 книжками по PB (пересланными мне с Украины), правда отсканенными в jpg и по 5 и 6 версиям PB, но как говориться на безрыбье и рак рыба :) Так же их можно скачать с ftp одного хорошего человека, который согласился их выложить:

он правда из германии, поэтому я не знаю, насколько у них вечер отличается и ночь от наших :)

Со мной же лучше всего связаться для начала по моему мылу.

Crip
Все есть везде. Другое дело какой ценой это все достается. Для меня корректное сравнивание инструментов - это в первую очередь не их возможности, а заложенные в них концепции правил проектирования и реализации продуктов. В PB я считаю сама модель правил проектирования проектов правильная, все логично, продуманно, никаких прикруток и довесок, строгая ориентация средства только на построение клиентов релляционных БД. Может ли VFP похвастаться тем, что он изначально был ориентирован на работу с SQL БД, что в нем все изначально продуманно и нет никаких "левых" решений в виде прикруток и довесок, противоречащих его изначальным концепциям ? Я VFP не видел, поэтому ответ за Вами. Однако в свое время я очень много работал с ForxPro 2.0-2.5 и хорошо зная как и с чем он работал сильно сомневаюсь, что он стал таким вот удобным средством для проектирования сложных клиентских приложений. Я не сомневаюсь, что MS вставил в VFP все, что только имеет громкое имя и может принести деньги - ООП, интернет, 3-звенки и т.д., но я знаю, к чему это приводит - наслоению технологий, путанице и возрастанию размера и читабельности кода.

PB изначально был спроектирован под клиент-серверные системы, с поддержкой принципов ООП, SQL, кэшированных изменений и мощным механизмом полученных с БД обработки и отображения данных. Правильная модель его реализации и явилась залогом того, что любые его новые возможности органично вписываются в него, позволяя оставлять те же концепции проектирования программ, расширяя их новыми функциональными возможностями.
FoxPro был изначально спроектирован под файл-серверные системы, как клон процедурного D-Base языка. По моему этим сказано все. В свое время я писал на FoxPro крупные проекты, которые до сих пор крутяться и прекрасно работают. Однако времена меняются и считающиеся тогда крупные проекты семечки по сравнению с тем, чем я занимаюсь теперь, что привело к моему переходу с файл-серверных на клиент-серверные технологии и соотвествующе и выбору других средств проектирования клиентов.

Пока писал ... новый пост от Вас появился. Прокоментирую:

Что-бы приложение получилось работоспособным никакие визарды и генераторы не подойдут
Ни о каких генераторах и визардах в PB речи я не вел. Их там особо и нет. Все дело в правильной модели PB, отсюда и мало кода.

И еще повторюсь MS плавно пытается увести людей с фокса на .NET
Насчет увести с фокса на .NET - чисто маркетинговый ход. Я пока не увидел чего то револлюционного в .NET, что действительно бы облегчило работу по созданию клиентских приложения. Я бы даже сказал усложнило на самом деле, так как компонентая модель ООП конечно универсальна, но усложняет проектирование и кодирование узконаправленных приложений, хотя оставляет широкий выбор расширения средств. Думаю зависимость между универсальностью, скоростью и качеством величина постоянная для любого средства и чем то жертвовать приходится всегда. В PB ООП обрезан по самое не хочу - там он реализован ровно настолько, чтобы позволить проектировать иеархию повторно используемых решений в проекте и писать 3-звенки. Больше на нем ничего не сделаешь. В C# можно делать все, но только через ООП и соотвественно классы и компоненты, что приводит к скатыванию кода до уровня управления классами, понижению его читабельности и возникновению многих проблем при решении узкоспециализированных задач, решения которых гораздо спецефичнее, чем набор предлагаемых классов и компонент для решения общего круга задач.

Видать то , что в прошлом было написано куча корявых прог под ДОС испортило
Извините - но насчет кучи корявых прог под ДОС - это необоснованный выпад. Куча корявых прог есть на любом средстве программирования и я бы сказал ДОСовый Fox как раз может гордиться тем, что стал "учителем" очень многих сейчас уважаемых и проффесиональных программистов, как кодеров, так и проектировщиков БД. Ради интереса поспрашивайте на форумах SQL.RU, сколько сейчас "крутых" программистов с Фокса слезло - думаю статистика Вас удивит. Заодно можете спросить, почему они с Фокса слезли в свое время.

И в любой работе самое главное это решение поставленной задачи, а как это должно мало волновать заказчика...
Как решается задача очень даже должно волновать заказчика. Ведь ему потом на этом продукте работать и возможно своими силами сопровождать не один год в условиях постоянно динамически изменяющихся внешне и внутре экономических условий. Вам не кажется странным, что не только в мире, но и у нас очень много крупных проектов реализовано с использованием PB и проекты уже годами сопровождаются силами внутренних АСУ (хоть в тех же крупных американских банках) ? Причем никто из них особо о смене инструмента не говорит, не смотря на то, что некоторые проекты были написаны 10 лет назад. И зарплаты PB программистов там стабильно держаться на высоком уровне (да и у нас кстати тоже, правда по причине отсуствия таких программистов). Думаю это хороший показатель в пользу того, что проекты на PB легко реализуются и в дальнейшем так же легко сопровождаются.

P.S. Кстати не знаю насколько это правда, но читал, что PB выступил в роли дедушки Access и VB, чему немного верю, с учетом того что формы Access уж очень во многом напоминают DataWindow из PB, который был сделан гораздо раньше, чем Access. PowerSoft-овцы утверждают, что Билли лично к ним приезжал, смотрел на их разработки и в первых версиях Access и VB участвовала команда разработчиков PB, в том числе и Watcom-вцы, которые в свое время разработали по заказу PowerSoft язык PowerScript и виртуальную машину PBVM. Вот такие вот сплетни ходят по интернету :)

Crip
А меня наоборот удивляет подход людей, знакомых только с VFP - когда им говорят, что есть и другие технологии (заметьте я не зря очень часто повторяю именно слово другая технология, а не язык или средство) и которые сразу рвуться в бой, даже не ознакомившись с идеями, которые пытаются до них донести собеседники - прям какой то комплекс неполноценности, который приводит к тому, что на любое сравнения VFP с чем то все обижаются и говорят, что их назвали дураками.

А ведь стоило бы развивать свой кругозор и оценивать инструменты программирования не с точки зрения крутизны, а эффективности под конкретно поставленные задачи.

Я например Access рассматриваю не как язык программирования, а как настольную БД и считаю для своих целей он очень даже ничего. Если кто то на нем и пытается крупные проекты писать - так это проблема не Access, а "светлой головы" программиста.

Извините, если чем обидел, задачи такой во всяком случае перед собой не ставил. Крутизну свою доказывать не стал бы - ее уровень я и сам неплохо и точно могу оценить по кол-ву и обьему запущенных проектов :)

Просто хотелось малость расширить кругозор коллег, так как сам собственно говоря вполне недавно перелез с Delphi на PB и был страшно огорчен, что раньше никогда о нем ничего не слышал и не видел и считаю что очень много из за этого потерял :)

С чем считаю тему закрытой и говорю всем до свиданья :)