Zapytanie ODBC na MS SQL Server zwracające pierwsze 255 znaków tylko w PHP PDO (FreeTDS)

Question

Aktualnie próbuję pobrać pewne dane z widoku bazy danych SQL Server, do którego mamy ograniczony dostęp z naszego serwera linuksowego.

Nie musimy edytować danych, tylko wyświetlaj je na stronie internetowej.

Wszystko wygląda dobrze, dopóki nie spróbujemy wydrukować tylko pierwszych 255 znaków pola tekstowego.

Czy ktoś wie, czy jest to problem z korzystaniem z FreeTDS poprzez PHP :: PDO, czy też powinien działać poprawnie? Widziałem innych ludzi mających podobne problemy, ale wydaje się, że nie ma wielu odpowiedzi.

Używam tego jako ciąg połączenia do db MS SQL:

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

Answer 1

Według FreeTDS User Guide, problem wydaje się, że FreeTDS może obsłużyć tylko varchar aż 255 znaków podczas rozmowy z SQL Server „z powodu ograniczeń tkwiących w definicji protokołu”. Wszystko, co jest większe, musi być typu danych: text.

Można rozwiązać ten problem poprzez modyfikację schematu odpowiednio, lub konwersji typu danych podczas zapytania, tak:

SELECT CAST(mycol as TEXT) FROM mytable 

Answer 2

Możesz zwiększyć wielkość pól tekstowych w pliku /etc/odbc.ini używanego przez FreeTDS.

[name_of_connection] 
TextSize = 2097152 

Można również spróbować użyć PHP rutyny niski poziom ODBC, aby upewnić się, że można uzyskać ten poziom pobierania danych, a następnie z powrotem do pracy przy użyciu PDO.

Answer 3

FreeTDS domyślnie używa protokołu w wersji 4.2 Jeśli się protokół do 7.0 możesz pobrać więcej niż 255 bajtów varcharu. Możesz użyć hackowania "CAST" lub możesz ZMIENIĆ colUMN col varchar (max).

varchar (max) to zupełnie inny typ kolumn niż varchar (DATA_TYPE 2005 vs 12) i będzie przesyłany strumieniowo przez freetony 4.2 bez skracania.

Dlaczego nie dokonać aktualizacji do wersji 7? Ponieważ UTF-8 nie może być przechowywany w varchar z nowszymi protokołami. SQL Server przekaże WSZYSTKIE informacje o protokole w UCS-2 (np. UTF-16) i przekształci dane w tabelę lub kolumnę przed zapisaniem. Wymaga to jednak przedrostowania danych UTF8 za pomocą N. INSERT do wartości tbl (txt) (N'hello world ')

Dlaczego nie CAST? CAST AS TEXT nie jest kompatybilny z MySQL (trzeba zrobić CAST AS CHAR).

Pozostając na protokole 4.2 i definiując twoje varchary jako varchar (max), napiszemy najbardziej zgodny SQL.

Answer 4

Kolejny faktor dla tego problemu. Od 2015 r. Zwracanie wartości typu XML powoduje, że zwracane znaki są zwracane w czystej postaci w postaci pierwszych 25. Jednak większość reszty XML zostanie zwrócona jako pozornie losowe śmieci, z okazjonalnym czystym fragmentem tekstu. W rzeczywistości, gdybym musiał zgadywać, zapytanie zwróci losowy blok pamięci dla wszystkich znaków po 256.

W moim konkretnym przypadku generowałem XML (używając wielu zapytań zagnieżdżonych XML), aby wysłać je do strony internetowej dla pokaz.W tym przypadku rozwiązaniem, które znalazłem, było użycie hackowania CAST, przesyłanie danych do varchar (max).

Należy więc pamiętać: Jeśli w wynikach zapytania zobaczysz blok 256 znaków, a następnie losowe śmieci, prawdopodobnie jest to wartość XML zwracana jako typ XML zamiast typu varchar (max).

PRZESTROGA: Może to mieć zastosowanie tylko wtedy, gdy kod XML jest generowany dynamicznie.