Статьи

В этой статье :

Советы и рекомендации
Расположение файлов проекта

• Расположение файлов внутри проекта
• Содержимое главной директории проекта
• Файл конфигурации CONFIG.FPW
• Как открыть проект
• Пути доступа к файлам проекта

  База данных

• Название файла базы данных
• Расположение файла базы данных
• Обслуживание файла базы данных
• А надо ли вообще использовать файл базы данных?

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

Как правило, большинство книг по программированию являются либо пересказом статей Help к языку, либо набором комиксов по типу "нажмите эту кнопочку увидите такую картинку, теперь нажмите эту кнопочку ...". Нельзя сказать, что это плохо или не нужно. Просто между двумя этими крайностями образовался провал, в котором и пропадает множество новичков. Поэтому любая книга, которая хоть как-то его закрывает обычно пользуется повышенным спросом.

О каком "провале" собственно идет речь?

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

Второй разрыв - это когда и что лучше всего применять. Обычно изложение строится таким образом: для решения задачи сделаем так, так и вот так. Но не предпринимается даже попытки объяснить, а почему собственно не иначе, когда есть другой способ? Как следствие, когда новичек узнает о том, что одну и ту же задачу можно решить даже не двумя, а тремя, четыремя и более способами у него в голове начинается полная карусель. Бросает из одной крайности в другую.

Есть и еще одна проблема, связанная с предыдущими двумя. Обычно в FoxPro начинают разбираться люди, уже попробовавшие свои силы в программировании на других языках (чаще всего в Delphi или Basic, да даже программисты работавшие ранее в FoxPro for DOS) и они пытаются применить стиль программирования хорошо (или не очень) им известного языка в Visual FoxPro и очень удивляются сталкиваясь с неожиданными (в смысле - не ожидАемыми) проблемами: вот ведь, в руководстве написано, что это можно, а у меня не выходит! А проблема оказывается в самом стиле программирования. Кое-какие приемы, хорошо работающие в Delphi для FoxPro являются попросту неприменимы.

Вот я и попытаюсь заполнить этот "провал" и описать некоторые рекомендации по программированию на FoxPro, с пояснениями почему собственно желательно делать так, а не иначе.

Советы и рекомендации

FoxPro - это язык, который очень снисходительно относится к ошибкам программиста: не дали определения переменной - ничего, я сам определю; забыли указать рабочую область - ничего, я сам попытаюсь ее найти. И так во многих случаях, если Вы забыли что-то указать FoxPro самостоятельно попытается это что-то найти.

С одной стороны, это конечно хорошо и облегчает жизнь програмисту, но вот с другой при создании достаточно крупных проектов в результате такой "самодеятельности" со стороны FoxPro могут возникать ошибки, которые очень трудно отловить.

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

Со стороны разработчиков FoxPro уже явно наметилась тенденция к ужесточению синтаксиса. Оно и понятно, такие языки программирования и создавать легче, да и библиотеки поддержки будут иметь меньший объем. Но пока это только тенденция, посмотрим, что будет дальше.

С другой стороны, конечно просто замечательно, что FoxPro предоставляет возможность решить одну и ту же проблему несколькими способами, но если в каждом конкретном случае размышлять на тему "что лучше использовать", то Вы никогда не закончите ни одного приложения.

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

Расположение файлов проекта

По большому счету, проект - это набор файлов. Возникает вопрос - где и как их расположить? Если у Вас он не возникает, то Вы или очень опытны (это же очевидно!), или наоборот очень неопытны (а разве это важно?).

Главным правилом в данном случае выступает разделение рабочих (модифицируемых) файлов и исполняемых (не модифицируемых). Имеется в виду прежде всего их физическое (по разным директориям) разделение.

Причина такого "неравноправия" прежде всего в том, что есть серьезные опасения в порче исполняемых файлов. Пусть случайное и непреднамеренное. Но если рабочие и исполняемые файлы лежат в одной директории, то очень легко ошибиться с выбором и модифицировать не тот файл. В результате - FoxPro или начнет работать с ошибками или вообще перестанет работать.

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

