Запрос 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 User Guide, этот вопрос, кажется, что 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 против 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 символов. Тем не менее, большая часть остальной части XML будет возвращена как кажущийся случайный мусор с редким фрагментом текста. Фактически, если бы я должен был догадаться, запрос возвращает случайный блок памяти для всех символов после 256.

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

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

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