Рис. 7.3
Вам придется пройти по дереву файлов в поисках базы данных в формате DBF, которую вы получили в результате первого этапа работы (см. предыдущий раздел). Как и раньше, возьмем в качестве примера файл File1.dbf. Чтобы увидеть его либо другие файлы этой базы данных в формате DBF, надо в поле Тип файла активизировать или какую-либо модификацию dBase (например, dBaseIII), или опцию Все файлы. В противном случае файлы формата DBF будут невидимы. Найдя нужный файл и пометив его, щелкните по кнопке
Если все прошло нормально, то Access 2002 выдаст сообщение об успешном импортировании файла (рис. 7.4). Щелкните по кнопке ОК.
Рис. 7.4
Теперь надо закрыть окно Импорт, и тогда вы увидите, что в окне базы данных появилась новая таблица Fiie1 (см. рис. 7.5).
Рис. 7.5
Поля даты и времени
Итак, второй этап импорта прошел успешно, и кажется, что с базой данных все в порядке. Однако приглядимся повнимательнее к импортированной таблице (см. рис. 7.6), особенно к полям даты и времени FIL_DATAY, FIL_TIMECH, FIL_DATAS, FIL_TIMESO. (Вы помните, как образовались эти имена? К исходным названиям полей файла File1.dat при преобразовании его в формат DBF слева добавляются префиксы FIL, а общее имя поля "обрезается" до 10 символов.)
Рис. 7.6
На рис. 7.6 эти поля сгруппированы вместе, чтобы их удобнее было просматривать. Значения перечисленных полей выглядят необычно, и вы поймете, в чем дело, перейдя в режим конструктора. Окно режима конструктора показано на рис. 7.7. Оказывается, эти поля, которые должны принадлежать к типу Дата/Время, после преобразования относятся к типам Текст или Числовой.
Рис. 7.7
Внесите необходимые исправления. Задайте для полей тип Дата/Время. В разделе для полей дат FIL_DATAY и FIL_DATAS установите значение свойства Краткий формат дат, что соответствует формату даты 09/12/1999, а для полей времени FIL_TIMECH и FIL_TIMESO – значение свойства Краткий формат времени, что соответствует изображению времени 12:36. Раз уж мы взялись наводить порядок, давайте зададим для свойства Заголовок перечисленных полей соответственно значения Дата ЧЭС, Дата сообщения о ЧЭС, Время ЧЭС, Время сообщения о ЧЭС. Путешествия во времени
Посмотрим, что у нас получилось. Перейдя в режим формы (см. рис. 7.7), вы обнаружите крайне любопытную картину. Поля времени теперь имеют привычные русскоязычные имена и выглядят нормально, если не считать того, что в большинстве случаев в них представлены нулевые значения. (Заметим, что это не ваша вина; информация о времени ЧЭС и уж тем более о времени передачи сообщения поступает далеко не всегда.) Но взгляните на поля дат. На календаре базы данных должен стоять 1995 год – год, указанный в запросе. А в таблице, которая представлена на рис. 7.8, вы видите 2093 год.
Рис. 7.8
Этот забавный факт имеет вполне рациональное объяснение, связанное с тем, что называется несовпадением в исходных установках различных СУБД. Если не задать заранее точное значение типа поля [8] – а для даты и времени это Дата/Время, то каждая введенная дата будет заноситься в память СУБД в виде числового выражения. Оно представляет собой количество дней, прошедших от даты, принятой за точку отсчета (ей присвоено значение 1). Это имеет определенный смысл: при необходимости вы сможете выполнять с датами арифметические действия. Если вы вводите значение времени, оно сохраняется в памяти в виде десятичной дроби, которая равна прошедшей на данный момент части дня. (За точку отсчета принимается 12 часов ночи.) А вот исходная дата в каждом семействе СУБД может быть разной. Например, в различных редакциях пакета Office, частью которого является Access, такой датой является 1 января 1900 года. В версиях языка dBase (одну из которых мы использовали) это 1 января 1800 года. Теперь вам понятны числа, которые появились в полях дат сразу после конвертации файла File1 в Access 2002 (см. рис. 7.6). А вот сутки во всех семействах СУБД начинаются в полночь, и тут при всем желании трудно придумать что-то оригинальное.
Возникает естественный вопрос: почему при конвертации данных в dBase нельзя установить для полей дат соответствующий формат, а не цифровой, который был использован в нашем примере? К сожалению, в dBase задано жесткое ограничение на длину поля Дата – 8 байт. Если вы считаете необходимым использовать четырехзначные символы для указания года (вспомните "проблему 2000 года"), то в отведенный лимит явно не укладываетесь: поля дат получатся просто пустыми, что вас, разумеется, не устроит.
Однако, объяснив этот печальный факт, вы не избавились от необходимости исправить положение. Чтобы сделать это, воспользуйтесь операцией замены-вставки. Сначала выделите столбец Дата ЧЭС, щелкнув кнопкой мыши по его имени. Теперь в меню Access 2002 откройте таблицу Fiie1 в режиме конструктора (см. рис. 7.8). Активизируйте меню Правка и выберите Найти. Можно, не входя в меню, просто применить комбинацию клавиш Ctrl+F. В результате на экране появится окно Поиск и замена (рис. 7.9).
Рис. 7.9
Теперь откройте вкладку Замена и установите следующие значения полей:
• Образец – /2093 (часть поля в столбце, которая подлежит замене);
• Заменить на – /1994 (год, устанавливаемый в порядке замены);
• Совпадение (данная опция задается стрелкой прокрутки);
• Просмотр – Все. Задается стрелкой прокрутки.
После этого следует щелкнуть по кнопке Заменить все. Затем повторить описанную процедуру для столбца Дата сообщения. В ходе операции поиска-замены по всем полям этих двух столбцов значение года – 2093 – будет заменено на 1994. Итоговый вид таблицы после внесенных исправлений представлен на рис. 7.10.
Рис. 7.10
Но и это еще не все. Если сравнить сообщение о ЧЭС, полученное из исходной базы данных в среде Clarion, и его изображение после конвертации в Access 2002, то можно обнаружить одно различие, свойственное всем записям. Состоит оно в том, что в новой базе данных даты всех событий сдвинуты на один день вперед по сравнению с исходной базой данных. Если, согласно информации в исходной базе данных, авария на магистральном трубопроводе произошла 23.03.95, то в новой БД этому событию соответствует другая дата – 24.03.95. В чем тут дело? Детальная проверка объясняет причину такого сдвига во времени: в разных СУБД заложены разные установки насчет того, как представлять дату 29.02 в високосном году. Это и проявляется при преобразовании базы данных. Там за несколько лет накапливаются большие массивы информации, и в каждом високосном году 29 февраля происходит своеобразная "мутация": в преобразованных записях все даты отличаются от исходных на +1 день. Через 4 года сдвиг увеличивается еще на 1 день, и т. д. Как видите, здесь необходима корректировка, и осуществить ее технически несложно; потребуются лишь внимательность и методичность. Просто сравните выбранные вами контрольные записи в исходной БД с их отображением в новой, итоговой базе данных и определите границы подмассива с конкретным значением сдвига (например, + 1). Теперь исправьте данные этого подмассива с помощью операции поиска-замены так, как было показано выше. Сортировка записей
И наконец, последняя операция: таблицу базы данных желательно, хотя и не обязательно, отсортировать. Операция сортировки записей в Access 2002 очень проста. В окне конструктора (см. рис. 7.10) выделите тот столбец, по которому требуется сортировать записи. Сама сортировка производится с помощью одной из двух кнопок:
или