Необходимость копирования объясняется как минимум необходимостью создания резервных копий всех рабочих файлов (есть и другие причины). По самой своей сути программирование - это модификация файлов. А файл можно "модифицировать" так, что мало не покажется. После чего остается только полностью удалить эту "модификацию" и начать все заново. Хорошо, если у Вас есть резервная копия, тогда Вы начнете не с нуля. А если нет?

Еще одной немаловажной причиной хранения файлов проекта отдельно от файлов FoxPro является удобство поиска нужных рабочих файлов. Если они свалены в одну "кучу" с рабочими файлами FoxPro, то становится очень тяжело найти нужный файл.

Итак, файлы Вашего проекта не следует хранить в той директории, где установлен собственно FoxPro. Следовательно, необходимо создать отдельную директорию для Ваших проектов.

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

В идеале, хорошо бы давать имена директорий в DOS-формате (т.е. до 8 символов), но это уже перестраховка. Уместитесь в 8 символов - хорошо, нет - ничего страшного.

Расположение файлов внутри проекта

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

Прежде всего, обязательно следует выделить отдельную директорию для хранения базы данных. Как правило, эту поддиректорию так и называют "DATA". В этой директории хранится как файл контейнера базы данных (DBC, DCT, DCX), так и файлы собственно таблиц (DBF, FPT, CDX)

Прочие файлы также следует "раскидать" по поддиректориям, но тут уже возможны варианты.

В примерах от MicroSoft рекомендуется хранить файлы по их типам: формы в директории Forms, классы в директории Class и т.п. Однако я предпочитаю хранить файлы по их логическому назначению: главные файлы программы в директории Main, файлы для работы со справочниками в директории SPR, файлы для работы с документами в директории Document и т.п. Какой вариант примете Вы - не так важно. Главное, чтобы у Вас файлы были "раскиданы" по нескольким директориям

Итак, в результате у Вас получится примерно следующая структура каталога Вашего проекта

C:\ProjVFP 
  C:\ProjVFP\MainProj 
  C:\ProjVFP\MainProj\Class 
  C:\ProjVFP\MainProj\Data 
  C:\ProjVFP\MainProj\Forms 
  C:\ProjVFP\MainProj\Prg 

Здесь каталог C:\ProjVFP - предназначен для хранения многих проектов, которые Вы без сомнения еще напишите. А собственно уже конкретно Ваш проект расположен в директории C:\ProjVFP\MainProj

Содержимое главной директории проекта

Ну хорошо, раскидали мы файлы по разным поддиректориям, а что же остается внутри главной директории проекта?

А вот внутри главной директории остается, во-первых, собственно файл проекта (файлы с расширением PJX, PJT), во-вторых, обязательно файл конфигурации CONFIG.FPW (это обычный текстовый файл, о нем чуть ниже) и в-третьх, файлы ресурсов FoxUser.DBF и FoxUser.FPT Прочие файлы уже по мере необходимости в конкретном проекте, но как правило, больше ничего здесь храниться не должно.

Вполне естесственное желание, назвать файл проекта тем же имененем, что и директория в которой он расположен, поскольку собственно ради него все это и затевается. Именно так и следует поступить - назвать файл проекта MainProj.pjx (и MainProj.pjt)

Файл ресурсов FoxUser.dbf и FoxUser.fpt можно и не создавать специально, а только сделать специальную запись в файле конфигурации (в этом случае он будет создан автоматически).

Зачем вообще надо тащить этот файл ресурсов в директорию проекта? Дело в том, что файл ресурсов хранит в себе координаты и положения всех когда-либо открываемых окон в среде FoxPro. Это значит, что в случае использования одного и того же файла ресурсов для всех проектов это файл "раздуется" до неимоверных размеров. А ведь в случае копирования проекта домой, желательно захватить с собой и файл ресурсов, чтобы "картинка не сбилась". Удобнее это сделать, если файл ресурсов физически расположен в той же директории, где и сам проект, а не искать его в директории FoxPro.

