SQL select fehlerhafte Resultate. Ist PHP 64 Bit das Problem?

peterw · 10.04.2009, 01:00

SQL Select-Befehle mit PHP zu MS SQL Server via unixODBC und freeTDS
sind fehlerhaft unter 64 Bit (openSUSE 10.2 und 11.1) und sind korrekt
unter 32 Bit (openSUSE 10.2 und 11.1).

Die Aufgabe:
PHP auf openSUSE 10.2 x86_64 soll Verbindung zu MS SQL Server 2000 aufnehmen.

Die Installation:
openSUSE 10.2 x86_64 ist eine Standardinstallation, keine GUI, nur Textmodus.

Dann openSUSE RPMs:
apache2 (v2.2.3)
apache2_mod_php5 (v5.2.0-10)

unixODBC gibts als openSUSE RPM aber libtdsodbc.so fehlt.
Deswegen selbst kompiliert (v2.2.14).
./configure --enable-gui=no
make
make install

Environmentvariable LD_LIBRARY_PATH gesetzt in /etc/profile.local.
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/lib
export LD_LIBRARY_PATH

freeTDS selbst kompiliert (v0.82).
./configure --with-tdsver=8.0
make
make install

tds.driver Datei mit:
[FreeTDS]
Description = v0.82 with protocol v8.0
Driver = /usr/local/lib/libtdsodbc.so

Treiber installieren:
odbcinst -i -d -f tds.driver

tds.datasource-Datei mit:
[MSSQLServer]
Driver = FreeTDS
Description = Datenbank
Trace = No
Server = IP des SQL Servers
Port = 1433
Database = Datenbank

Installieren:
odbcinst -i -s -f tds.datasource

odbcinst -j liefert:
unixODBC 2.2.14
DRIVERS............: /usr/local/etc/odbcinst.ini
SYSTEM DATA SOURCES: /usr/local/etc/odbc.ini
FILE DATA SOURCES..: /usr/local/etc/ODBCDataSources
USER DATA SOURCES..: /root/.odbc.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Size.: 8

Verbindung zum SQL-Server auf der Konsole:
isql -v MSSQLServer user password
+---------------------------------------+
| Connected! |
| |
| sql-statement |
| help [tablename] |
| quit |
| |
+---------------------------------------+

select-Befehle hier sind ok.

Auch: Die Logs von unixODBC und freeTDS zeigen, dass alle Daten ankommen.

Bis hierher scheint es also ok zu sein.

Nun PHP.
Das php5-odbc-RPM von openSUSE installiert odbc.so.
odbc.so als Extension in php.ini eingetragen.
Apache restart: PHP-Skript bekommt keine Verbindung zum SQL-Server.

Also odbc.so neu kompiliert.
php5-devel und autoconf installiert.
openSUSE-RPM php.src (v5.2.0-10) installiert.
Bekomme php5-5.2.0.tar.bz2.
Auspacken.
Nach Unterordner ext/odbc.
phpize
./configure --with-unixODBC=shared,/usr/local
make

Im Unterordner modules ist nun odbc.so.
Nach /usr/lib64/php5/extensions kopiert.

Eintrag in der /etc/phph5/apache2/php.ini:
extension = odbc.so
apache restart.

2 PHP-Skripte geschrieben, siehe unten:
Skript1: select auf Tabelle mit 1 Datensatz: Liefert nichts.
Skript2: select auf Tabelle mit 10389 Datensätze: Liefert 10283 Datensätze.
D.h. die Ausgabe ist fehlerhaft.
PHP liefert keinen ehler.

Das gleiche Vorgehen auf openSUSE x86_32:
Skript1: select auf Tabelle mit 1 Datensatz: Liefert 1 Datensatz.
Skript2: select auf Tabelle mit 10389 Datensätze: Liefert 10389 Datensätze.
D.h. die Ausgabe ist korrekt.

Fazit:
32 Bit scheint ok zu sein.
64 Bit scheint bis zu unixODBC und freeTDS ok zu sein.
PHP ist nicht mehr ok.

Das gleiche Verhalten bei PHP 5.2.6 auf openSUSE 11.1.
32 Bit scheint ok zu sein.
64 Bit scheint bis zu unixODBC und freeTDS ok zu sein.
PHP ist nicht mehr ok.

Hat jemand eine Idee?
Vielen Dank.

----------------------------

Hier sind die PHP-Skripte.
Nur die Tabellen im select Befehl unterscheiden sich.

