Access->SQL

Мне досталось преобразовывать огромную и плохо структурированную прогу. На этом деле я набил немало шишек. Хотя преобразование из провайдера JET 3.51 в JET 4.0 (соответственно с Access 97 на Access 2000) вроде-бы происходит нормально, но реально приложения ПАДАЮТ даже при таком незначительном изменении. Что касается преобразования к провайдеру SQL - то тут надо менять не только формат ConnectionString - тут дело значительно серьезнее.

Во-первых, надо собственно перегнать данные. Почему-то Access собственно конвертирование данных не выполняет. Зато сам SQL-сервер прекрасно импортирует данные, только надо правильно выбрать провайдера и дальше все пойдет прекрасно. И наконец можно перегнать каждую таблицу Access в таблицу SQL-сервера через отдельное ODBC-имя. В примере использовано ODBC-имя "qqq", которое надо предварительно создать а ODBC-администраторе кнопкой NEW - а когда ODBC-коннект назначения создан - остается только нажать Ok.

Еще одно искушение при работе с JET - попытаться получить такую же трассировку как и в SQL Profiler. Кажется что это можно сделать ODBC-Администратором - однако в итоге выходит сущая ерунда. К слову сказать, я вообще не знаю как настраивать JET-провайдер за исключением внесения изменений непосредственно в реестр, как описано в www.microsoft.com. В отличии от JET - SQL провайдер имеет грандиозное количество настроек SET Options, Server Options , Database Options, DBCC Options, а также множество функций для чтения и установки этих опций. Даже список свойств соединения с SQL-провайдером внушает трепет - Connection, Recordset, Table, Column Properties. Посмотреть их можно как раз в первой форме той тестовой задачки, которую я писал во время тестирования для устройства на эту работу - Тетрис-дождик из динамически создаваемых фигур, хранимых в SQL-базе.

Собственно дальше моя работа по преобразованию программы заключалась в переписывании несовместимости SQL-диалектов JET-провайдера и SQL-провайдера:

• Кавычки. Обычно SQL принимает в качестве разделителя строки только одинарную кавычку.Однако при устновке SET QUOTED_IDENTIFIER OFF умеет принимать оба типа кавычек - одиночные и двойные. Причем при попадании кавычек внутрь строки одиночные удваиваются, а двойные - нет. Но в одном и том же запросе - разные кавычки мешать нельзя.
• Несовместимый формат даты. JET принимает даты только вида #01/01/2000# - других вариантов нет. SQL принимает даты в одинарных кавычках, в двойных (но только не в #), разделенные чем угодно - точкой, слешем, минусом. При этом порядок YY-MM-DD тоже может быть любой и задается командой SET DATEFORMAT mdy. Даже типов данных DataTime - два. Обычный (восьмибайтовый) от 01/01/1753 до 31/12/9999 и укороченный (четырехбайтовый) от 01/01/1900 до 06/06/2079.
• SQL не позволяет выполнить UPDATE без указания FROM, а в Access можно было даже обновить сразу несколько таблиц, соединенных JOIN
• SQL не открывает для записи АДО-рекордсет с ORDER BY
• SQL совершенно по другому работает с Boolean величинами:
  • не сортирует по логическому выражению,
  • не принимает выражения =NULL, а требует IS NULL,
  • принимает в логические поля только 0 или 1, а не True, False, Yes, No. А между тем True в Access вообще равно -1.

Еще та прога хранила целые числа в базе - как тексты. Соответственно назад в числа они преобразовывались инструкцией VB6 - VAL (которая игнорирует пробелы) и подобные строки "241 386 - 00" может сразу преобразовать в число 241386 в констукциях типа "where val([d1])= 241386". Ну а чтобы прочитать эти строки как числа (не меняя прогу) мне приходилось набивать руку на подобных конструкциях. При этом эта еще самая короткая - при наличии точки - тип данных в SQL всегда получается Float, поэтому была нужна еще гора конструкций IF, проверяющих диапазон и отбрасывающий из считываемой строки "-00".

<SITEMAP>  <MVC>  <ASP>  <NET>  <DATA>  <KIOSK>  <FLEX>  <SQL>  <NOTES>  <LINUX>  <MONO>  <FREEWARE>  <DOCS>  <ENG>  <CHAT ME>  <ABOUT ME>  < THANKS ME>