Определить какой именно файл ресурсов используется и где он находится можно с помощью функции SYS(2005)

Файл конфигурации CONFIG.FPW

Теперь важнейший вопрос о файле конфигурации CONFIG.FPW. Это обычный текстовый файл и о нем почему-то крайне редко упоминается в книгах о FoxPro. Этот файл необходимо создать самостоятельно. Автоматически он не создается.

Как правило, используют 2 файла конфигурации - один на этапе создания и отладки проекта и другой - на этапе исполнения собственно готового EXE у клиента. Тот файл конфигурации, который поставляется клиенту можно включить внутрь EXE, но лучше этого не делать. В этом случае он позволяет производить некоторую внешнюю настройку среды FoxPro даже в готовом EXE.

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

CODEPAGE=1251  
RESOURCE=FoxUser.dbf  
TITLE=Мой новый проект  
PATH=Data,Forms,Class,Prg  
COMMAND=MODIFY PROJECT MainProj.pjx

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

RESOURCE - эта опция говорит о том, что в качестве ресурсного файла выступает файл FoxUser.dbf расположенный в директории по умолчанию. Если такого файла там нет, то он будет создан автоматически. В принципе, Вы можете указать абсолютно любое имя для ресурсного файла, но лучше придерживаться принятого стандарта, чтобы не запутаться.

TITLE - эта опция задает текст заголовка главного окна FoxPro вместо стандартного "Microsoft Visual FoxPro". Заключать текст заголовка в кавычки не надо.

PATH - еще одна очень важная настройка. Она говорит FoxPro о том, где следует искать файлы (в каких директориях) относительно текущей директории. В качестве разделителя можно указывать как просто запятую, так и символ точки с запятой. Подробнее о путях доступа чуть ниже.

COMMAND - эта опция задает команду, которую необходимо выполнить в момент открытия среды FoxPro. К сожалению, нельзя указать несколько опций COMMAND. Из них будет выполнена только одна. Но если Вам необходимо выполнить несколько команд при открытии среды FoxPro, то напишите их все в специальном файле PRG и опция будет выглядеть например так:

COMMAND=DO Start.prg  

По умолчанию, FoxPro "запоминает" последний открытый проект и пытается его открыть при каждом открытии среды FoxPro. Это удобно, когда Вы работает с одим проектом, но при работе с несколькими проектами это раздражает. Отключить режим автоматического открытия последнего открытого проекта можно в среде FoxPro: Пункт главного меню Tools -> Options -> закладка View -> Снять "птичку" в пункте "Open last project on startup" и сохранить настройки по кнопке "Set As Default". А для открытия "нужного" проекта при открытии FoxPro как раз и используется опция COMMAND в файле конфигурации.

В файле конфигурации можно сделать еще много различных настроек, но в большинстве случаев это не нужно. Например, большинство команд SET по умолчанию настроены как раз таким образом, который помогает отлаживать проект. Т.е. делать их перенастройку в файле конфигурации просто не имеет смысла.

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

Как открыть проект

Обратите внимание, что я не указал в файле конфигурации директории по умолчанию. В принципе, это можно сделать используя опцию DEFAULT примерно так:

DEFAULT=C:\ProjVFP\MainProj  

Однако есть способ лучше. Для открытия проекта создайте ярлык на рабочем столе со следующими реквизитами (у меня VFP6, поэтому пути соответствующие)

Командная строка

"C:\Program Files\Microsoft Visual Studio\Vfp98\VFP6.EXE" -T -C"C:\ProjVFP\MainProj\config.fpw"
Директория по умолчанию "C:\ProjVFP\MainProj"

