Igor KorolyovVB6 значительно проще фокса - отсутствие ООП там ставит его в заведомо неудобную позицию - какое наследование, какие классы - не нужно ничего этого изучать. Максимум что нужно - хорошее понимание COM - хотя до этого среднему VB-ко тоже очевидно надо дорасти. C#/VB.NET и прочие - как это ни странно тоже значительно проще в изучении - так что вы не правы...
Тех, кто использует ООП в VFP - единицы. Это скорее исключение, чем правило. Средний фокспрошник, как правило, ни сном, ни духом не ведает о том, что ООП использовать местами гораздо удобнее, а тянет за собой процедурный стиль. Это из моей практики.

Igor KorolyovВообще-то создание кросс-таблицы в фоксе - т.е. его родными средствами (из курсора полученного например с того-же MS SQL) занимает порядка 30 секунд (именно написание кода, не последующая работа его :) там уже от объёмов всё зависит) - даже в View/Query designer можно просто потыкав кнопки сделать это...
Я противник такого подхода. Являюсь сторонником того, что все данные должны обрабатываться на сервере БД (в самом распространенном случае на T-SQL для MSSQL) и готовый набор данных уже отдается клиенту. Прошли уже времена обработки данных на клиенте. Таких задач КРАЙНЕ мало, если система хорошо реализована как клиент-сервер.

Собственно оффтопик получается. Насчет языков - welcome в ветку по C# на этом же Фокспрошном форуме.
А мало предложений по работе из-за того, что язык ФоксПро как таковой - морально устарел, только и всего. Поезд Framework отправляется...

Reznichenko Y.V.Это еще как посмотреть. Еще неизвестно кому проще будет освоить NET: фокспрошнику, владеющему MS-идеологией ООП, или делфисту, привыкшему собирать программу из готовых компонентиков.
Ой не смешите меня
Я бы сказал иначе. Фокспрошнику, в среднем имеющему очень слабое понятие об ООП или не имеющему его вообще или Дельфисту изначально работающему со своим, изначально объектно-ориентированным языком программирования.
Вот это куда ближе к истине.

Igor KorolyovДумаю в NET стане будет такая-же тенденция процветать - минимум программистов-разработчиков и большинство программистов-пользователей - которые лишь мышой шевелить и умеют - ну и искать в сети всё новые и новые компоненты, вместо того чтобы взять и слегка изменить имеющуюся :)
Эта тенденция уже существует. Кол-во глупых вопросов в ветках C#, VB.NET, ADO.NET - уже гораздо больше, чем, например, год назад.
Igor KorolyovТогда велкам в написание серверной процедуры создания кросс таблицы :)
Я со своим "убогим" фоксом сделаю это в пару строк за 30 секунд (используя
написанный в незапамятные времена - ещё FPD-ные и переведенный под в VFP
минимальными усилиями - генератор кросс-таблиц).
Я и делаю кросс-табы на MSSQL-сервере T-SQL'ем. И это хорошо. И это правильно. И это, кроме всего, быстрее работает. А вот приходится поддерживать один проект на фоксе ("ERP-система", туды ее в качель), где все это сделано на стороне клиента. И когда Profiler'ом смотришь какие количества данных он гоняет с сервера и на сервер (типа select * из 5-ти таблиц, а дальше считает на клиенте) - жутко становится. А все из-за морально устаревшей, у большинства фокспрошников, идеологии обработки данных. Ну не знают как с серверами БД правильно работать и учиться не хотят. Привыкли "минимальными усилиями"(с).
Igor KorolyovКогда твой сервер стоимостью под 100000$ с софтом не меньшей стоимости начнёт судорожно дёргаться от всего-то пары десятков "тяжёлых" клиентов (которым нужно нечто посложнее чем SELECT * FROM table WHERE nPK = 123 раз в пять минут), когда администраторы начнут с умным видом суетится, перекидывая таблицы между tablespace-ами, требуя себе новый RAID массив, замену и так 2-х процессорного сервера на 4-х процессорный кластер (что конечно им не сильно и не надолго поможет)... Тогда ты очевидно переосмыслишь свои очень громкие заявления :)
Знаешь, двухпроцессорный, на двух гигагерцовых Xeon'ах старенький сервер, стоимостью гораздо менее 100000$ совершенно не дергается на сотне клиентов, если правильно построены базы, таблицы, нормально написаны хранимые процедуры и клиенты написаны так, чтобы не быть "тяжелыми"(с).
Igor KorolyovКакова конфигурация типичного клиентского компа сегодня? Какова суммарная вычислительная мощность всех клиентов в средней организации, и всех серверов там-же? Из чего мы исходим когда полностью игнорируем наличие досаточно мощной техники с клиентской стороны? Почему тогда не ставят повально вместо клиентов терминалки?
Встречаются и 500-е селероны со 128Мб оперативки и они совершенно не должны страдать в сравнении с 3000-ми Пентиумами 4 при работе с БД. Что тут неясного? Идеология "клиент-сервер" неясна или я чего-то непонимаю? А расчет написанный как ХП на сервере в любом случае быстрее и идеологически правильнее, чем перегонка данных клиенту, расчет там и перегонка обратно. А если расчет поменять? Будете обновлять все клиентские приложения? Вчерашним днем живете, товарищ.
Igor KorolyovДа нет, просто на работу то принимают обычно "манагеры" которые вообще в этом деле не в зуб ногой. Они просто не знают что такое VFP, хотя очень возможно что видели где-то FPD приложения (в магазине на кассе, в почтовом отделении, в поликлинике ...) написанные в незапамятные времена, с характерным синеньким (если цветной монитор) экраном и работающие (вот жуть то) без мышки, на 286 машине с 640Кб памяти :)
Ясное дело что после этого они вряд-ли станут искать VFP разработчика :)
Я видел кассы как под DOS на FPD файл-сервер, под Windows на VB и MSDE, так и под Linux на GNU C и MySql. Рассказывать плюсы и минусы каждого решения? Да, когда-то я сам писал клиента под кассы на Clipper'е в виде файл-сервера. Но те времена давно ушли.
Igor KorolyovАга, точно - "Дорога в никуда" - давненько уже БГ написал эту нетленку, а
ведь до сих пор помнят и до сих пор толпы фанатов по ней следуют :) К
коммунизму уже не мчимся, так хоть туда - опять к светлому будущему :)
Я бы сказал, что "Дорога в никуда" - это оставаться в стане разработчиков FoxPro. Как ни печально для вас - такова реальность. Нынче в фаворе .NET и Java разработчики или вы видеть этого не желаете или переучиваться не хотите из-за банальной лени.

