consulta ODBC em MS SQL Server retornando primeiros 255 caracteres apenas em PHP DOP (FreeTDS)

Question

Atualmente estou tentando puxar alguns dados de uma visão de banco de dados SQL Server que têm restringido o acesso a partir de nosso servidor web Linux.

Nós não precisa editar os dados apenas exibi-lo em uma página web.

Tudo parece bem até que nós tentamos de saída e só obter os primeiros 255 caracteres de um campo de texto.

Alguém sabe se este é um problema com o uso de FreeTDS através do PHP :: DOP ou se ele deve funcionar bem? Eu vi outras pessoas lá fora, com problemas semelhantes, mas não parece ser muitas respostas.

Eu estou usando isso como a seqüência de conexão para o db MS SQL:

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

Answer 1

De acordo com a FreeTDS Guia do Usuário , a questão parece ser que FreeTDS pode apenas lidar com varchar até 255 caracteres quando se fala de SQL Server "devido a limitações inerentes à definição de protocolo" . Qualquer coisa maior do que precisa ser tipo de dados text.

Você pode resolver o problema, quer modificando o esquema em conformidade, ou converter o tipo de dados durante a sua consulta, assim:

SELECT CAST(mycol as TEXT) FROM mytable

Answer 2

Você pode aumentar o tamanho de campos de texto no arquivo /etc/odbc.ini usado por FreeTDS.

[name_of_connection]
TextSize = 2097152

Você também pode tentar usar o baixo nível de PHP ODBC rotinas para se certificar de que você pode obter esse nível de recuperação de dados, em seguida, trabalhar para trás até usando PDO.

Answer 3

FreeTDS, por padrão, usa o protocolo versão 4.2 Se você se o protocolo para 7,0 você pode recuperar mais de 255 bytes de um varchar. Você pode usar o "CAST" corte, ou você pode alterar a coluna col varchar (max).

VARCHAR (max) é um tipo de coluna completamente diferente do que VARCHAR (DATA_TYPE 2,005 vs 12) e vai ser transmitido ao longo freetds 4,2 w / o truncamento.

Por que não atualizar para a versão 7? Porque UTF-8 não podem ser armazenados em varchar com os protocolos mais recentes. SQL Server irá transmitir toda a informação de protocolo no UCS-2 (como UTF-16) e converter seus dados na tabela ou coluna agrupamento antes de salvar. Mas, isso requer que você dados prefixo UTF8 com N. inserir valores tbl (txt) (N'hello mundo ')

Por que não elenco? Elenco como TEXT não é compatível com o MySQL (necessidade de fazer escalado como CHAR).

Ficar no protocolo 4.2 e definir seus varchars como varchar (max) do que você escreve o SQL mais compatível deixar.

Answer 4

Mais um factóide para este problema. A partir de 2015, retornando um valor de resultados tipo XML no primeiro 25 6 caracteres que estão sendo devolvidos de forma limpa. No entanto, a maior parte do resto do XML será devolvido como lixo aparentemente aleatória, com um fragmento clara ocasional de texto. Na verdade, se eu tivesse que adivinhar, a consulta retorna um bloco aleatório de memória para todos os caracteres após 256.

No meu caso específico, eu estava gerando XML (usando múltiplas consultas FOR XML aninhadas) para enviar para um site para exibição. Neste caso, a solução que encontrei foi usar o hack CAST, lançando os dados para varchar (max).

Então lembre-se:. Se você ver um bloco de 256 caracteres claros seguido de lixo aleatório nos resultados da consulta, é provavelmente um valor XML que estão sendo devolvidos como um tipo XML em vez de um tipo varchar (max)

ressalva:. Isso só podem ser aplicadas se o XML é gerado dinamicamente