mysql_connect liefert kein false

Hallo,
ich möchte den Fehler abfangen, wenn MySQL gar nicht läuft.
mysql_connect sollte doch im Fehlerfall false zurückliefern, jedoch wird
nach Aufruf dieser Funktion die weitere Verarbeitung des PHP-Skripts
einfach abgebrochen.

if (false == $this->connect) {
echo ":".$this->connect.": hier1\n";
$this->connect = mysql_connect($dbhost, $dbuser, $dbpw);
echo "hier2\n";


"hier2" wird nicht mehr ausgegeben, wenn MySQL nicht läuft. Jemand eine
Idee, was da nicht stimmen könnte?

Gruß,
Thomas B

Re: mysql_connect liefert kein false

Thomas Barth schrieb:

> mysql_connect sollte doch im Fehlerfall false zurückliefern, jedoch wird
> nach Aufruf dieser Funktion die weitere Verarbeitung des PHP-Skripts
> einfach abgebrochen.

Setze mal Dein Error Reporting auf E_ALL, lass das Script laufen und
schaue Dir die Fehlermeldung an. Falls Dir die nicht weiterhilft, teile
sie uns mit.

Gruß. Claus

Re: mysql_connect liefert kein false

Claus Reibenstein wrote:
> Thomas Barth schrieb:
>
>> mysql_connect sollte doch im Fehlerfall false zurückliefern, jedoch wird
>> nach Aufruf dieser Funktion die weitere Verarbeitung des PHP-Skripts
>> einfach abgebrochen.
>
> Setze mal Dein Error Reporting auf E_ALL, lass das Script laufen und
> schaue Dir die Fehlermeldung an. Falls Dir die nicht weiterhilft, teile
> sie uns mit.
>
> Gruß. Claus

Ich wollte gerade schreiben, dass ich es auf E_ALL gesetzt habe, sah
dann aber, dass ich error_reporting(E_ALL); geschrieben hatte, wofür es
keine Fehlerausgabe gibt :-)

Gruß,
Thomas

Re: mysql_connect liefert kein false

Thomas Barth schrieb:
>>> mysql_connect sollte doch im Fehlerfall false zurückliefern, jedoch=
wird
>>> nach Aufruf dieser Funktion die weitere Verarbeitung des PHP-Skripts
>>> einfach abgebrochen.
>> Setze mal Dein Error Reporting auf E_ALL, lass das Script laufen und
>> schaue Dir die Fehlermeldung an. Falls Dir die nicht weiterhilft, teil=
e
>> sie uns mit.
>>
>> Gruß. Claus
>=20
> Ich wollte gerade schreiben, dass ich es auf E_ALL gesetzt habe, sah
> dann aber, dass ich error_reporting(E_ALL); geschrieben hatte, wofür =
es
> keine Fehlerausgabe gibt :-)

Hä?

Na egal, mehrere Vermutungen, darunter die üblichen Verdächtigen:
- Ist die mysql-Extension vorhanden? Sprich: Klappt denn der Connect bei
laufendem Server? Du hast nur den Fehlerfall mitgeteilt...
- Treffen die Notes auf http://php.net/mysql_connect auf deinen
Anwendungsfall zu?
- Wenn die Engine selber abschmiert, dann bekommst du auch keine
Fehlermeldung mehr. Das wäre oll.
- Windows/Linux: Ärger mit der Firewall?
- Linux: Zugriffsrechte?

Generell: Bitte immer ein vollständiges Snippet posten und am besten
Betriebssystem/Server/PHP-Version/ usw. nennen, wenn das relevant sein
könnte.

Und überhaupt: Wieso nutzt immer noch alle Welt mysql, wo die Extension=

längst aus der Standard-Distro geflogen ist? Wenn schon pures MySQL,
dann bitte mit mysqli. Oder gleich PDO nehmen...

OLLi

--=20
We believe the makers created the chosen realm in 9 days.
They believe it took 10.
[Enterprise 312]

Re: mysql_connect liefert kein false

Oliver Grätz schrieb:

> Und überhaupt: Wieso nutzt immer noch alle Welt mysql, wo die Extension
> längst aus der Standard-Distro geflogen ist? Wenn schon pures MySQL,
> dann bitte mit mysqli. Oder gleich PDO nehmen...

Das hat mich neugierig gemacht, also habe ich auf der PHP-Website mal
nachgeschaut.

