Fatal error: Call to undefined function mysql_connect()...

Mal die Frage an unsere PHP Cracks...
System: Windows 2003 Standard Server
IIS 6.0
MySQL 5.x
Ich bekomme das:
Fatal error: Call to undefined function mysql_connect() in ...
Nach locker 4 Stunden Googlen, rumtesten etc. bin ich keinen Schritt weiter gekommen.
Nur das die Jungs von MySQL denen von PHP die Schuld in die Schuhe schieben und die das gleiche über MySQL sagen.
Weder der Trick mit dem Eintrag in den Systemvariablen (PHPRC, welches mir ein paar schöne Exceptions von PHP zeigte), noch das Kopieren von php_mysql.dll und php_mysqli.dll in das PHP Hauptverzeichnis, noch das Kopieren derer in das System32 Verzeichnis haben geholfen.
XAMPP will ich bewußt nicht einsetzen. Das geht zwar, aber so leicht gebe ich nicht auf. Ich will verstehen was da schief geht und das Problem gelöst bekommen.
Manche Sachen in XAMPP gefallen mir halt einfach nicht.

extension=php_mysql.dll
in der php.ini vorhanden ?

Ja!
Ich habe vorhin sogar extra noch einen CVS Snapshot (Nightly Build) verwendet. Keine Chance.

was sagt die php-info?
wenns da nicht bei steht, dann wird es nicht geladen..
nach dem php.ini-ändern den iis neu gestartet?

Ich habe mal alles benötigte eingesammelt und hier abgelegt:
www.highantdev.de/transfer/serverproblem.zip

mhh oki dann weiter, libmysql.dll im windows dir ? (kein plan was die dort zu suchen hat, nur ohne hat es bei mir nicht gefunzt)

Sowohl in Windows als auch im System32.
Kein Ergebnis.

php.ini ist in c:\windows ?
vielleicht extension_dir... durch extension_dir = "./ext/" ersetzen ?

Alles schon probiert.
Wie man anhand von phpinfo sehen kann, wird ja mysql geladen.
Mir ist nur eben beim prüfen anhand von php.exe -m aufgefallen, daß sowohl php 5.2.5 als auch php 5.3.0 dev eine total vermurkste php.ini haben.
Ca. 20 Module sind blind dort eingebunden, welche überhaupt nicht vorliegen.
Toll.. jetzt hab ich 5.3.0 dev entfernt, 5.2.5 installiert und der IIS mag gar nicht mehr.
Bin langsam mega gefrustet von diesem Fummeln. Irgendwie bin ich vom XCopy Deploment a'la C# verwöhnt.
Jetzt habe ich mal versucht die ZIP-Version zu installieren von PHP 5.2.5...
Tjo... Permission Denied... Für heute gebe ich auf. Zeit für die Heia.

Geh ich recht in der Anahme das du versucht 2 Server Softwaren auf eine PC zu installieren?
Meines wissen kann man nur immer 1 laufen lassen entweder den Apache server oder den IIS6 Server von Microsoft.
Beide zusammen machen aber nur Probleme.
Mfg Splasch

Nein, wie ganz zu Anfang erwähnt...
IIS 6.0
MySQL 5.x
PHP 5.2.5
Kein Apache. Dafür habe ich den IIS.

1. Welchen Pfad gibt dir PHPInfo für die Konfigurationsdatei an?
2. Ist die Datei php_mysql.dll (bzw. php_mysqli.dll) im Ordner C:\Programme\PHP\ext (Pfad der PHP-Installation hängt von der Konfiguration ab)?
3. Ist die Datei libmysql.dll auf dem PC vorhanden (muss im Ordner C:\Programme\PHP liegen)?
Mit den 3 Punkten klappte es bei mir auf der virtuellen Umgebung.

1. Configuration File (php.ini) Path C:\WINDOWS
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHH
Mir geht hier eben ein Stern mittlerer Größe auf... WAS ZUR... ???
Ok, DASS check ich nachher gleich mal! Thx!

