Переход с sqloledb на драйвер odbc 13 для SQL Server

Я хочу использовать функцию Always Encrypted, представленную в SQL Server 2016 SP1. Для этого мне нужно использовать новый ODBC Driver 13.1 for SQL Server вместо текущего sqloledb.

Кажется, это ломает мое приложение, например, когда возвращается XML. Здесь сказано, что:

Чтобы воспользоваться преимуществами новых функций, представленных в SQL Server 2005, таких как несколько активных наборов результатов (MARS), уведомления о запросах, определяемые пользователем типы (UDT) или новый тип данных xml, существующие приложения, использующие объекты данных ActiveX (ADO ) должны использовать поставщика OLE DB собственного клиента SQL Server в качестве поставщика доступа к данным.

Так это значит, что мне нужно переписать код, где используется XML?

Я знаю, что Microsoft undecated устаревший драйвер sqloledb, но его первая версия, выпущенная в марте 2018 года, не будет поддерживать Always Encrypted, так что я не хочу ждать.


odbc sql-server always-encrypted asp-classic sqloledb
person gotqn    schedule 07.02.2018    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Классический ADO не имеет представления о типе XML SQL Server. Устаревший поставщик SQLOLEDB и устаревший драйвер ODBC для SQL Server возвращают тип adLongVarWChar (203) для XML, поэтому на стороне клиента это строка.

Более новый поставщик OLE DB собственного клиента SQL ServerSQL Server возвращает тип 141 для XML в ADO, но нет соответствующего ADO DataTypeEnum (https://docs.microsoft.com/en-us/sql/ado/reference/ado-api/datatypeenum). Поставщик вернет XML-данные в виде adLongVarWChar, если для совместимости с ADO указано ключевое слово строки подключения DataTypeCompatibility=80.

К сожалению, нет эквивалентного ключевого слова строки подключения DataTypeCompatibility для драйверов ODBC. Более новые драйверы ODBC возвращают XML-данные в виде типа ADO adLongVarBinary (205) при доступе через поставщика MSDASQL, который классический ADO использует для драйверов ODBC. Таким образом, XML нужно будет либо преобразовать в/из nvarchar(MAX) в SQL-запросах, либо преобразовать значение adLongVarBinary на стороне клиента.

Я не могу сказать, поможет ли еще не выпущенный драйвер Microsoft OLE DB для SQL Server, поддерживающий ключевое слово DataTypeCompatibility, но я надеюсь, что это произойдет, как и в случае с Native Client. Надеюсь, скоро мы узнаем подробности. Я сомневаюсь, что ADO будет доработана для изначальной поддержки новых типов SQL, поскольку за последние 15 лет его практически не трогали, но раньше я ошибался.

person Dan Guzman    schedule 07.02.2018
comment
Спасибо. Я могу использовать комбинацию двух соединений, чтобы устаревший код всегда работал в зашифрованном виде (одно с использованием OLEDB и одно с использованием ODBC, где требуется AE). Вы говорите, что существует вероятность того, что невыпущенный драйвер Microsoft OLE DB потребует перезаписи устаревшего кода? - person gotqn; 07.02.2018
comment
@gotqn, да, возможно, устаревший классический код ADO может потребовать изменений. Я посмотрю, смогу ли я узнать больше информации. - person Dan Guzman; 07.02.2018
comment
Да. Довольно сложно найти подробности или дорожную карту нового OLEDB водителя. На самом деле, я прочитал ваш блог (dbdelta.com/tag/odbc), чтобы узнать больше Детали. - person gotqn; 07.02.2018
comment
@gotqn, я думаю, что проблема дорожной карты больше связана с ADO, чем с OLE DB, поскольку OLE DB не рекомендуется. ADO почти устарел, поэтому вам нужно быть особенно тщательным при тестировании. Я знаю, что это не всегда возможно с устаревшими приложениями, но ваша жизнь станет проще, если вы сможете отказаться от классического ASP/ADO. - person Dan Guzman; 10.02.2018
comment
Вы уверены, что это устарело? Вы имеете в виду, что он может плохо поддерживаться новым драйвером MSSQLOLEDB? - person gotqn; 10.02.2018
comment
@gotqn, ADO официально не считается устаревшим, хотя, вероятно, ему следует уделить мало внимания. Так что имейте в виду, что ADO может не работать должным образом с новыми функциями/драйверами SQL Server, поскольку он все еще живет в мире SQL 2000. Имейте в виду, это не означает, что это не будет работать, но могут потребоваться изменения кода, и поддержка AE будет сомнительной. См. мой связанный ответ об ADO и AE. - person Dan Guzman; 10.02.2018
comment
Смешной. Это снова я. - person gotqn; 06.03.2018