Этот забавный факт имеет вполне рациональное объяснение, связанное с тем, что называется несовпадением в исходных установках различных СУБД. Если не задать заранее точное значение типа поля [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).

Теперь откройте вкладку Замена и установите следующие значения полей:

• Образец – /2093 (часть поля в столбце, которая подлежит замене);

• Заменить на – /1994 (год, устанавливаемый в порядке замены);

• Совпадение (данная опция задается стрелкой прокрутки);

• Просмотр – Все. Задается стрелкой прокрутки.

После этого следует щелкнуть по кнопке Заменить все. Затем повторить описанную процедуру для столбца Дата сообщения. В ходе операции поиска-замены по всем полям этих двух столбцов значение года – 2093 – будет заменено на 1994. Итоговый вид таблицы после внесенных исправлений представлен на рис. 7.10.

Но и это еще не все. Если сравнить сообщение о ЧЭС, полученное из исходной базы данных в среде Clarion, и его изображение после конвертации в Access 2002, то можно обнаружить одно различие, свойственное всем записям. Состоит оно в том, что в новой базе данных даты всех событий сдвинуты на один день вперед по сравнению с исходной базой данных. Если, согласно информации в исходной базе данных, авария на магистральном трубопроводе произошла 23.03.95, то в новой БД этому событию соответствует другая дата – 24.03.95. В чем тут дело? Детальная проверка объясняет причину такого сдвига во времени: в разных СУБД заложены разные установки насчет того, как представлять дату 29.02 в високосном году. Это и проявляется при преобразовании базы данных. Там за несколько лет накапливаются большие массивы информации, и в каждом високосном году 29 февраля происходит своеобразная «мутация»: в преобразованных записях все даты отличаются от исходных на +1 день. Через 4 года сдвиг увеличивается еще на 1 день, и т. д. Как видите, здесь необходима корректировка, и осуществить ее технически несложно; потребуются лишь внимательность и методичность. Просто сравните выбранные вами контрольные записи в исходной БД с их отображением в новой, итоговой базе данных и определите границы подмассива с конкретным значением сдвига (например, + 1). Теперь исправьте данные этого подмассива с помощью операции поиска-замены так, как было показано выше. Сортировка записей

И наконец, последняя операция: таблицу базы данных желательно, хотя и не обязательно, отсортировать. Операция сортировки записей в Access 2002 очень проста. В окне конструктора (см. рис. 7.10) выделите тот столбец, по которому требуется сортировать записи. Сама сортировка производится с помощью одной из двух кнопок:

или

Посредством первой из них вы располагаете записи по возрастанию: для цифровых символов – от 0 до 9, для текстовых – от A до Z. Вторая кнопка, соответственно, используется для сортировки записей по убыванию. Щелкните по одной из кнопок.

Теперь оглянемся назад и посмотрим, что уже сделано и что еще предстоит выполнить.

Вы преобразовали и импортировали в Access 2002 один файл (Fiie1) базы данных БД ЧЭС из СУБД, созданной в среде Clarion. Но, во-первых, вы импортировали только часть информации (данные лишь за один год), а в БД ЧЭС накоплены записи с 1990 года. Во-вторых, в БД ЧЭС есть еще несколько словарных файлов, которые тоже нужно перенести в новую базу.

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

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

В завершение работы надо привести базу данных в привычный вид. Ограничения на длину имени поля практически отсутствуют, поэтому дайте всем полям в файлах русскоязычные названия. Вы уже начали делать это немного раньше – в разделе «Поля даты и времени» – с помощью поля Имя поля конструктора таблиц. В своем заключительном варианте таблица Fiie1 представлена на рис. 7.11, а окно базы данных – на рис. 7.12.