PHP-Code:

  
    error_reporting(E_ALL);

    $dsn="Driver=FreeTDS;TDS_Version=8.0;Server=IP_to_SQL_Server;Port=1433;Database=database_to_connect;UID=user;PWD=password";

    $connect = odbc_connect($dsn, "user", "password");

    print "Connect: $connect";

    $query = "SELECT * FROM table";

    $result = odbc_exec($connect, $query);

    while(odbc_fetch_row($result)) {
    $field1 = odbc_result($result, 1);
    $field2 = odbc_result($result, 2);
    $field3 = odbc_result($result, 3);
    $field4 = odbc_result($result, 4);
    print("$field1 $field2 $field3 $field4\n");
    print "<hr>";
    }

    odbc_close($connect);

JEGO · 10.04.2009, 08:23

Für das Highlighting von PHP-Code sind die [php]-Tags zuständig. Bitte ändere das noch.

tohms · 12.04.2009, 13:25

Was sagen denn Deine Logdateien im System? Sieht mir eher nach einem Paketproblem aus und Du wärst mit der Frage in einem SUSE-Forum vielleicht besser aufgehoben, da SUSE doch gern manche Dinge komplett anders macht.

peterw · 16.04.2009, 00:03

Vielen Dank für Deine Antwort thoms.

Das mit den SUSE-Foren hatte ich mir auch gedacht.
Meine Frage stellte ich zuerst im openSUSE-Forum.
Keine Antwort bisher.

Dann erst kam ich auf dieses Forum.

Und es hat sich gelohnt.
Deine einfache Frage nach den "Logdateien im System" ist ein Treffer!
Irgendwie ging das bei mir total unter.
Peinlich für mich.
Danke.

Die Logdateien liefern:
+ 32 Bit (SUSE 10.2 und 11.1) keine verwertbaren Einträge nach
select-Befehlen.
+ 64 Bit (SUSE 10.2 und 11.1) liefert nach select-Befehlen:
/var/log/apache2/error_log liefert:
[error] [client IP] ALERT - canary mismatch on efree() - heap overflow
detected (attacker ...).
Und /var/log/messages liefert:
... suhosin[3731]: ALERT - canary mismatch on efree() - heap overflow
detected (attacker ...).

php -v ergibt:
PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Dec 3 2008 15:21:5

Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies

Googeln ergab bisher 3 Reparaturvarianten:

Variante 1:
In der php.ini die Variable "memory_limit" hochsetzen.
Hat bei mir nicht geholfen, selbst bei einem Wert von 500M nicht.

Variante 2:
Von PHP 5.2 zu PHP 5.3 upzugraden.
PHP 5.3 scheints noch nicht zu geben.

Variante 3:
Suhosin abschalten.
Damit bekomme ich aber das folgende Problem:
Die SUSE bringt Suhosin schon im PHP-RPM mit.
Abschalten würde hier wohl bedeuten:
PHP deinstallieren.
Dann PHP ohne Suhosin neu kompilieren.
Ist das richtig?
Gerade sowas möchte ich aber vermeiden.
Gehts noch anders?
Ohne solche tiefgreifenden Veränderungen?

Vielen Dank

peterw

tohms · 16.04.2009, 07:53

Also suhosin kannst Du normalerweise in der php.ini de-/aktivieren. In wie weit das aber Sinn macht, ist die Frage. Wenn es ein öffentlicher Server ist, würde ich mir das gut überlegen, da es grundlegende Sicherheit bietet.
Vielleicht wäre es sinnvoll erstmal die Query zu optimieren!?

PS: GIbt es für SUSE schon das 5.2.9 als rpm? Vielleicht das mal probieren!

peterw · 17.04.2009, 03:13

Hallo tohms,

danke für Deine Antwort.

Sorry, ich hab mich unpräzise ausgedrückt.
Suhosin existiert hier nur als Patch, nicht als Extension.
Mittlerweile weiss ich, dass der Patch, weil Patch, nicht deaktiviert
werden kann. Um den suhosin-Patch zu deaktivieren, müsste wohl PHP
vollständig neu kompiliert werden.

Andererseits gebe ich Dir recht, dass das Deaktivieren von suhosin
wegen der Sicherheit keine gute Idee ist.

Das Deaktivieren macht nur insoweit Sinn, um zu checken, ob meine
Abfragen dann durchgehen, oder ob es nicht noch weitere Probleme gibt.

Was verstehst Du unter optimieren der query?
Meine query ist ein "SELECT * FROM table";

Ein SUSE 5.2.9-PHP-RPM existiert, allerdings nur für die SUSE 11.1.
Ich werde das mal mit 5.2.9 und 64 Bit probieren.

