Mai 25, 2022, 13:06:49

Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!


Access via PHP/PDO (ODBC): Sporadisch "Too many connections"

Begonnen von oliver1974, März 12, 2022, 18:48:12

⏪ vorheriges - nächstes ⏩

oliver1974

Hallo,

Ich versuche via PHP (und dort via PDO) auf eine Access Datenbank zuzugreifen, dass klappt bis auf einige Encoding-Detailprobleme eigentlich auch ganz gut.

Testumgebung ist auf einem Windows Rechner mit XAMPP, ODBC ist aktiviert in der php.ini, wie gesagt, funktioniert auch soweit, aber sporadisch beim Aufbau einer Verbindung via

$pdo = new PDO("odbc:Driver={Microsoft Access Driver (*.mdb, *.accdb)};charset=UTF-8; DBQ=$dbName; Uid=; Pwd=;");

.. haut er mir eine
SQLSTATE[08004] SQLDriverConnect: -1036 [Microsoft][ODBC-Treiber für Microsoft Access] Zu viele Client-Tasks.
.. als Exception um die Ohren.

Eigentlich dürften da nicht zu viele Verbindungen sein. Ich baue die sogar im PHP Skript nach Benutzung fleißig wieder ab, indem ich $pdo und davon abhängige Objekte auf null setze (was glaube ich explizit gar nicht notwendig wäre, die Connection sollte er nach Ende des Skriptes ja eh beenden.. vermutlich).

Danach hilft nur ein Neustart des Webserver.

Jemand eine Idee oder "best practices" bei solchen Problemen? Zu PHP in Verbindung mit Access findet man nicht sooo viel Ergiebiges im Netz.

markus888

März 13, 2022, 12:41:39 #1 Letzte Bearbeitung: März 13, 2022, 12:48:31 von markus888
Was ist pdo für eine Klasse?
Hast du dich da mit den Properties mal gründlich beschäftigt?

o.k. hab schon gesehen was pdo ist.
Also aus meiner Sicht würde ich mich da eher in einem Forum umsehen, wo pdo genutzt wird.
Die werden da am ehesten Erfahrung damit haben.

Mich wundert es natürlich, dass überhaupt wer für das Web Access verwendet - aber wie auch immer.
Kann dir da aber leider auch keinen vernünftigen Rat geben, außer vielleicht mal mit ADO zu testen.


10 Jahre Access

oliver1974

Ist nicht direkt "draußen" fürs Web, da würde ich das im Traum nicht nehmen.. interne Verwendung/Intranet, und warum da, würde den Rahmen hier sprengen.

Habe auch versucht direkt via odbc_connect(..) und Folgemethoden das anzubinden, aber da muss ich noch schauen ob das sich besser verhält, gefühlt würde ich sagen er baut einfach die Verbindungen nicht ab und irgendwann ist Schicht im Schacht.

PhilS

1. Kontrolliere nochmal ganz genau, dass du auch wirklich alle PDO Objekte (nicht nur die Verbindungen!) schließt bzw. auf Null setzt. - So wie ich die Dokumentation lese, sollte man sich nicht darauf verlassen, dass das schon automatisch passiert.

2. Wenn das nicht hilft, könntest du versuchen eine persistente Verbindung zu verwenden (PDO::ATTR_PERSISTENT => true).
Neue Videoserie: Windows API in VBA

Klassische CommandBars visuell bearbeiten: Access DevTools CommandBar Editor

oliver1974

Zitat von: PhilS am März 13, 2022, 17:00:051. Kontrolliere nochmal ganz genau, dass du auch wirklich alle PDO Objekte (nicht nur die Verbindungen!) schließt bzw. auf Null setzt. - So wie ich die Dokumentation lese, sollte man sich nicht darauf verlassen, dass das schon automatisch passiert.

2. Wenn das nicht hilft, könntest du versuchen eine persistente Verbindung zu verwenden (PDO::ATTR_PERSISTENT => true).

Zu 1.).. ja, habe ich auch schon gelesen, und x fach kontrolliert, ich sehe nix, dass noch eines der davon abhängigen Objekte nicht auf null gesetzt werden würde... ich baue die auch in der (hoffentlich) richtigen Reihenfolge ab.

Gegenwärtig lote ich aus ob die klassische Methode via den ODBC Funktionen besser geht, aber bisher habe ich da noch kein zuverlässiges Ergebnis (da der Fehler ja auch nicht sofort auftritt), aber odbc_close liest sich - was MS Access angeht, schon in den Kommentaren der PHP Dokumentation abenteuerlich..

Zitat:
"`odbc_close()` does not report success and some drivers (namely Microsoft Access) don't seem to close connections at first attempt. This is normally not an issue, unless you need to establish many connections within the script lifetime.

You can use the fact that resource type changes (e.g. from "odbc link" to "Unknown") as a trick to figure out whether connection was successfully closed (and eventually retry):"

<?php
$type 
get_resource_type($conn);
$wait_until time() + 3;
do {
    
odbc_close($conexion_odbc);
} while (
get_resource_type($conn)===$type && time()<$wait_until);

Ich versuche das mal und muss dann mal beobachten (wobei ich glaube er hat da einen Fehler bei "$conexion_odbc" und meinte einfach auch an der Stelle "$conn" ...

Irgendwie muss das eigentlich gehen, PHP und Access ist zwar nicht so gängig, aber man findet immer wieder welche die meinen sie hätten seit Jahren sowas im Einsatz...

Zu 2.) Werde ich auch mal prüfen, meine Optionen sind ja gegenwärtig gering, insofern muss man alles schauen.
Den Grundgedanken hatte ich auch schon dass er an irgendeiner Stelle zu viel Verbindungen aufbaut (wobei das gegenwärtig nach meiner Einschätzung nicht mal im ungünstigsten Falle viel sein kann, aber wer weiß..)


PhilS

Access (ACE/JET) ist nicht ideal als Backend für Webanwendungen.
Wenn auch die Persistente Verbindung nicht weiterhilft, würde ich ,wenn möglich, auf MySQL o.ä. umstellen.
Neue Videoserie: Windows API in VBA

Klassische CommandBars visuell bearbeiten: Access DevTools CommandBar Editor

oliver1974

Zitat von: PhilS am März 14, 2022, 09:29:39Access (ACE/JET) ist nicht ideal als Backend für Webanwendungen.
Wenn auch die Persistente Verbindung nicht weiterhilft, würde ich ,wenn möglich, auf MySQL o.ä. umstellen.

Wie ich schon sagte (glaube ich), dessen bin ich mir sehr bewusst, für "richtige" Webanwendungen würde ich eine JET-Datenbank nicht mit der Kneifzange anfassen. :)

Das hat im vorliegenden Fall halt diverse Gründe... die hier erstmal keine Rolle spielen, aber unter anderem wäre dann sehr viel anderes auch anzupassen.

Gegenwärtig tritt der Fehler nicht mehr auf nach einigen Änderungen, da das eh recht sporadisch war, weiß ich noch nicht wirklich, warum es jetzt zu gehen scheint.. ich benutze konsequent die "alten" odbc_(..) Funktionen von PHP und schließe immer mit odbc_close_all() einfach alles an Verbindungen, was nicht niet- und nagelfest ist... (sofern dass auch entsprechend durchgeführt wird, ist ja alles etwas undurchsichtig), sehr hemdsärmelig, aber angesichts der Tatsache dass die "logischen" und eleganteren Lösungen nicht zu funktionieren scheinen funktioniert das bisher sehr gut...