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

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

Answer 3

FreeTDS по умолчанию использует протокол версии 4.2, если вы обновите протокол до версии 7.0, вы сможете получить более 255 байт varchar.Вы можете использовать "ПРИВЕДЕНИЕ", или вы можете ИЗМЕНИТЬ СТОЛБЕЦ col varchar (максимум).

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

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

Почему бы не БРОСИТЬ?ПРИВЕДЕНИЕ В ВИДЕ ТЕКСТА несовместимо с MySQL (необходимо выполнить ПРИВЕДЕНИЕ В ВИДЕ СИМВОЛА).

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

Answer 4

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

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

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

ПРЕДОСТЕРЕЖЕНИЕ:Это может применяться только в том случае, если XML генерируется динамически.