Leider ist aber meine Hauptbaustelle SUSE 10.2 64 Bit.
Dafür hab ich bisher kein 5.2.9-PHP-RPM gefunden.

Ich habe heute mal den easysoft ODBC-Treiber für den SQL Server installiert.
Damit habe ich bei SUSE 10.2 64 Bit keine Probleme mit meinen Abfragen.
Nur: Der Teiber kostet knapp 800 Euro.
Damit ist der Treiber out.
Die Sache zeigt mir allerdings eins: Unlösbar ist mein Problem mit
SUSE 10.2 64 Bit nicht.

Vielen Dank

peterw

tohms · 21.04.2009, 09:19

Hallo Peter,

so wie ich das sehe, solltest Du vielleicht doch mal an eine eigene Kompilierung denken, um es dann damit zu testen.
Aber - und das meinte ich mit Optimierung - scheint es so zu sein, dass der Speicherverbrauch zu groß ist und ein Select über eine ganze Tabelle ohne Einschränkung könnte natürlich vermuten lassen, dass da ein "Unhold" unterwegs ist. Brauchst Du denn tatsächlich alle Daten aus der Tabelle? Kannst Du es nicht durch Where-Klauseln oder durch Limit einschränken?

Gruß
Thomas

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
<div> Tag select() Problem	sharp	JavaScript, Ajax und mehr	13	19.09.2008 00:23
Problem mit SELECT IF	r-ene	Datenbanken	2	07.02.2008 10:22
SELECT AS geht bei AVG net	cyberholic	Datenbanken	0	04.05.2006 09:43
Mysql SELECT Abfrage -- Problem mit LIMIT	djrace	Datenbanken	2	01.05.2006 12:58
Problem beim Auswerten eines select Feldes	FireFIghter	PHP Tipps 2006	3	23.04.2006 15:28
SELECT problem	Fatal Error	PHP Tipps 2006	5	21.04.2006 16:31
[JavaScript] Event Handler in form select - Syntax?	winfo_cologne	HTML, Usability und Barrierefreiheit	5	29.03.2006 16:47
Fehlerhafte MySQL Ausgabe mit SELECT	c-bass	Datenbanken	16	23.08.2005 14:49
[Erledigt] Select Statement - Order by Problem mit Datentypen		Datenbanken	6	03.06.2005 16:02
Problem mit select (AND, OR und Like gemixt)	pixelcut	Datenbanken	3	11.05.2005 10:14
[Erledigt] SELECT Problem		PHP Tipps 2005	6	08.03.2005 21:10
[Erledigt] SELECT ... LIKE Problem		Datenbanken	10	05.03.2005 13:21
mysql SELECT problem	yoshy	Datenbanken	7	20.02.2005 00:46
[Erledigt] Select &amp;amp; Update Syntax Problem!		Datenbanken	3	14.12.2004 18:17
Formular Select Problem		PHP Tipps 2004	3	22.08.2004 17:28