Lustigerweise gibt es unter C:\WINDOWS keine php.ini
Ich habe jetzt mal aus der in C:\PHP5\ alles rausgeworfen was meiner Meinung nicht notwendig ist. Zur Sicherheit ist mysql dort auch auskommentiert worden.
Beim prüfen ist mir dann noch aufgefallen, daß der Installer von PHP 5.2.5 den 8.3 DOS-Namen der ISAPI Variante verwendet hat, was der IIS mit einem Standard HTTP 404 quittiert hatte.
Nach der Auswahl der DLL mit der vollen Schreibweise und einem IISReset geht PHPInfo auch wieder.
Im Moment liebäugel ich aufgrund des Frusts mit dem SQL Server 2005 Express. Für meine Zwecke langt der voll und ganz.
Danke an alle für die Hilfe!
Ich denke mal, MySQL sollte jetzt auch keine große Hürde mehr darstellen.

Was zum lachen:
Fatal error: Call to undefined function mssql_connect()
Nach einigem Suchen bin ich jetzt vermutlich dahinter gekommen.
extension_dir ist laut phpinfo C:\PHP5
In der php.ini steht aber was anderes.
Selbst eine php.ini unter C:\Windows wird nicht gelesen. Ich muß hier wohl mal mit ein paar Tools von sysinternals ran um rauszufinden WOHER php diese Configdaten meint bekommen zu müssen.
AH... dank php --ini habe ich rausgefunden welche er liest... KEINE
Der findet keine und nimmt die Defaulteinstellungen.
Gebe ich ihm eine, dann kommt... nichts. Der IIS sagt HTTP 200, 0 Bytes send...

I love it... Das Forum... Und wieder 10 Minuten getippt, Save gedrückt und...
Ok, es geht jetzt. Ich bin zu faul nochmal alles zu tippen.

Dann hat ja die Leidensgeschichte einen krönenden Abschluss gefunden

Ich sag nur:
www.kolonialkampf.de/blog/?cat=10

Normalerweise wird man im Alter ja toleranter... irgendwie muß ich diesen Punkt bisher übersprungen haben

phpinfo();
?>
gibt aus welche php.ini eingeladen wird ( www.depon.net/phpinfo.php )

Martin... alles schön und gut, aber...
Wenn die Jungs vom PHP Team meinen, daß sie den Pfad HARDCODED eintragen müssen und man nur mittels PHPRC Eintrag in den Systemvariablen dem entgegen wirken kann und außerdem unmengen von Modulen als DEFAULT eingetragen sind, welche es schlicht und einfach nicht gibt...
Sorry... aber ich bin mega angefressen von dieser PHP Scheiße.

Hardcoded wo?
Ich seh da nur was bei Pear...

Starte mal php so: "php --ini"
Bei mir stand Hardcoded C:\Windows und von mir hat PHP das nicht.
Ich beziehe mich dabei auf den MSI Installer für 5.2.5

Das ist nicht Hardcoded denke ich, das ist der Default Wert.
Du müsstest php auch so starten können: php.exe -c D:\Irgendwas\php.ini
Dann nimmt er die von dir angegebene Ini.
Gruß,
Marc

PHP sucht in der Tat zuerst in c:\Windows bzw der %Windows_Directory% oder wie dies auch immer heißt.
Dies ist in der Tat in der Windows-Welt etwas ungewöhnlich, da Konfigurationsdaten entweder in der Registry, im LocalAppData-Path oder im Programmverzeichnis selbst liegen zu haben.
BTW: Ich nutze PHP 5.2.5 aus dem ZIP-Archiv. Dem MSI-Installer traue ich nicht so wirklich. Ich habe keinen Nerv, dass er mir irgendwie in den IIS reingreift.
@Klaus:
Ich vermute, dass PHP die Funktion GetEnvironmentPath bzw die Umgebungsvariable ausliest.

Der MSI Installer baut wirklich Bockmist.
So trägt er die Application Extension z.B. mit dem 8.3 DOS-Namen ein.
Und damit scheint der IIS nicht klar zu kommen. Man muß hier manuell dann den Eintrag zum einen neu Anlegen, zum anderen bei der .php Extension Registrierung den Dateinamen auch manuell anpassen.