Запрос ODBC на MS SQL Server, возвращающий первые 255 символов только в PHP PDO (FreeTDS)

Question

В настоящее время я пытаюсь получить некоторые данные из представления базы данных SQL Server, доступ к которым у нас ограничен, с нашего веб-сервера Linux.

Нам не нужно редактировать данные, просто отобразите их на веб-странице.

Все выглядит нормально, пока мы не попытаемся вывести и получить только первые 255 символов текстового поля.

Кто-нибудь знает, если это проблема с использованием FreeTDS через PHP :: PDO или он должен работать нормально? Я видел других людей, имеющих подобные проблемы, но, похоже, не так много ответов.

Я использую это как строку подключения для базы данных MS SQL:

$dbConn = new PDO("odbc:Driver=FreeTDS;DSN=OURDSN;UID=WWWUser;PWD=ourpassword");

Answer 1

Согласно Руководству пользователя FreeTDS , проблема заключается в том, что FreeTDS может обрабатывать varchar до 255 символов при обращении к SQL Server "из-за ограничений, присущих определению протокола«.Все, что больше этого, должно иметь тип данных text.

Вы можете решить проблему, либо соответствующим образом изменив свою схему, либо преобразовав тип данных во время запроса, например:

SELECT CAST(mycol as TEXT) FROM mytable

Answer 2

Вы можете увеличить размер текстовых полей в файле /etc/odbc.ini, используемом FreeTDS.

[name_of_connection]
TextSize = 2097152

Вы также можете попробовать использовать низкоуровневые процедуры PHP odbc, чтобы убедиться, что вы можете получить этот уровень извлечения данных, а затем вернуться к использованию PDO.

Answer 3

FreeTDS по умолчанию использует протокол версии 4.2. Если вы используете протокол до 7.0, вы можете получить более 255 байт varchar. Вы можете использовать хак "CAST" или ALTER COLUMN col varchar (max).

varchar (max) - это совершенно другой тип столбца, чем varchar (DATA_TYPE 2005 vs 12), и будет транслироваться через freetds 4.2 без усечения.

Почему бы не обновить до версии 7? Потому что UTF-8 нельзя хранить в varchar с более новыми протоколами. SQL Server будет передавать ВСЕ данные протокола в UCS-2 (например, UTF-16) и преобразовывать ваши данные в таблицу или сопоставление столбцов перед сохранением. Но это требует от вас префикса данных UTF8 с помощью N. INSERT в значения tbl (txt) (N'hello world ')

Почему не CAST? CAST AS TEXT не совместим с MySQL (необходимо выполнить CAST AS CHAR).

Оставаясь на протоколе 4.2 и определяя ваши varchars как varchar (max), давайте напишем наиболее совместимый SQL.

Answer 4

Еще один фактоид для этой проблемы. По состоянию на 2015 г. возвращение значения типа XML приводит к тому, что первые 25 6 символов возвращаются корректно. Тем не менее, большая часть остального XML будет возвращена как случайный мусор со случайным чистым фрагментом текста. На самом деле, если бы мне пришлось угадывать, запрос возвращает случайный блок памяти для всех символов после 256.

В моем конкретном случае я генерировал XML (используя несколько вложенных запросов FOR XML) для отправки на веб-сайт для отображения. В этом случае решение, которое я нашел, состояло в том, чтобы использовать взлом CAST, приведя данные к varchar (max).

Итак, помните: если в результатах запроса вы видите блок из 256 чистых символов, за которыми следует случайный мусор, это, вероятно, значение XML, возвращаемое как тип XML вместо типа varchar (max).

CAVEAT: это может применяться, только если XML генерируется динамически.