Zu mysqli steht dort:

| Warnung
|
| Diese Erweiterung ist EXPERIMENTELL. Das Verhalten dieser Erweiterung,
| einschließlich der Funktionsnamen, und alles Andere was hier
| dokumentiert ist, kann sich in zukünftigen PHP-Versionen ohne
| Ankündigung ändern. Seien Sie gewarnt und verwenden Sie diese
| Erweiterung auf eigenes Risiko.
Quelle:

Das hält mich davon ab, diese Erweiterung zu benutzen.

Zu PDO:
| PDO benötigt die neuen OO-Features im Kern von PHP 5 und wird deswegen
| nicht mit früheren Versionen von PHP funktionieren.
Quelle:

Ich erstelle Websites oder Datenbanken für kleine und mittlere
Unternehmen. Die ganz kleinen Firmen sind häufig auf günstigen Webspace
angewiesen, und da läuft überwiegend noch PHP 4. Also kommt PDO auch
nicht infrage.

Was ist der Nachteil von der mysql-Extension?

Viele Grüße
Gustaf

Re: mysql_connect liefert kein false

Gustaf Mossakowski meinte:

> Zu mysqli steht dort:
>
> | Warnung
> |
> | Diese Erweiterung ist EXPERIMENTELL. Das Verhalten dieser Erweiterung,
> | einschließlich der Funktionsnamen, und alles Andere was hier
> | dokumentiert ist, kann sich in zukünftigen PHP-Versionen ohne
> | Ankündigung ändern. Seien Sie gewarnt und verwenden Sie diese
> | Erweiterung auf eigenes Risiko.
> Quelle:
>
> Das hält mich davon ab, diese Erweiterung zu benutzen.

Keine Ahnung, wo du da schaust. Obiges Link liefert mir eine
englischesprachige Manual-Seite ganz ohne Warnung. Auch bei den
einzelnen Funktionen steht da nichts mehr. Stand ist 31.5. - 1.6.2007

> Was ist der Nachteil von der mysql-Extension?

Das ihr die Vorteile der Alternativen fehlen.

Gruß, Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: mysql_connect liefert kein false

..oO(Gustaf Mossakowski)

>Oliver Grätz schrieb:
>
>> Und überhaupt: Wieso nutzt immer noch alle Welt mysql, wo die Extension
>> längst aus der Standard-Distro geflogen ist? Wenn schon pures MySQL,
>> dann bitte mit mysqli. Oder gleich PDO nehmen...
>
>Das hat mich neugierig gemacht, also habe ich auf der PHP-Website mal
>nachgeschaut.
>
>Zu mysqli steht dort:
>
>| Warnung
>|
>| Diese Erweiterung ist EXPERIMENTELL. Das Verhalten dieser Erweiterung,
>| einschließlich der Funktionsnamen, und alles Andere was hier
>| dokumentiert ist, kann sich in zukünftigen PHP-Versionen ohne
>| Ankündigung ändern. Seien Sie gewarnt und verwenden Sie diese
>| Erweiterung auf eigenes Risiko.
>Quelle:
>
>Das hält mich davon ab, diese Erweiterung zu benutzen.

Richte Dich nach dem englischen Handbuch, nicht nach dem deutschen.

http://www.php.net/manual/en/ref.mysqli.php

>Zu PDO:
>| PDO benötigt die neuen OO-Features im Kern von PHP 5 und wird deswegen
>| nicht mit früheren Versionen von PHP funktionieren.
>Quelle:
>
>Ich erstelle Websites oder Datenbanken für kleine und mittlere
>Unternehmen. Die ganz kleinen Firmen sind häufig auf günstigen Webspace
>angewiesen, und da läuft überwiegend noch PHP 4. Also kommt PDO auch
>nicht infrage.

Jeder vernünftige Host bietet selbst in den preiswertesten Paketen PHP 4
und 5 parallel an. Das Kostenargument ist schon lange nicht mehr gültig.

>Was ist der Nachteil von der mysql-Extension?

Andersrum ausgedrückt: Die anderen Schnittstellen haben eindeutige
Vorteile, insbesondere PDO. Diese betreffen hauptsächlich Sicherheit,
Wartbarkeit und Flexibilität des Codes.

Micha

Re: mysql_connect liefert kein false

Gregor Kofler schrieb:

