Хочу поделиться небольшой конкретикой на тему - что лучше - FoxPro или все остальное.

Во-первых, мой стаж программирования - 27 лет, с 1979 г. Знаю и реально программировал на более чем 30 языках, начиная с таких, как КОБОЛ, ФОРТРАН, ЛИСП, АДО, МОДУЛА и МОДУЛА-2 и заканчивая как раз xBase-языками, т.е. по большому счету - FoxPro. Так что сранивать могу просто на основани личного опыта, часто - печального. И могу ответственно утверждать - НИЧЕГО ЛУЧШЕ FoxPro просто не существует. Все остальное - это на 90% недобросовестная реклама (PR), а на остальные 10% - привычка соответствующих программеров.
Следует подчеркнуть, что это НЕ относится к чисто системных задачам - понятно, что ОС лучше всего писать даже не на ассемблере, а чисто в кодах процессора (так, кстати, и делают, когда хотят получить максимальную скорость выполнения и максимальную компактность). Ассемблер - это тоже в большой степени макро-язык.

Во-вторых, я работал в очень разных областях, самое последнее время - в банковской сфере (начальник управления информтехнологий). Образование мое (первое) - физический факультет Пермского госуниверститета, специальность "теоретическая физика", работал почти 8 первых лет в структуре Пермской группы научных учреждений Уральского филиала Академии наук СССР. Так что и предметные области знаю хорошо, и в науке, и в производстве, и в финансах.

А теперб про Fox.
Это “печальный” опыт 15 лет разработки в среде Foxа, начиная с FPD 1.0 в 1989 г. и заканчивая VFP7-9. До недавнего времени – еще 4 месяца назад – работал на очень крупном предприятии. Там на Foxе, сначала мной, а потом под моим руководством, был сделан и очень успешно работает по сю пору огромный комплекс:
Управление производством на местах (40 пользователей)
Руководство (17 пользователей)
Планово-экономическая служба (9 пользователей)
Бухгалтерия (21 пользователей)
Отдел налогобложения (5 пользователей)
МатТехСнабжение (16 пользователей)
Маркетинг (4 пользователя)
Отдел управления персоналом (6 пользователей)
Отдел проектно-конструкторский (12 пользователей)
и по мелочи еще пользователей 20
А также весь внутренний документооборот (в т.ч. СККД, СКПД, СКИД и прочее)
Не считая разработчиков – еще 6 человек
Да, СККД – это система контроля качества документации, СКПД – система контроля производственной дисциплины, СКИД – система контроля исполнительской дисциплины.

Так вот, все это удовольствие в настоящее время крутится на серверах Aquarius (2*Pentium4-2800, RAID5-160Gb, 4Gb ОЗУ, NetCard 1Gbit). Сетка построена на маршрутизаторах Cisco 2995 с гигабитными портами, пользователи подключены через 100 Мбитные коммутаторы, кабельная система – категории 5е (т.е. гигабитная), рабочие станции – от CELERON-1000 до Pentium4-3200, на всех стоят Windows2000-WS либо XP-SP1, основное требование – чтобы ОЗУ было не менее 256 Мбайт.

Размер НАШЕЙ базы составляет примерно 14 Гбайт (это без графических данных – отдел кадров хранит в базе фотографии и сканированные копии документов всех 1400 работников, это еще примерно 4 Гбайт данных – но они хранятся в BINARY-MEMO-полях, индексированы по описанию и внутренним UIDам, и потому на скорость не влияют).
Так вот, СКОРОСТЬ работы НАШЕЙ системы примерно в 7-8 раз превосходит скорость работы ФУНКЦИОНАЛЬНО аналогичной системы на MS SQL 2000 SERVER с клиентской частью на Delphi, и примерно в 11 раз быстрее, чем ФУНКЦИОНАЛЬНО аналогичная система на Oracle 8i (сервера SUN, операционка SUN Solaris, на рабочих станциях Oracle Client, и все прочие удовольствия, сам клиент тоже на Delphi) - предлагали нам раза четыре приобрести такие ERP-системы, стоимостью от 20 000 до 150 000 зеленых, каждый раз проводили сравнение – уходили с нашего предприятия пристыженные.
Имеется в виду среднее время реакции системы на набор обычных (стандартизированных) запросов, достаточно стандартный принцип сравнения.
Это как раз на ту тему, что лучше – FoxPro или всякие там так называемые “промышленные СУБД” типа Sybase, Oracle и прочие мерзости.
За последние 7 лет наша система НЕ ПАДАЛА НИ РАЗУ. НЕ ПОРТИЛИСЬ НИ ИНДЕКСЫ, НИ БАЗЫ !!! Дело в том, что КАК СПРОЕКТИРУЕШЬ СИСТЕМУ, ТАК ОНА И ПОПЛЫВЕТ !
Защищайте сервера UPSами от бросков напряжения и отключения, станции тоже.
Проверяйте индексы перед началом работы, и при необходимости восстанавливайте – это достаточно просто делается программным путем, за пару недель можно полностью отладить такую проверку, сам делал. А простые индексы восстанавливаются очень быстро.
И ВСЁ. Всё остальное – от лукавого.

PS. Возвращаясь к технологии Рашмора. При сравнении с другими системами мы поступали просто. В качестве одного из тестов брали 6 таблиц – одну, содержащую примерно 400 000 записей (номенклатурный детализированный справочник), из 26 полей, и пять более мелких, технологические справочники по 12-15 000 записей, и просили сделать один и тот же сложный запрос с рабочей станции на выборку из данного набора таблиц. Для каждой СУБД таблицы строились заново, по данным, выгруженным нами в текстовый файл – т.е., в каждой СУБД создавалась база данных, и данные туда импортировались из 6 текстовых файлов. Размер таблиц (суммарный) – примерно 70 Мбайт, имеются и числовые (типа Integer), и символьные (binary) поля, и обычные символьные поля, и логические, и мемо-поля)
VFP7 – примерно 410 секунд
Oracle 8i – примерно 3590 секунд
MS SQL Server 2000 – примерно 3090 секунд.
Вот так.

Это часть моего поста в другой форум, поэтому немного скомкано - но, надеюсь, достаточно понятно.