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

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

нам не нужно редактировать данные только для отображения на веб-странице.

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

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

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

$dbConn = new PDO("odbc:Driver=FreeTDS;DSN=OURDSN;UID=WWWUser;PWD=ourpassword");
6
freetds odbc pdo php sql-server

4 ответов

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

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

SELECT CAST(mycol as TEXT) FROM mytable
6

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

[name_of_connection]
TextSize = 2097152

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

2

FreeTDS, по умолчанию, использует версию протокола 4.2, если вы поднимаете протокол до 7.0, вы можете получить более 255 байтов varchar. Вы можете использовать "CAST" hack, или вы можете изменить столбец 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. вставить в значения tbl (txt) (n'Hello world')

Почему бы не бросить? CAST как текст не совместим с MySQL (нужно сделать CAST как CHAR).

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

1

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

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

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

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

0