>> Quelle:
>
> Keine Ahnung, wo du da schaust. Obiges Link liefert mir eine
> englischesprachige Manual-Seite ganz ohne Warnung. Auch bei den
> einzelnen Funktionen steht da nichts mehr. Stand ist 31.5. - 1.6.2007

Hmm. Habe mich mal durch die Sprachen geklickt, da scheint's wirklich
nur auf der deutschsprachigen Seite zu stehen (Last updated: Thu, 31 May
2007). Auf der französischsprachigen ist's nicht drauf, Last update
Februar 2007. Das ist ja ärgerlich.

>> Was ist der Nachteil von der mysql-Extension?
>
> Das ihr die Vorteile der Alternativen fehlen.

Dann werde ich mir die Vorteile mal anschauen. Vielen Dank, auch an
Micha.

Viele Grüße
Gustaf

Re: mysql_connect liefert kein false

Gustaf Mossakowski schrieb:
>>> Quelle:
>> Keine Ahnung, wo du da schaust. Obiges Link liefert mir eine=20
>> englischesprachige Manual-Seite ganz ohne Warnung. Auch bei den=20
>> einzelnen Funktionen steht da nichts mehr. Stand ist 31.5. - 1.6.2007
>=20
> Hmm. Habe mich mal durch die Sprachen geklickt, da scheint's wirklich=20
> nur auf der deutschsprachigen Seite zu stehen (Last updated: Thu, 31 Ma=
y=20
> 2007). Auf der französischsprachigen ist's nicht drauf, Last update=20
> Februar 2007. Das ist ja ärgerlich.

Merke: Falls du englisch kannst, schalte php.net auf englisch. Die
englische Doku ist grundsätzlich die aktuellste und speziell die
deutsche hat den Ruf, stellenweise weit hinterher zu hinken.

mysqli ist etwa schon so lange stabil wie MySQL 4.1 bei MySQL AB den
Generally Available Status erreicht hat. Inzwischen ist 5.0 die
Produktivversion!

OLLi

--=20
"Show the cleavage, say the line. Got it?"
[Director, Angel 219]

Re: mysql_connect liefert kein false

Gustaf Mossakowski schrieb:
> Ich erstelle Websites oder Datenbanken für kleine und mittlere=20
> Unternehmen. Die ganz kleinen Firmen sind häufig auf günstigen Webs=
pace=20
> angewiesen, und da läuft überwiegend noch PHP 4. Also kommt PDO auc=
h=20
> nicht infrage.

Quark. Selbst das 4 Euro Paket von Strato bietet PHP5.

> Was ist der Nachteil von der mysql-Extension?
Neben den fehlenden Features auch, dass sie aus Lizenzgründen quasi aus=

dem Core geflogen ist. Statt mit MySQL wird PHP aktuell mit SQLite als
DB-Interface ausgeliefert. Das merkt man als Programmierer übrigens nur=
,
wenn man sein PHP selber kompiliert, weil man sonst weiterhin alles als
Modul verfügbar hat.

Nachteil: Man sieht nicht, wo aktiv entwickelt wird. Die alte
mysql-Extension ist entwicklungstechnisch quasi tot, es wird aktuell gar
an einer lizenzrechtlich freieren, nativen Extension gewerkelt, die dann
ohne die libmysql auskommen wird.

Der beste Weg ist aktuell PDO. Das Interface ist für alle
Datenbanksysteme einheitlich, wenn auch die Queries wegen abweichender
SQL-Sprachstandards nicht automatisch einen Wechsel von MySQL auf
Postgres überstehen. Aber immerhin muss man die API nur einmal lernen.
Außerdem kann man sich bei PDOs Prepared Statements meistens das
manuelle Escaping schenken.

OLLi


--=20
Cordy: "So it was that green card thing?"
Harry: "Nope. It was a madly-in-love-couldn't-live-without-each-other
kinda thing."
[Angel 107]

Re: mysql_connect liefert kein false

Hallo!

Oliver Grätz schrieb:
> Außerdem kann man sich bei PDOs Prepared Statements meistens das
> manuelle Escaping schenken.

was heißt *meistens* etwas ausführlicher? Ich bin erst vor relativ
kurzer Zeit auf PDO umgestiegen und ich fürchte, dass ich noch nicht
alles im Sinne des Erfinders anwende. Wenn ich in prepared Statements
Parameter-Binding benutze, escape ich gar nichts mehr ... Ist das falsch?


