Теперь важнейший вопрос о файле конфигурации CONFIG.FPW. Это обычный текстовый файл и о нем почему-то крайне редко упоминается в книгах о FoxPro. Этот файл необходимо создать самостоятельно. Автоматически он не создается.
Как правило, используют 2 файла конфигурации — один на этапе создания и отладки проекта и другой — на этапе исполнения собственно готового EXE у клиента. Тот файл конфигурации, который поставляется клиенту можно включить внутрь EXE, но лучше этого не делать. В этом случае он позволяет производить некоторую внешнюю настройку среды FoxPro даже в готовом EXE.
Итак, что же должно быть в том файле конфигурации, который используется на этапе создания и изменения проекта. Вот его примерное содержание
Несколько слов о том, о чем собственно пойдет здесь речь и для чего это все было написано. Очень трудно сформулировать это все кратко, но тем не менее я попытаюсь.
Как правило, большинство книг по программированию являются либо пересказом статей Help к языку, либо набором комиксов по типу «нажмите эту кнопочку увидите такую картинку, теперь нажмите эту кнопочку …». Нельзя сказать, что это плохо или не нужно. Просто между двумя этими крайностями образовался провал, в котором и пропадает множество новичков. Поэтому любая книга, которая хоть как-то его закрывает обычно пользуется повышенным спросом.
О каком «провале» собственно идет речь?
Первый разрыв — это терминология. Определение различным терминам либо вообще не дается (дескать и так все понятно), либо дается строго научное (т.е. очень заумное, лучше бы его и не давали). В результате, читая дальнейшие статьи уже совершенно непонятно о чем собственно идет речь.
Поскольку ключевое поле — это обычное поле таблицы, то на него распространяются все рекомендации приведенные в разделе «Поля таблицы». Однако поскольку это все-таки очень специфическое поле, то для него я бы добавил следующие рекомендации
Образуйте название ключевого поля таблицы добавив к имени таблицы 2 буквы «ID» (от слова identifier — идентификатор), отбросив букву «s» если имя таблицы — это слово во множественном числе — Например, если вы назвали таблицу контрагентов «Partners», то ключевое поле будет назваться «PartnerID». При таком способе наименования однозначно можно сказать к какой таблице относится ключевое. Но не стоит назвать ключевое поле также как и собственно таблицу, поскольку в некоторых случаях станет весьма проблематично сходу определить о чем идет речь — о поле или собственно о таблице
Раньше, когда для хранения числовых данных в FoxPro существовали только поля типа Numeric перевес в аргументации склонялся в пользу использования полей типа Character, но с появлением полей типа Integer все стало не так однозначно
При сравнении способа хранения ключевого поля в символьном или числовом формате выдвигаются 3 аргумента
В числовых полях легче формировать новое значение
Символьные поля «экономичнее», т.е. можно уместить больше значений в том же размере
Символьные поля «универсальнее» при так назваемых задачах репликации, т.е. объединении не связанных между собой баз данных
Многим из нас приходилось слышать различные утверждения о Фоксе, мягко говоря, не соответствующие действительности. Здесь собрана коллекция наиболее часто встречающихся мифов, и приведены простые соображения по поводу каждого из них.
1. Microsoft собирается закрыть проект Visual FoxPro, т.к. он является конкурентом других продуктов компании.
Странно, но этот слух бродит с тех пор, как Microsoft купила права на FoxPro. А было это почти уже 10 лет назад. Что-то медлит Microsoft
2. Со времен FoxPro for Windows 2.5 в языке не было никаких принципиальных изменений, просто переставлялись номера версий.
Появились контейнеры баз данных, ООП, возможность создания COM и DCOM, работа с ADO, множество визуальных улучшений… Одно можно сказать определенно – поработав в любой более свежей версии, на старую возвращаться уже не хочется.
Таблицы FoxPro — это прямые наследники формата DBASE. В этом формате процесс удаления записей разбит на 2 этапа. Сначала записи помечаются как удаленные, но физически все еще сохраняются в таблице. А для их физического удаления необходимо дать специальную команду. Причем физическое удаление требует эксклюзивного (единоличного) доступа к таблице.
Под термином «удаление» в FoxPro понимается именно установка метки на удаление, а не физическое удаление записи в таблице. Т.е. команды DELETE, DELETE-SQL физически не удаляют записи; триггер DELETE срабатывает при установке метки на удаление; триггер INSERT срабатывает при снятии метки на удаление (ну, и при физическом создании новой записи)
Цель данного раздела — это не ознакомление со всеми существующими в FoxPro типами данных, а описание некоторых особенностей использования тех или иных типов данных. Понимание этих особенностей позволит упростить выбор типа данных при проектировании таблиц. А также уменьшить количество ошибок в программе.
Прежде всего, следует понимать, что существуют типы данных переменных памяти и типы данных полей таблиц. Это далеко не одно и то же. Например, если Вы используете в таблице поле типа Character, то количество символов в таком поле всегда ограничено некоторым числом не превышающем 254 символа. Но переменная памяти имеет значительно больший размер, ограниченный количеством символов 16,777,184
Важнейшим элементом любой системы управления базами данных является наличие средств ускоренного поиска данных, поскольку поиск — это самая распростарненная операция в системах обработки данных. Но простое сканирование исходной таблицы в поисках нужной записи — это относительно медленная операция. В предельном случае, необходимо будет просканировать все записи таблицы, чтобы найти нужную запись или убедится, что такой записи не существует. Чтобы уменьшить количество просматриваемых записей, как правило, создают специальный файл, который содержит в себе нечто вроде списка пар: значение записи — номер запись. Т.е. в этом файле, перечисленны все значения некоторого поля или функции полей таблицы и указаны идентификаторы соответсвующих записей Этот специальный файл называют индексным файлом, а имя поля или функцию полей, на основе которого вычисляется значение записи — индексным ключем
В FoxPro существует некоторая путаница с этим термином (впрочем, как и с большинством других терминов), вызванная не столько неясностью самого термина, сколько особенностью его использования.
Триггер — это выражение, значение которого вычисляется при наступлении определенного события. Это выражение должно вернуть обязательно логическое значение .T. или .F.
Но все дело в том, что в качестве одного из аргументов этого выражения может стоять некоторая функция (или несколько функций). Вот эти-то функции, вызываемые из выражения триггера, также называют «триггер».
Как правило, когда речь идет о триггере, то подразумевают именно функцию — триггер, а не выражение — триггер.
В далеком, теперь уже, 1994 году, в свете развития всяких ООП технологий , в том же Turbo Vision, захотелось и мне в Фоксе придумать нечто такое же, пусть, хоть и отдаленно напоминающее сие новаторства. Собственно все сводилось к возможности получения результата функции из внешнего, по отношению к текущему, модуля. Если разработчики дали возможность использовать конструкции DO Func1 in Module1
То почему-то не дали возможности хотя бы сделать так Do Func1 in Module1 to myVar
Хотя и такая конструкция, меня не устраивала. Хотелось сделать модуль отвечающий за поведение определенного вида документа, но как получать результат функции их этого модуля или другого без шаманского передергивания с использованием Set Procedure
