consulta ODBC en MS SQL Server devolver primeros 255 caracteres sólo en PHP DOP (FreeTDS)

Question

Actualmente estoy tratando de sacar algunos datos de una vista de base de datos SQL Server que hemos restringido el acceso a nuestro servidor web Linux.

No es necesario para editar los datos que acaba de mostrar en una página web.

Todo se ve bien hasta que tratamos de salida y sólo obtenemos los primeros 255 caracteres de un campo de texto.

¿Alguien sabe si esto es un problema con el uso FreeTDS través de PHP :: DOP o si debería funcionar bien? He visto a otras personas por ahí que tienen problemas similares, pero no parecen haber muchas respuestas.

Estoy usando esto como la cadena de conexión para el DB MS SQL:

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

Answer 1

De acuerdo con la FreeTDS Guía del usuario , el problema parece ser que puede FreeTDS Sólo manejar varchar hasta 255 caracteres cuando se habla a SQL Server "debido a las limitaciones inherentes a la definición del protocolo" . Cualquier cosa más grande que eso tiene que ser el tipo de datos text.

Puede resolver el problema, ya sea mediante la modificación de su esquema en consecuencia, o la conversión del tipo de datos durante la consulta, así:

SELECT CAST(mycol as TEXT) FROM mytable

Answer 2

Puede aumentar el tamaño de los campos de texto en el archivo /etc/odbc.ini utilizado por FreeTDS.

[name_of_connection]
TextSize = 2097152

También puede tratar de usar las rutinas de bajo nivel ODBC PHP para asegurarse de que usted puede conseguir que el nivel de recuperación de datos, y luego trabajar de nuevo hasta el uso de DOP.

Answer 3

FreeTDS, por defecto, utiliza el protocolo de la versión 4.2 Si el protocolo a 7,0 puede recuperar más de 255 bytes de un varchar. Se puede utilizar el truco "Fundido", o se puede alterar varchar COLUMNA col (max).

varchar (max) es un tipo de columna completamente diferente que varchar (DATA_TYPE 2005 vs 12) y será transmitido sobre freetds 4.2 w / o truncar.

Por qué no actualizar a la versión 7? Debido a UTF-8 no se puede almacenar en varchar con los protocolos más nuevos. SQL Server se transmitirán toda la información de protocolo en UCS-2 (como UTF-16) y convertir sus datos en la tabla o columna de colación antes de guardar. Sin embargo, esto requiere que el prefijo de datos UTF8 con N. INSERT en TBL valores (TXT) (N'hello mundo ')

¿Por qué no echa? Reparto como texto no es compatible con MySQL (necesidad de hacer reparto como CHAR).

El permanecer en el protocolo 4.2 y la definición de sus varchars como varchar (max) vamos a escribir el SQL más compatible.

Answer 4

Una factoide más para este problema. A partir de 2015, que devuelve un valor de tipo de resultados XML en los primeros 25 6 caracteres que se devuelven limpiamente. Sin embargo, la mayor parte del resto del XML que se obtiene es la basura, aparentemente al azar, con un fragmento de texto claro de vez en cuando. De hecho, si tuviera que adivinar, la consulta devuelve un bloque al azar de la memoria para todos los caracteres después de 256.

En mi caso particular, yo estaba generando XML (utilizando múltiples consultas FOR XML anidadas) para enviar a un sitio web para su visualización. En este caso, la solución que encontré fue utilizar el hack CAST, fundición los datos a varchar (max).

Así que recuerde: Si ve un bloque de 256 caracteres claros seguidos de basura aleatoria en los resultados de la consulta, es probable que sea un valor XML se devuelve como un tipo XML en lugar de un varchar (max) de tipo

.

advertencia: Esto sólo puede aplicarse si se genera dinámicamente el código XML

.