Gruß,
Habbo

Re: mysql_connect liefert kein false

Jan Habbo Brüning schrieb:
> Hallo!
>=20
> Oliver Grätz schrieb:
>> Außerdem kann man sich bei PDOs Prepared Statements meistens das
>> manuelle Escaping schenken.
>=20
> was heißt *meistens* etwas ausführlicher? Ich bin erst vor re=
lativ=20
> kurzer Zeit auf PDO umgestiegen und ich fürchte, dass ich noch nic=
ht=20
> alles im Sinne des Erfinders anwende. Wenn ich in prepared Statements=20
> Parameter-Binding benutze, escape ich gar nichts mehr ... Ist das falsc=
h?

Du kannst nur die Parameter über Prepared Statements binden, nicht a=
ber
Spaltenbezeichner. Also funktioniert

SELECT * FROM huba WHERE name=3D?

aber nicht

SELECT * FROM huba WHERE ?=3D?

oder

SELECT * FROM huba WHERE name=3D? ORDER BY ?

Zuletzt ist mir das bei MySQL noch um die Ohren geflogen, weil zumindest
die nativen Prepared Statements weder mit dem ersten noch mit dem
zweiten Fragezeichen was anfangen können. Das könnte mit der Op=
tion
EMULATE_PREPARES anders aussehen, was ja wohl neuerdings Standard ist,
wenn ich die PHP-Release Notes richtig gelesen habe. Aus der Sicht des
DBMS ist die Beschränkung jedoch völlig richtig, denn Prepared
Statements bedeuten, dass es tatsächlich den Ausführplan schon =
vorab
generieren und speichern kann und später nur noch die Parameterwerte=

einsetzt. Änderungen an was anderen als den Parameterwerten füh=
ren zu
völlig anderen Plänen und passen demnach nicht in das "Prepared=
" Konzept.

Sollte aber nicht so sein, dann musst du alles, was dynamisch ist und
womöglich von draußen kommt, zunächst wie früher esca=
pen. Das gilt
insbesondere für Sortierkriterien wie oben im Beispiel, die ja gerne=
mal
als GET-Parameter rumgereicht werden.

OLLi

--=20
An Vanessa von den No Angels:
â€=9CDeutschland liebt Dich und die anderen 4 Schlampen!â€=9D
[Nora Tschirner]

Re: mysql_connect liefert kein false

Oliver Grätz schrieb:
> Du kannst nur die Parameter über Prepared Statements binden, nicht aber
> Spaltenbezeichner. Also funktioniert
>
> SELECT * FROM huba WHERE name=?
>
> aber nicht
>
> SELECT * FROM huba WHERE ?=?
>
> oder
>
> SELECT * FROM huba WHERE name=? ORDER BY ?

Ist klar. Aber Spaltennamen würde doch auch niemand ernsthaft aus
Benutzervariablen übernehmen oder? Selbst wenn die maskiert worden sind,
resultiert das Ganze ja in einer Ausnahme, wenn die Spalte nicht
existiert. Sowas hole ich mir immer über switch() oder per Index aus
einem Array, so dass bei Fehleingabe immer ein Defaultwert zurückkommt.


Gruß,
Habbo

Re: mysql_connect liefert kein false

Oliver Grätz wrote:

>>
>> Ich wollte gerade schreiben, dass ich es auf E_ALL gesetzt habe, sah
>> dann aber, dass ich error_reporting(E_ALL); geschrieben hatte, wofür es
>> keine Fehlerausgabe gibt :-)
>
> Hä?
>

Hehe, man muss auch error_reporting('E_ALL'); , um die gewünschten
Fehlermeldungen zu erhalten :-)

Gruß,

Re: mysql_connect liefert kein false

Oliver Grätz wrote:

> Du kannst nur die Parameter über Prepared Statements binden, nicht aber
> Spaltenbezeichner. Also funktioniert
>
> SELECT * FROM huba WHERE name=?
>
> aber nicht
>
> SELECT * FROM huba WHERE ?=?
>
> oder
>
> SELECT * FROM huba WHERE name=? ORDER BY ?
>

Erinnert mich irgendwie an Perl-DBI :-) Und das gibt es schon seit
Jahren! Lustig, wenn sich eine Sprache weiterentwickeltet, indem sie die
Features aus anderen Sprachen übernimmt.

Gruß,
Thomas B