Ключи запуска можно записать вместе как "-TC". Ключ "-T" говорит о том, что при запуске среды FoxPro не надо отображать заставку-логотип, а ключ "-C" говорит о том, что следом за ним указан полный путь доступа вместе с именем файла конфигурации, который следует использовать при запуске среды FoxPro. Строго говоря здесь можно указать абсолютно любое имя файла конфигурации, но лучше придерживаться принятого стандарта, чтобы не запутаться. В следующей строке Вы указываете и собственно директорию по умолчанию, которой и является та директория в которой расположен Ваш файл проекта.

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

Пути доступа к файлам проекта

Итак, если Вы последовали всем приведенным выше рекомендациям, то у Вас должно получится следующее: При запуске среды FoxPro в качестве директории по умолчанию устанавливается директория, где расположен сам файл проекта, а все прочие файлы проекта располагаются в поддиректориях.

Как же в этом случае обратится к рабочим файлам проекта?

Если Вы указали опцию PATH в файле конфигурации, то обращаетесь так, как-будто все файлы проекта лежат в текущей директории, например:

USE MyTable.dbf  
  DO FORM MyForm.scx 

Несмотря на то, что физически таблица MyTable.dbf находится в папке "DATA", а файл формы MyForm.scx в папке "Forms" FoxPro тем не менее найдет и запустит нужные файлы, поскольку путь доступа к ним был прописан в опции PATH в файле конфигурации.

Использование путей доступа в настройках файла конфигурации (или же программно в стартовом файле проекта) позволяет в простых случаях легко переносить проект из одной директории в другую. То же самое можно сказать и о данных. Вы спокойно включаете таблицы в DataEnvironment форм и отчетов не заботясь о том, что у клиента эти таблицы физически будут расположены в других директориях. Они все-равно будут найдены, если задан путь доступа к ним.

Разумеется, есть ситуации, когда простого указания путей доступа оказывается недостаточно. Например, когда Вы одновременно работаете с несколькими одноименными таблицами принадлежащими разным базам данных. В таких случаях используются различные приемы принудительного указания абсолютных путей доступа (здесь я их рассматривать не буду). Но в большинстве случаев использование настройки PATH оказывается вполне достаточным.

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

Кроме того, облегчается процесс создания резервных копий (да и просто копирования) файлов Вашего проекта. А также снижается вероятность порчи рабочих файлов собственно FoxPro.

База данных

По большому счету, под термином "база данных" понимают совокупность всех данных, а также наложенных на них правил и ограничений, обеспечивающих целостность и непротиворечивость этих даных. Иногда его действительно употребляют именно в этом смысле, однако чаще всего в FoxPro этот термин понимается в более узком смысле

База данных - это файл с расширением DBC, а также связанные с ним файлы с тем же именем, но с расширениями DCX и DCT

Более правильно было бы применять термин "контейнер базы данных". Подозреваю, что от него и произошло название расширения (первые буквы в английском DataBase Container). Однако в связи с привычкой американцев все сокращать слово "контейнер" как-то затерялось.

В версиях FoxPro 2.x под термином "база данных" понимали то, что сейчас понимают под термином "таблица", просто потому, что в этих версих еще не было файла DBC. Из-за чего часто возникают недоразумения и недопонимания.

По своей сути, файл DBC - это обычный файл DBF, только с измененным расширением (как и большинство других файлов используемых в FoxPro). Соответсвенно DCT - это файл мемо-полей (переименованный FPT), а DCX - это структурный индексный файл (переименованный CDX). Отличие от простого файла DBF заключается только в содержимом 28 байта заголовка (считая что первый байт имеет порядковый номер 0). В файле базы данных в этом байте заполнен 3 бит (чего нет в DBF-файлах). Т.е. ASCII код записанного там символа не менее 4 (обычно 7), в то время, как у DBF-файлов его содержимое наоборот не превышает 3.

Поскольку файл базы данных - это обычный файл DBF, то Вы можете открыть его как таблицу и просмотреть содержимое.

USE MyBase.dbc AGAIN  

Указывать расширение файла, как и опцию AGAIN в этом случае обязательно. Без указания расширения FoxPro посчитает, что его расширение DBF и ошибется. А опция AGAIN нужна потому, что файл базы данных может быть уже открыт командой OPEN DATABASE и без этой опции Вы также получите сообщение об ошибке

