Павел Дубнов - Access 2002: Самоучитель

Как и раньше, мы будем рассматривать конвертацию данных на примере одного файла. Возьмем самый представительный в базе данных БД ЧЭСфайл – File1.dat, показанный на рис. 7.2. В сущности, формальное преобразование происходит предельно просто. Выберите с помощью клавиатуры (а не мыши, так как MS DOS вполне может обходиться и без нее) выходной формат (Output Type) и имя выходного файла (Output File), который назовите Fiie1.dbf. Теперь нажмите клавишу Enter.Указывать файл-источник (Source File) не надо: имя этого системного файла Clarion введет самостоятельно. На данном этапе и произойдет преобразование: появится требуемый файл Fiie1.dbf. Если, вводя имя этого файла, вы не указали его расположение, то он будет помещен в ту же директорию, в которой находится конвертер Ccvt. Казалось бы, дело сделано, и можно переходить к следующему этапу конвертирования.

Однако не все так просто. В dBase действует ограничение на длину имени поля – оно не может превышать 10 символов. Кроме того, при конвертации в название включается префикс. Например, имя поля PEREDALпосле преобразования превратится в FIL_PEREDA.Но в результате конвертации точно так же будет выглядеть и имя другого поля – PEREDAB.Тогда окажется, что в файле File1.dbf содержатся два поля с одинаковыми именами, что недопустимо. Конечно, такая проблема разрешается относительно легко: войдите в систему dBase и там исправьте имя файла. Поскольку данная ситуация является частной, здесь она подробно не рассматривается. Но очень важно помнить, что при переносе файлов из одной СУБД в другую (даже если речь идет о реляционных СУБД) необходимы повышенные осторожность и внимание. В следующем разделе будет показано, что описанный выше эпизод – не единственный случай, когда могут возникнуть проблемы.

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

Второй этап: импорт данных из dBase в Access 2002

Теперь нам нужно импортировать в базу данных Контрольно-измерительные приборыфайлы из базы данных БД ЧЭС,конвертировав их при этом из формата dBase.

Снова откройте окно базы данных. Напомним, что необходимо выполнить следующие действия:

1. Из окна Access 2002 открыть базу данных по ее имени (БД ЧЭС).

2. Щелкните по кнопке

на панели инструментов базы данных. На экране появится окно базы данных (см. рис. 3.1).

3. Если начальная форма вам почему-либо мешает, уберите ее, щелкнув по кнопке закрытия окна.

Теперь в меню базы данных выберите опцию Файл,а в открывшемся подменю – Внешние данные.Затем активизируйте опцию Импорт,после чего на экране появится одноименное окно (рис. 7.3).

Вам придется пройти по дереву файлов в поисках базы данных в формате DBF, которую вы получили в результате первого этапа работы (см. предыдущий раздел). Как и раньше, возьмем в качестве примера файл File1.dbf. Чтобы увидеть его либо другие файлы этой базы данных в формате DBF, надо в поле Тип файлаактивизировать или какую-либо модификацию dBase (например, dBaseIII), или опцию Все файлы.В противном случае файлы формата DBF будут невидимы. Найдя нужный файл и пометив его, щелкните по кнопке

Если все прошло нормально, то Access 2002 выдаст сообщение об успешном импортировании файла (рис. 7.4). Щелкните по кнопке ОК.

Теперь надо закрыть окно Импорт,и тогда вы увидите, что в окне базы данных появилась новая таблица Fiie1(см. рис. 7.5).

Поля даты и времени

Итак, второй этап импорта прошел успешно, и кажется, что с базой данных все в порядке. Однако приглядимся повнимательнее к импортированной таблице (см. рис. 7.6), особенно к полям даты и времени FIL_DATAY, FIL_TIMECH, FIL_DATAS, FIL_TIMESO.(Вы помните, как образовались эти имена? К исходным названиям полей файла File1.dat при преобразовании его в формат DBF слева добавляются префиксы FIL, а общее имя поля «обрезается» до 10 символов.)

На рис. 7.6 эти поля сгруппированы вместе, чтобы их удобнее было просматривать. Значения перечисленных полей выглядят необычно, и вы поймете, в чем дело, перейдя в режим конструктора. Окно режима конструктора показано на рис. 7.7. Оказывается, эти поля, которые должны принадлежать к типу Дата/Время,после преобразования относятся к типам Текстили Числовой.

Внесите необходимые исправления. Задайте для полей тип Дата/Время.В разделе для полей дат FIL_DATAYи FIL_DATASустановите значение свойства Краткий формат дат,что соответствует формату даты 09/12/1999, а для полей времени FIL_TIMECHи FIL_TIMESO– значение свойства Краткий формат времени,что соответствует изображению времени 12:36. Раз уж мы взялись наводить порядок, давайте зададим для свойства Заголовокперечисленных полей соответственно значения Дата ЧЭС, Дата сообщения о ЧЭС, Время ЧЭС, Время сообщения о ЧЭС.Путешествия во времени

Посмотрим, что у нас получилось. Перейдя в режим формы (см. рис. 7.7), вы обнаружите крайне любопытную картину. Поля времени теперь имеют привычные русскоязычные имена и выглядят нормально, если не считать того, что в большинстве случаев в них представлены нулевые значения. (Заметим, что это не ваша вина; информация о времени ЧЭС и уж тем более о времени передачи сообщения поступает далеко не всегда.) Но взгляните на поля дат. На календаре базы данных должен стоять 1995 год – год, указанный в запросе. А в таблице, которая представлена на рис. 7.8, вы видите 2093 год.

Этот забавный факт имеет вполне рациональное объяснение, связанное с тем, что называется несовпадением в исходных установках различных СУБД. Если не задать заранее точное значение типа поля [8] – а для даты и времени это Дата/Время,то каждая введенная дата будет заноситься в память СУБД в виде числового выражения. Оно представляет собой количество дней, прошедших от даты, принятой за точку отсчета (ей присвоено значение 1). Это имеет определенный смысл: при необходимости вы сможете выполнять с датами арифметические действия. Если вы вводите значение времени, оно сохраняется в памяти в виде десятичной дроби, которая равна прошедшей на данный момент части дня. (За точку отсчета принимается 12 часов ночи.) А вот исходная дата в каждом семействе СУБД может быть разной. Например, в различных редакциях пакета Office, частью которого является Access, такой датой является 1 января 1900 года. В версиях языка dBase (одну из которых мы использовали) это 1 января 1800 года. Теперь вам понятны числа, которые появились в полях дат сразу после конвертации файла File1 в Access 2002 (см. рис. 7.6). А вот сутки во всех семействах СУБД начинаются в полночь, и тут при всем желании трудно придумать что-то оригинальное.