10.04.2009, 01:00
peterw Neuer Benutzer Registriert seit: 10.04.2009 Beiträge: 3	SQL select fehlerhafte Resultate. Ist PHP 64 Bit das Problem? SQL Select-Befehle mit PHP zu MS SQL Server via unixODBC und freeTDS sind fehlerhaft unter 64 Bit (openSUSE 10.2 und 11.1) und sind korrekt unter 32 Bit (openSUSE 10.2 und 11.1). Die Aufgabe: PHP auf openSUSE 10.2 x86_64 soll Verbindung zu MS SQL Server 2000 aufnehmen. Die Installation: openSUSE 10.2 x86_64 ist eine Standardinstallation, keine GUI, nur Textmodus. Dann openSUSE RPMs: apache2 (v2.2.3) apache2_mod_php5 (v5.2.0-10) unixODBC gibts als openSUSE RPM aber libtdsodbc.so fehlt. Deswegen selbst kompiliert (v2.2.14). ./configure --enable-gui=no make make install Environmentvariable LD_LIBRARY_PATH gesetzt in /etc/profile.local. LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/lib export LD_LIBRARY_PATH freeTDS selbst kompiliert (v0.82). ./configure --with-tdsver=8.0 make make install tds.driver Datei mit: [FreeTDS] Description = v0.82 with protocol v8.0 Driver = /usr/local/lib/libtdsodbc.so Treiber installieren: odbcinst -i -d -f tds.driver tds.datasource-Datei mit: [MSSQLServer] Driver = FreeTDS Description = Datenbank Trace = No Server = IP des SQL Servers Port = 1433 Database = Datenbank Installieren: odbcinst -i -s -f tds.datasource odbcinst -j liefert: unixODBC 2.2.14 DRIVERS............: /usr/local/etc/odbcinst.ini SYSTEM DATA SOURCES: /usr/local/etc/odbc.ini FILE DATA SOURCES..: /usr/local/etc/ODBCDataSources USER DATA SOURCES..: /root/.odbc.ini SQLULEN Size.......: 8 SQLLEN Size........: 8 SQLSETPOSIROW Size.: 8 Verbindung zum SQL-Server auf der Konsole: isql -v MSSQLServer user password +---------------------------------------+ \| Connected! \| \| \| \| sql-statement \| \| help [tablename] \| \| quit \| \| \| +---------------------------------------+ select-Befehle hier sind ok. Auch: Die Logs von unixODBC und freeTDS zeigen, dass alle Daten ankommen. Bis hierher scheint es also ok zu sein. Nun PHP. Das php5-odbc-RPM von openSUSE installiert odbc.so. odbc.so als Extension in php.ini eingetragen. Apache restart: PHP-Skript bekommt keine Verbindung zum SQL-Server. Also odbc.so neu kompiliert. php5-devel und autoconf installiert. openSUSE-RPM php.src (v5.2.0-10) installiert. Bekomme php5-5.2.0.tar.bz2. Auspacken. Nach Unterordner ext/odbc. phpize ./configure --with-unixODBC=shared,/usr/local make Im Unterordner modules ist nun odbc.so. Nach /usr/lib64/php5/extensions kopiert. Eintrag in der /etc/phph5/apache2/php.ini: extension = odbc.so apache restart. 2 PHP-Skripte geschrieben, siehe unten: Skript1: select auf Tabelle mit 1 Datensatz: Liefert nichts. Skript2: select auf Tabelle mit 10389 Datensätze: Liefert 10283 Datensätze. D.h. die Ausgabe ist fehlerhaft. PHP liefert keinen ehler. Das gleiche Vorgehen auf openSUSE x86_32: Skript1: select auf Tabelle mit 1 Datensatz: Liefert 1 Datensatz. Skript2: select auf Tabelle mit 10389 Datensätze: Liefert 10389 Datensätze. D.h. die Ausgabe ist korrekt. Fazit: 32 Bit scheint ok zu sein. 64 Bit scheint bis zu unixODBC und freeTDS ok zu sein. PHP ist nicht mehr ok. Das gleiche Verhalten bei PHP 5.2.6 auf openSUSE 11.1. 32 Bit scheint ok zu sein. 64 Bit scheint bis zu unixODBC und freeTDS ok zu sein. PHP ist nicht mehr ok. Hat jemand eine Idee? Vielen Dank. ---------------------------- Hier sind die PHP-Skripte. Nur die Tabellen im select Befehl unterscheiden sich. PHP-Code: error_reporting(E_ALL); $dsn="Driver=FreeTDS;TDS_Version=8.0;Server=IP_to_SQL_Server;Port=1433;Database=database_to_connect;UID=user;PWD=password"; $connect = odbc_connect($dsn, "user", "password"); print "Connect: $connect"; $query = "SELECT * FROM table"; $result = odbc_exec($connect, $query); while(odbc_fetch_row($result)) { $field1 = odbc_result($result, 1); $field2 = odbc_result($result, 2); $field3 = odbc_result($result, 3); $field4 = odbc_result($result, 4); print("$field1 $field2 $field3 $field4\n"); print "<hr>"; } odbc_close($connect); Geändert von peterw (10.04.2009 um 10:03 Uhr).


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

10.04.2009, 08:23
JEGO Erfahrener Benutzer Registriert seit: 01.12.2003 Beiträge: 2.555 PHP-Kenntnisse: Anfänger	Für das Highlighting von PHP-Code sind die [php]-Tags zuständig. Bitte ändere das noch. __________________ Gruß JEGO Ein PHP Script tut, was Du schreibst, nicht was Du willst.

12.04.2009, 13:25
tohms Benutzer Registriert seit: 19.10.2008 Beiträge: 44	Was sagen denn Deine Logdateien im System? Sieht mir eher nach einem Paketproblem aus und Du wärst mit der Frage in einem SUSE-Forum vielleicht besser aufgehoben, da SUSE doch gern manche Dinge komplett anders macht.