Зачастую, открытие файла базы данных как таблицы в более ранних версих FoxPro был единственной возможностью быстро получить нужную информацию. Например, какие таблицы базы данных имеют поле с заранее известным именем "MyField"? Для ответа на этот вопрос строим SQL запрос примерно следующего содержания:

SELECT a.ObjectName ;  
        FROM MyBase.dbc a ;  
        INNER JOIN MyBase.dbc b ON a.ObjectID=b.ParentID ;  
        WHERE a.ObjectType='Table' and b.ObjectType='Field' and ;  
               b.ObjectName=PADR(LOWER('MyField'),128)

Но я бы не рекомендовал пользоваться такими "хакерскими" трюками и использовать штатные функции для работы с файлом базы данных INDBC(), DBGetProp(), ADBObjects() и тому подобное, поскольку в этом случае слишком велик риск непреднамеренной порчи файла базы данных.

Название файла базы данных

Файл базы данных, как и любой другой файл в системе Windows может содержать до 128 символов, содержать пробелы, русские символы, цифры и некоторые спец.символы. Однако для упрощения работы в FoxPro я бы порекомендовал следующие ограничения в наименовании файла базы данных

• Не использовать в названии русские символы - причина этой рекомендации в том, что FoxPro разрабатывался прежде всего для англоязычных пользователей и использование в нем символов другого языка - это уже последующее дополнение. Как следствие, велик риск, что чего-то, где-то недосмотрели и при определенных ситуациях русские буквы в имени вызовут неожиданные глюки
• Не использовать в названии пробелы - в принципе, ошибок использование пробелов не вызовет, но несколько усложнит сам процесс программирования, поскольку имена и пути доступа, содержащие пробелы необходимо заключать в кавычки. Просто добавит лишней заботы - не забывать кавычки. А зачем усложнять себе жизнь, когда без этого легко можно обойтись.
• По возможности, ограничивайте длину названия 8 символами и не используйте в названии цифр и спец.символов - на самом деле я не вижу разумных объяснений этому ограничению. Но дело в том, что подавляющее большинство системных файлов и файлов примеров в FoxPro (да и собственно системы Windows) ограничены как раз-таки именно 8 символами и не используют ни цифры ни спец.символы. Зачастую в ущерб информативности названия. Почему разработчики идут на такое ограничение не понятно, но имеет смысл последовать их примеру. Видимо на это есть какие-то причины, кроме привычки к DOS-нотации
• Не называйте файл базы данных также как и один из содержащихся в ней объектов - не обязательно речь идет о таблицах, это может быть совпадение с названием Local View, или индексного тега, или поля таблицы, да мало ли чего еще... Разумеется ошибки это не вызовет, но усложнит понимание написанного кода самим программистом. Не всегда с ходу можно однозначно определить, что речь идет именно о файле базы данных, а не о каком-либо другом объекте. А если еще и их названия совпадают, то совсем тяжело становится.
• Не используйте для названия одно из зарезервированных в FoxPro слов - опять же, ошибки это не вызовет, но резко снизит "читабельность" кода. Ведь зарезервированные слова автоматически подсвечиваются опеределенным цветом (если Вы используете стандартный текстовый редактор FoxPro) и с ходу становится проблематично отличить опцию или команду от имени файла базы данных
  

  Расположение файла базы данных

Как для файла базы данных, так и вообще для всех рабочих таблиц использующихся в проекте следует выделять специальную папку (директорию). Эта рекомендация относится как к этапу разработки проекта, так и к поставке готового приложения клиентам.

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

Желательно файл базы данных располагать в той же папке, где и включенные в него файлы DBF

По большому счету, конечно можно держать файл базы данных в одной директории, а включенные в него файлы DBF в другой. Но это усложняет сам процесс разработки проекта. Например, создание резервной копии в простейшем случе заключается в простом копировании директории с рабочими файлами в другое место. Если же рабочие файлы отделены от файла базы данных, то потребуется уже копирование 2-х директорий. Соответственно усложнится код.

