MS-SQL Länge für Spalten vom Typ "Text"

[Marcusson]

Bei Verwendung der "Microsoft SQL Server Functions" (mssql-library) von PHP 4 / 5 ist mir aufgefallen, dass beim Durchführen einer SQL-Abfrage Felder vom Typ "Text" bei einer Länge von exakt 4096 Zeichen abgeschnitten werden. Ist der Inhalt des Feldes größer, dann geht der Rest verloren.

Schuld daran ist anscheinend die C-API, welche PHP intern verwendet um mit dem SQL Server zu kommunizieren. Diese API hat außerdem dass Problem, dass keine Unicode-kodierten Zeichenfolgen übetragen kann. Beim Versuch ein Feld vom Typ "nText" zu lesen bricht das DBMS mit einer entsprechenden Fehlermeldung ab und meldet, dass die verwendete C-Bibliothek veraltet sei.

Von dem Problem betroffen ist auch das DB-Paket des PEAR-Framework, welches diese Bibliothek verwendet und daher ebenfalls fehlerhafte Ergebnisse liefert.

Gibt es irgendeine andere PHP-Bibliothek für MS-SQL, welche dieses Problem nicht hat?

Ich würde nur ungern auf eine andere Skript- oder Programmiersprache ausweichen müssen, nur weil man mit PHP keine Text-Felder aus einer MS-SQL Datenbank auslesen kann.

[asp2php]

unter welchem OS läuft PHP?

[Marcusson]

Win32 (genauer gesagt Windows XP Prof)

[asp2php]

das hier schon durch geführt?


Requirements for Win32 platforms.

The extension requires the MS SQL Client Tools to be installed on the system where PHP is installed. The Client Tools can be installed from the MS SQL Server CD or by copying ntwdblib.dll from \winnt\system32 on the server to \winnt\system32 on the PHP box. Copying ntwdblib.dll will only provide access. Configuration of the client will require installation of all the tools.

[Marcusson]

Ja, wurde durchgeführt. Wenn man das nicht machen würde, könnte man überhaupt nicht auf MS-SQL zugreifen ;-)

[gleiwitz19]

vielleicht gibt es von ms eine eigene, aktuelle php_mssql.dll? (bei mysql_ ist es analog so der fall: eine .dll ist in der php-distribution und eine 'empfohlenere' auf der mysql webseite).

Googeln nach "php_mssql.dll ntwdblib.dll 4096" liefert in kurzer Zeit in den User Contributed Notes des php-online-Manuals etwas: In der php.ini gibt es den Eintrag: "mssql.textlimit = 4096"

Suchen mit notepad in der php.ini liefert sogar bei mir, der mssql überhaupt nicht nutzt, dasselbe.

[gleiwitz19]

edited above.

[Marcusson]

Danke, die php.ini war genau das richtige Stichwort

; Handling of LONG fields.  Returns number of bytes to variables.  0 means passthru.

; Valid range 0 - 2147483647.  Default = 4096.
mssql.textlimit = 0

; Valid range 0 - 2147483647.  Default = 4096.
mssql.textsize = 0

Ich werde es mit diesen Einstellungen mal probieren.

[Marcusson]

[EDIT] Die Einstellung "0" im Sinne von "passthru" funktioniert ärgerlicherweise nicht und führt dazu, dass wiederum der Default-Wert 4096 verwendet wird.

Wie auch immer: die Einstellung auf die Maximalwerte funktioniert.

; Valid range 0 - 2147483647. Default = 4096.
mssql.textlimit = 2147483647

; Valid range 0 - 2147483647. Default = 4096.
mssql.textsize = 2147483647

Anscheinend gilt das gleiche Problem analog auch für einige andere DBMS. Ich habe vergleichbare Einstellungen in der PHP.ini auch für die ODBC-Schnittstelle gefunden.

[asp2php]

ja ändere die Einstellung in .ini dann sollte es gehen.

wozu brauchst du ntext, oder überhaupt n-Typen? das wird zwar angeboten, aber so selten genutzt, weil man nur umständlich mit diesen Typen umgehen kann. Ich speichere die exotischen Daten in ganz normalen Felder mit char, varchar, text. Es kommt darauf an, dass du die Daten mit den richtigen Encoding und Charset wieder darstellst, wie sie erfasst wurden, du kannst die Daten nur nicht im EM oder QA ansehen

[Marcusson]

Wozu ntext? Ganz einfach: Laut Handbuch zu MS SQL Server 2005 werden angeblich alle Ausgaben mit einer Länge von mehr als 8kb sowieso automatisch in ntext umgewandelt. Ergo, wenn man sehr große Datenmengen schaufelt kommt man zwangsläufig damit in Kontakt. Zudem wäre da noch die UTF-8 Kodierung von XML-Dateien.

Außerdem ist es doch schon interessant, mit XQueries auf einer Datenbank arbeiten zu können. Vor allem dann, wenn es sich bei den Daten um XML-Dateien handelt, von denen jede ein paar Megabyte groß ist und man beispielsweise aus dem Datenpool nur alle XML-Subtrees aus der Ebene "Urteilsbegründung" benötigt, welche einen Tag "Datum" mit dem Attribut "Jahr" > "2000" und < "2003" haben.

Macht doch Sinn, oder???