16.04.2009, 00:03
peterw Neuer Benutzer Registriert seit: 10.04.2009 Beiträge: 3	Vielen Dank für Deine Antwort thoms. Das mit den SUSE-Foren hatte ich mir auch gedacht. Meine Frage stellte ich zuerst im openSUSE-Forum. Keine Antwort bisher. Dann erst kam ich auf dieses Forum. Und es hat sich gelohnt. Deine einfache Frage nach den "Logdateien im System" ist ein Treffer! Irgendwie ging das bei mir total unter. Peinlich für mich. Danke. Die Logdateien liefern: + 32 Bit (SUSE 10.2 und 11.1) keine verwertbaren Einträge nach select-Befehlen. + 64 Bit (SUSE 10.2 und 11.1) liefert nach select-Befehlen: /var/log/apache2/error_log liefert: [error] [client IP] ALERT - canary mismatch on efree() - heap overflow detected (attacker ...). Und /var/log/messages liefert: ... suhosin[3731]: ALERT - canary mismatch on efree() - heap overflow detected (attacker ...). php -v ergibt: PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Dec 3 2008 15:21:5 Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies Googeln ergab bisher 3 Reparaturvarianten: Variante 1: In der php.ini die Variable "memory_limit" hochsetzen. Hat bei mir nicht geholfen, selbst bei einem Wert von 500M nicht. Variante 2: Von PHP 5.2 zu PHP 5.3 upzugraden. PHP 5.3 scheints noch nicht zu geben. Variante 3: Suhosin abschalten. Damit bekomme ich aber das folgende Problem: Die SUSE bringt Suhosin schon im PHP-RPM mit. Abschalten würde hier wohl bedeuten: PHP deinstallieren. Dann PHP ohne Suhosin neu kompilieren. Ist das richtig? Gerade sowas möchte ich aber vermeiden. Gehts noch anders? Ohne solche tiefgreifenden Veränderungen? Vielen Dank peterw

16.04.2009, 07:53
tohms Benutzer Registriert seit: 19.10.2008 Beiträge: 44	Also suhosin kannst Du normalerweise in der php.ini de-/aktivieren. In wie weit das aber Sinn macht, ist die Frage. Wenn es ein öffentlicher Server ist, würde ich mir das gut überlegen, da es grundlegende Sicherheit bietet. Vielleicht wäre es sinnvoll erstmal die Query zu optimieren!? PS: GIbt es für SUSE schon das 5.2.9 als rpm? Vielleicht das mal probieren!

17.04.2009, 03:13
peterw Neuer Benutzer Registriert seit: 10.04.2009 Beiträge: 3	Hallo tohms, danke für Deine Antwort. Sorry, ich hab mich unpräzise ausgedrückt. Suhosin existiert hier nur als Patch, nicht als Extension. Mittlerweile weiss ich, dass der Patch, weil Patch, nicht deaktiviert werden kann. Um den suhosin-Patch zu deaktivieren, müsste wohl PHP vollständig neu kompiliert werden. Andererseits gebe ich Dir recht, dass das Deaktivieren von suhosin wegen der Sicherheit keine gute Idee ist. Das Deaktivieren macht nur insoweit Sinn, um zu checken, ob meine Abfragen dann durchgehen, oder ob es nicht noch weitere Probleme gibt. Was verstehst Du unter optimieren der query? Meine query ist ein "SELECT * FROM table"; Ein SUSE 5.2.9-PHP-RPM existiert, allerdings nur für die SUSE 11.1. Ich werde das mal mit 5.2.9 und 64 Bit probieren. Leider ist aber meine Hauptbaustelle SUSE 10.2 64 Bit. Dafür hab ich bisher kein 5.2.9-PHP-RPM gefunden. Ich habe heute mal den easysoft ODBC-Treiber für den SQL Server installiert. Damit habe ich bei SUSE 10.2 64 Bit keine Probleme mit meinen Abfragen. Nur: Der Teiber kostet knapp 800 Euro. Damit ist der Treiber out. Die Sache zeigt mir allerdings eins: Unlösbar ist mein Problem mit SUSE 10.2 64 Bit nicht. Vielen Dank peterw

21.04.2009, 09:19
tohms Benutzer Registriert seit: 19.10.2008 Beiträge: 44	Hallo Peter, so wie ich das sehe, solltest Du vielleicht doch mal an eine eigene Kompilierung denken, um es dann damit zu testen. Aber - und das meinte ich mit Optimierung - scheint es so zu sein, dass der Speicherverbrauch zu groß ist und ein Select über eine ganze Tabelle ohne Einschränkung könnte natürlich vermuten lassen, dass da ein "Unhold" unterwegs ist. Brauchst Du denn tatsächlich alle Daten aus der Tabelle? Kannst Du es nicht durch Where-Klauseln oder durch Limit einschränken? Gruß Thomas