Здравствуйте, уважаемые коллеги. Хочу поделиться недавним опытом перевода базы данных из формата Access 2000 на платформу MS SQL Server 7.0. Конечно, моя статья не отличается профессионализмом и полнотой изложения. Мой практический опыт работы с SQL-Server до этого момента был равен почти абсолютному нулю. Но как можно заметить, летом статей настолько мало, что искренне хочется поддержать наше Королевство. Итак, приступим.
Несмотря на использование ODBC DSN и родных майкрософтовских драйверов обнаружилась некоторая несовместимость.
Используемые драйвера:

• MS Access - "Microsoft Access Driver" из состава MS Office 2000
• SQL-Server - "SQL Server" из состава MS SQL-Server 7.0

Операционная система сервера приложений - Windows 2000.

Весь перевод производился с помощью мастера "DTS Import Wizard", входящего в состав SQL-Server.

Перевод данных с датами

При переводе одной из таблиц обнаружились две ошибки:

• Несмотря на запрет пустых значений для одного из полей в формате "дата-время", в таблице Access имелось 3 записи с пустыми значениями в этих полях. Всего записей в таблице более 17 тысяч. Как эти три там оказались - никто не знает.
• После исправления этой ситуации процесс перевода был прерван ошибкой:

Как оказалось, в таблице имелась куча записей с годами вроде 2089, 2095, 2099. Причина этого понятна - использование маски при некорректной настройке формата даты в системе. Непонятно, почему эти данные не принял SQL-Server. Тем не менее, спасибо ему за это. Корректировке были подвергнуты более 3000 записей (программа не сопровождалась три года). Чтобы подобное не повторилось в дальнейшем, я поставил проверку на значение даты перед операцией "Post". В дальнейшем перевод 24 таблиц прошел быстро и без затруднений. Объем базы данных в формате Access на момент перевода составлял 7.8 Мб после операции "сжатия-восстановления".

Особенность типов данных

По умолчанию в процессе перевода данных таблицы создавались с полями формата nvarchar и ntext. Как оказалось, при использовании майкрософтовского ODBC-драйвера "SQL Server" эти форматы не воспринимаются через BDE. Пришлось менять форматы на varchar и text. Varchar соответствует "текстовому" формату Access, а text - "полю Memo". Также было замечено, что логические поля, приобретшие теперь тип "bit", не допускают использование пустых значений. Поэтому им необходимо указать значения по умолчанию (0 или -1). После перевода все таблицы свободно открывались и редактировались через BDE. Как оказалось, индексы и реляционные связи не были конвертированы. Не желая испытывать судьбу, я тут же присвоил всем таблицам первичные индексы.

Некоторые особенности построения SQL-запросов

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

• Использование условий вроде "= true" для логических полей порождало ошибку. Замена "true" на -1, а "false" на 0 решило проблему.
• Использование в запросах условия "<> Null" оказалось недопустимым. Требуется писать "Is Not Null".
• Условия на даты пришлось переписать в формате yyyymmdd в кавычках и без разделителей. При работе с Access использовалась маска #mm/dd/yyyy# с разделителем "/". Благодаря централизованному использованию функции преобразования даты в программе пришлось изменить только ее. Отсюда совет: используйте функции преобразования централизованно.
• Последнее, с чем я столкнулся - это особенность работы функции Str() в запросе, которою я использовал для получения строкового значения логического поля. Access давал результат " -1" и " 0" для true и false соответственно. SQL-Server предложил " -1" и " 0" - уже с 10 пробелами перед значением. Это просто решается с помощью функции LTrim().

Вот и все! Затраченное на перевод время - 2,5 часа с тремя перекурами и одним перерывом на кофе. Несмотря на отсутствие вторичных индексов, выполнение запросов замедлилось не более, чем в два раза, а повторное открытие запроса - около полутора. Просто так лепить индексы мне не хочется, поэтому пока оставлю так, а как появится время, воспользуюсь утилитой "Query analyzer", который входит в состав SQL-Server. Как написано в умной книжке, она позволяет отслеживать этапы выполнения запроса по времени, из чего можно сделать вывод о необходимости тех или иных вторичных индексов. Самое приятное, что сразу бросилось в глаза:

• Быстрый backup и возможность архивации по расписанию. Установи два-три расписания с разными периодами и голова не болит. Недостаток: архивация возможна только на локальные носители. Подключенные сетевые диски и сетевые адреса не воспринимаются.
• Исчезли проблемы с медленным сохранением Memo-полей, из-за чего запись блокировалась на значительное время.

В завершение несколько советов по использованию Access (опыт - четыре года):

• Одни из лучших компонентов для доступа - фирмы Regatta Systems.
• Тем не менее лучшим считаю вариант ODBC с драйвером MS Access 2000. Однако из-за проблем с Memo-полями, в частности, в больших таблицах, приходилось использовать отдельные запросы на их изменение.
• При настройке DSN установите параметр "Safe transaction" равным 1. По умолчанию 0. Из справки: "Если имеет значение 0 (по умолчанию), все транзакции передаются немедленно. Если имеет значение 1, все транзакции сохраняются на диске только после операции передачи. При этом немного снижается быстродействие."
• Наибольшая скорость работы с базой данных (практически мгновенно) была получена на операционной системе Windows 2000.

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

• Обратиться в "Интерфейс" за дополнительной информацией/по вопросу приобретения продуктов
• Подписаться на рассылку "Работа с MS Access"