Технология импорта базы данных Контроль ЧС в основном та же, что и в предыдущем случае. Как вы помните, исходная база данных существует в среде FoxPro. Поскольку в программном обеспечении Access 2002 отсутствует конвертер формата FoxPro, на первом этапе надо импортировать файлы данных в Access 97 (где нужный конвертер есть), а уже затем, на втором этапе работы – из среды Access 97 в Access 2002. Снова подробно рассмотрим эти преобразования на наиболее показательном примере – на файле ES_oper.dbf, одном из тех, где сосредоточена вся основная фактическая информация.

Первый этап: импорт данных из FoxPro в Access 97

Как выглядит исходная запись базы данных Контроль ЧС в формате DBF среды FoxPro, показано на рис. 7.13.

Рис. 7.13

Последовательность действий при конвертации указанного файла практически полностью совпадает с первым этапом импорта базы данных БД ЧЭС. Еще раз перечислим необходимые шаги, но очень кратко:

1. Откройте окно базы данных в Access 97. В принципе можно было использовать любую БД в Access 97, так как импортируемый файл в ней долго не задержится. Но ради чистоты эксперимента все же откройте новую базу данных в Access 97 и назовите ее db1.mdb, как и будущую БД в Access 2002. Однако поместите открытую вами базу данных в другую (по сравнению с db1.mdb в Access 2002) папку, чтобы программа Windows не возражала, так как одновременное присутствие на одном жестком диске Access 97 и Access 2002 может вызывать конфликты. Окно этой пустой базы данных показано на рис. 7.14.

2. Войдите в меню базы данных и задайте ряд команд: Файл Внешние данные Импорт.

3. Найдите файл ES_oper.dbf в исходной БД (см. рис. 7.15). Не забудьте указать в этом окне тип выбранного файла.

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

5. В ответ на сообщение Выполнен импорт ES_oper щелкните по кнопке OK.

6. В окне базы данных появится новая таблица ES_oper.

Если вы теперь откроете таблицу ES_oper (см. рис. 7.16), то увидите, что даты в исходной и в импортированной базах данных совпадают и отображаются в правильном формате, а поля времени вообще отсутствуют. Можно вздохнуть свободно: проблем, которые пришлось решать при импорте предыдущей БД, в этом случае не будет. Переходите ко второму этапу конвертации.

Рис. 7.16

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

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

1. Откройте окно базы данных в Access 2002 (см. рис. 7.12).

2. Войдите в меню базы данных, а выполните ряд команд:

Файл → Внешние данные → Импорт.

3. Найдите файл.dbf в исходной базе данных (см. рис. 7.15). Чтобы файлы с таким расширением были видимыми, предварительно укажите в этом окне соответствующий тип файла (или Все файлы).

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

5. На появившееся сообщение Файл ES_oper успешно импортирован следует ответить OK.

6. В окне базы данных появится новая таблица ES_oper.

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

Опустим промежуточные детали, подробно рассмотренные на примере файла ES_oper. На рис. 7.17 представлено окно новой базы данных в Access 2002, в которой собраны наконец все файлы – как свои, «родные», так и импортированные.

В заключение надо русифицировать имена полей в файлах, подобно тому как это было показано на рис. 7.11 для файла File1 из базы данных БД ЧЭС. Посвящать изменениям каждого файла по отдельному рисунку нет смысла – файлов слишком много. Кроме того, эти изменения будут рассмотрены в последующих главах, когда речь пойдет о программировании в базе данных.

1. По мере появления новых, более совершенных СУБД все актуальнее становится проблема использования данных, которые накоплены в информационных банках предыдущих, в том числе и морально устаревших версий.

2. В решении этой проблемы на сегодняшний день наметились два основных направления:

– применение конвертеров, которые преобразуют данные из одного формата в другой. Наборы таких конвертеров, хотя и не всегда достаточно полные, есть практически во всех СУБД, и пока это основной путь решения проблемы;

– использование технологии ODBC (Open Database Connectivity). Это открытый интерфейс доступа к базам данных из прикладных программ. Он позволяет работать с документами «чужих» для конкретной БД форматов.