Кроме того, в этом случае несколько увеличится размер файла базы данных (точнее файла DCT - мемо-файла), поскольку непосредственно в нем хранится относительный путь к включенным в него таблицам. Если таблицы расположены в той же директории, что и сам файл базы данных, то этого относительного пути просто нет. Справедливости ради, следует заметить, что относительный путь к базе данных хранится и в заголовках таблиц, которые в эту базу данных включены. Но на размер таблиц это не влияет, поскольку под этот относительный путь всегда выделяется фиксированное место вне зависимости от факта его наличия.

Обслуживание файла базы данных

Собственно, обслуживание файла базы данных заключается в его регулярной "чистке". Поскольку файл базы данных - это обычная DBF-таблица, то и удаление из него происходит так же как и в таблице в 2 этапа: сначала записи только помечаются как удаленные, но физически не удаляются. А для физического удаления необходимо выполнить упаковку файла базы данных.

На этапе разработки для этой цели используется специальный пункт меню в режиме модификации базы данных: пункт главного меню Database->Clean Up DataBase. Фактически, этот пункт меню выполняет команду PACK для файла базы данных, поэтому требует эксклюзивного открытия базы данных (в режиме EXCLUSIVE). Если база данных открыта в режиме SHARED, то этот пункт меню будет недоступен.

Кроме собственно чистки файла базы данных от ранее удаленных записей, выполнение этой операции существенно уменьшает размер файла DCT в котором хранятся в том числе все "хранимые процедуры". Поэтому после внесения изменений в хранимые процедуры также желательно сделать чистку базы данных.

На этапе выполнения у клиента необходимость чистки базы данных возникает только в том случае если Вы динамически добавляете и удаляете какие-либо объекты в базу данных. Например, создаете Local View командой CREATE SQL VIEW. Или модифицируете какие-либо свойств по DBSetProp(). Или модифицируете таблицы по ALTER TABLE.

В этом случае чистка базы данных выполняется с использованием обычной команды PACK примерно таким образом

SET DATABASE TO MyBase  
  CLOSE DATABASE  
  OPEN DATABASE MyBase EXCLUSIVE  
  SET DATABASE TO MyBase  
  PACK DATABASE  
  CLOSE DATABASE  
  OPEN DATABASE MyBase SHARED  
  SET DATABASE TO MyBase  

Разумеется, это только общая схема, здесь опущены различные проверки необходимые в полноценном приложении.

Если же Вы никаким образом не модифицируете файл базы данных на этапе работы у клиента, то и нет необходимости в чистке файла базы данных.

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

А надо ли вообще использовать файл базы данных?

Подобный вопрос очень часто задают программисты, которые раньше работали на FoxPro 2.x, где этого файла просто не было. Да и сам FoxPro вполне способен работать и со свободными таблицами безо всякой базы данных. Отвечу сразу - надо! А теперь попробую объяснить почему.

• Использование файла базы данных расширяет возможности таблиц DBF.

  Например, в файле DBF в принципе нельзя дать полю название содержащее более 10 символов, но если он включен в базу данных, то название поля может уже содержать до 128 символов. Никакие правила (RULE), значения по умолчанию (DEFAULT), триггера и кое-что другое попросту невозможны в файле DBF вне файла базы данных. Точнее так - невозможно их автоматическое выполнение.

• Использовании файла базы данных позволяет выполнять операции, которые крайне сложно организовать другими способами

  Например, такая операция как "транзакция" может быть реализована только среди таблиц DBF включенных в базу данных. В принципе, этот процесс можно организовать и со свободными таблицами, но это потребует от программиста значительных усилий. А такой замечательный объект как обновляемый Local View - сколько усилий требовалось при программировании в FoxPro 2.x для реализации того, что этот объект делает автоматически!
  Вобщем, использование файла базы данных серьезно облегчает жизнь программиста.