ВладимирМЧеловек раньше программировал на некоем языке Z, который предполагал определенный стиль (идеологию) работы. Теперь этот человек берется изучать FoxPro, но подходит к нему с теми же приемами (стилем, идеологией), что и к тому языку Z, на котором он раньше программировал.
Естесственно, у него начинаются проблемы. Он пытается "кривизну" стиля исправить за счет программирования. Этим и обсуловлено большинство проблем.
ВладимирМ(из другой ветки подсказывает новичку как сделать кое-что)LOCAL lcNumber
lcNumber = "151"
Ну да, ну да. Ну вот приходится писать на нескольких языках одновременно.
Отсутствие жесткой типизации - это то, что меня просто убивает в FoxPro. С точки зрения, например, Си-шной идеологии. Средний фокспрошник даже не объявляет переменную и область видимости, я уж не говорю о ее типе, а сразу пишут lcNumber = "151" или lcNumber = 151, что на его взгляд почти одно и тоже.
ВладимирМВ основном, именно обучение на собственных шишках. По крайней мере, я изучал Fox именно так.
Это плохо. Уж простите, но есть даже народная поговорка о том человеке, кто учится на своих ошибках.
ВладимирМНу, не нравится тебе язык программирования - не программируй на нем!
То, что можно сделать не на Фоксе - делаю, в основном, на С#, но если жесткие ограничения по задаче - приходится писать на FoxPro.
Sergej_SЕсли рассчет ведется только для отчета, в базу ничего не записывается, зачем сервак-то грузить зазря? Качнул с него нужный диапазон и колбась его на клиенте.
Если расчет ведется для отчета - я делаю ХП на сервере, которая у меня отбирает и рассчитывает все, что нужно. И результирующий набор данных я отдаю на клиент. Надо исключать ситуации, когда с клиента делается SELECT * FROM <несколько таблиц> INTO <несколько курсоров на клиенте> и дальше ведется расчет локально. А и "ERP-системы" некоторые пишут на FoxPro с подобным подходом. Могу пальцем показать. Хранимые процедуры с параметрами гораздо удобнее. Ну почему в стане(стае;) программистов FoxPro у многих сложности с пониманием этого момента?