Fatal error: Interface 'DatabaseStatementInterface' not found

Debug mal und guck wo es dran liegt? Vielleicht hast du in der htacces was abgelegt das Einfluss auf die DB connection nimmt, und die wurde mit dem update zerschosssen? Oder die settings.php aus Versehen? Oedr ein Fehler in der DB während des updates, so dass es zu corruptions kam?

Hallo,

ich tippe hier darauf dass die prefetch.inc nicht überschreiben wurde wie geplant.
Prüfe mal die Schreibrechte auf das Verzeichnis und im speziellen auf ...\prefetch.inc
diese wurden evtl. nicht überschrieben bei deinem Update.

MfG

Robert

Hallo,
ich kriege gerade keinen Zugriff per FTP-Programm um die Schreibrechte zu prüfen (muss erst einmal den Provider erreichen). Wie ist das mit dem Debug? Wie und wo kann man das den prüfen?

Viele Grüße Jani

Hallo,

ähem, wie möchtest Du denn ohne FTP den update gemacht haben?

MfG

http://de.wikipedia.org/wiki/Debugger

Aber das mit dem ftp sagt mir dass das nicht unbedingt deine Baustelle ist.

Schau erst mal dass Du Zugriff auf Deine Dateien bekommst. Aber ehrlich gesagt kann ich mir da keinen Fehler vorstellen, wenn Du das per ftp Zugriff gemacht hast, da dann die Rechte automatisch vergeben werden. (Ich gehe davon aus dass Du das per ftp Client machst.)

Hallo,

natürlich habe ich ein FTP-Programm und einen FTP-Zugang und als ich das Update ausprobiert habe, ging der auch. Und es war auch nicht das erste Update per FPT (hat vorher immer funktioniert). Nachdem das Update nicht geklappt hat, habe ich natürlich die alte Version wieder raufgeladen. schließlich steht die Seite im Netz und soll auch erreicht werden. Ich habe nur aus noch ungeklärter Ursache gerade keine FTP-Verbindung (für mich auch überraschend).

Gruß Jani

@maen

ich glaube debuggen ist da im Moment kein Tipp.
Das mit dem debugging (vor allen Dingen remote) erfordert schon einiges Know How ;-)
Ich frage mich in diesem Fall, wie man Drupal updated ohne Zugriff auf das Dateisystem
zu haben.
Ich denke mal hier ist irgendwo der Hund begraben.

MfG

Robert

PS: nehmt bitte zur Kenntinis oben, ich glaube und ich denke ;-)

Hi Jani,

also: wenn Du die alte Klasse drübergeschmissen hat und damit alles wieder geht, und Du behauptest die neue Version und die alte seien identisch, dann ist doch alles gut!

Demnach hättest Du ja dann die neue Version von drupal am Laufen.

Wenn dich somit nur interessiert, woran der Fehler lag, dann komme ich wieder auf das Thema debuggen zurück.

Nimm demnach die laufende Version, nimm den file den Du überspielt hast, lade dies auf einen testserver, in vielen Fällen localhost, schmeiss den xdebug in der php ini an, nimm einen Editor mit dem man debuggen kann (kostenlos eclipse oder netbeans), schau Dir eines von 100 tutorials an wie debugging funktioniert, und erzähle uns dann hier abschließend was der Fehler war.

In netbeans oder eclipse kannst Du noch die alte und neue Version des files diffen, um überprüfen zu lassen ob sie wirklich identisch sind.

BG,

Marc

Hi,
also ohne FTP (Dateiupload) gibt es kein update uf dem Server.
Evtl. hat Dein Server FTP abgebrochen und da Du keinen Zugriff
mehr darauf hast kannst Du auch kein Backup mehr aufspielen.
Am besten Du wendest Dich an Deinen Provider wegen dem FTP.
Erst dann kannst Du etwas machen.

@maen
Wie sollte Jani das ganze remote debuggen können ohne administrativem Zugrif die gesamte Infrastruktur auf Router, Switches,Firewall,etc.?
Da es FTP ist gehe ich davon aus dass die Seite remote läuft.

MfG

Robert

Ich hatte doch gesagt dass er erst per FTP wieder ran muss.(Oder ssh, egal!)

Dann auf dem Testserver debuggen!

Ich würde auch nicht auf dem laufenden System debuggen, das legt doch alles lahm!

Drücke ich mich echt so unverständlich aus???

@maen

Nein, normalerweise nicht.
Ich bin schon mehrmals über Deine Kommentare gestolpert und finde
Sie immer sehr passend und konstruktiv.
(Ich bin mir auch sicher, Du kennst Drupal schon länger als ich)

Allerdings, fand ich in diesem Fall (habe auch nichts von lokalem testserver gelesen),
dass jemand der nicht die Dateiberechtigungen prüfen kann,
kaum einen Debugger wie Zend oder Xdebug sinnvoll
einsetzen kann (Lokal oder Remote).
Wenn ein Server Remote nicht läuft kannst Du Ihn auch debuggen (da er sowieso nicht läuft, start auf anderen port und debug).
Lokales Debuggen würde Dir nur (annähernd) mit gleichen OS Parametern(OS,APACHE,PHP,MYSQL,Drupal Module alle Versionen) in einer VM etwas bringen.
Sollte es ein Programmierfehler ausschliesslich in Drupal sein kannst Du es auch mit einen ungleichen lokalen Installation versuchen.

MfG

Robert

...

...

War nur ein Spässle...

1. Robert hat recht, mit dem debuggen bin ich noch überfordert.
2. ich habe sonst den FTP-Zugang zu den Dateien, er ist erst heute abend ausgefallen
3. den Update habe ich schon vor einigen Tagen versucht von Version 7.32 auf 7.33
4. Da die Seite dann nicht mehr lief, habe ich die alte Version (7.32 wieder hochgeladen)
5. ein paar Tage später habe ich es noch einmal versucht, es gab aber die gleiche Fehlermeldung
6. Ich habe lokal nur die beiden prefetch.inc dateien verglichen (aus Version 7.32 und 7.33) und die kamen mir identisch vor.
7. Das heißt noch lange nicht, dass die gesamten Dateien identisch sind und nun die neue Version läuft. Eben nicht! Ich habe ja die alte Version (7.32) wieder ins Netz gestellt, damit die Seiteüberhaupt angezeigt wird. Bekomme nun natürlich laufend die Meldung, dass der Drupal-Kern nicht aktuell ist. Würde das auch gern beheben, aber solange ich den Fehler nicht finde, kann ich kein Update machen. Ich habe also nicht nur ein Erkenntnisinteresse an dem Fehler, sondern ein wirkliches Problem.

Gruß Jani

mach es exakt so wie ich beschrieben habe. Per FTP download inkl. DB auf localhost, xdebug einrichten, editor einrichten, debuggen.

Die Bemerkungen von Robert beziehen sich auf die Schwierigkeit, dies remote als Anfänger durchzuziehen. Debuggen selbst bedarf der Übung, da musst Du durch.

@Marc, nicht jeder kann das ;-)

Aber zurück zum Thread:
Aus der Fehlermeldung würde ich schliessen,
dass die Datei pretech.inc nicht durch das Update
erneuert wurde (egal welcher upload webdav,ft,ssh).
Aus 2. Gründen:
1. Die Dateien sind nach dem Update gleich
2. Laut fehlermeldung eine fehlende Funktion in prefetch.inc

LG

Erst einmal vielen Dank für Eure Anregungen. Ich habe jetzt einmal die prefetch.inc der Version 7.32 und die prefetch.inc der Version 7.33 (jeweils aus dem Original-Download-Verzeichnis) ausgedruckt und verglichen. Die Dateien sind identisch. D.h.an dieser Stelle gab es keine Veränderungen in der neuen Version. Die Datei müsste also funktionieren, auch falls sie nicht neu hochgeladen wurde. Es fehlt keine Funktion an dieser Stelle. Es wurde nur aus irgendeinem Grund irgendwas nicht gefunden.
Das es aber in der Datei ja tatsächlich um die Schnittstelle zur Datenbank geht, scheint doch irgendwas in Zusammenhang mit der Datenbank falsch gelaufen zu sein. Entweder ein Fehler beim Speichern der DB oder irgendwas beim Wiederzugriff (die prefetch.inc wurde ja nur bis Zeile 22 abgearbeitet, dann kam ja schon die Fehlermeldung, die einen weiteren Zugriff auf das ganze System ja nicht mehr zu lies).

Tja, dann muss ich wohl doch, wie von maen vorgeschlagen, alles auf localhost neu einrichten (das wird wohl erst einmal dauern) und dann ein debug versuchen.

Ich nehme mal an, man kann nicht einfach abwarten bis die nächste Version erscheint und hoffen, dass der Fehler dann nicht mehr auftritt?

Kann man denn davon ausgehen, dass sich der Fehler auf localhost simulieren lässt oder ist die Serverumgebung beim Provider evt. auch entscheidend?

Grüße Jani

Es gibt schon eine drupal 7.34 Version.

Aber ich glaube ehrlich nicht dass das daran liegt.

Es ist echt selten dass sich in der PDO was tut, da dann ja auch Schwierigkeiten mit bereits vorhandenen Modulen auftreten könnten. (hook_install, db_query, db_select etc. hängen ja davon ab).

Spiel doch mal spaßeshalber per ftp die neue prefetch über die alte. Da dürfte meiner Meinung nach nichts passieren.

Für mich wahrscheinlicher ist es, dass Du in der .htacess irgendwelche Änderungen gemacht hast (oder settings.php), die nicht berücksichtigt wurden.

Ich habe einmal die alte .htacess drüber gespielt, hat auch nichts genützt. Dann habe ich einmal alles runtergelöscht und die Version 7.34 raufgespielt. Hat nicht geklappt. Nur die Fehlermeldung ist jetzt eine andere, nämlich: 500 - Interner Serverfehler.
Jetzt habe ich erst einmal wieder die Version 7.32 hochgeladen, die läuft.
Worauf kann sich dieser "Interner Serverfehler" beziehen? Kann ich das auf localhost nachvollziehen oder hängt das mit der Serverumgebung des Providers zusammen?

Gruß Jani

Wenn eine nackte 7.34 Installation einen 500-Fehler gibt, liegt das meist an der .htaccess-Datei. Im Anfangsbereich dieser Datei gibt es zwei Zeilen, die mit options beginnen. Manche Provider mögen die nicht also ein '#' als Kommentarzeichen davor setzen. Dann sollte, wenn eine 7.32 läuft, auch eine 7.34 funktionieren. Vielleicht machst Du mal ein Diff auf die beiden .htaccess-Dateien, um die Unterschiede zu sehen.

Dann würde ich beim Support um die error.logs betteln. Oder:

https://www.drupal.org/node/158043

Aber nach der Fehleranalyse wieder raus damit!!!

Hallo Werner,
na ja, ganz „nackt“ war die Installation ja nicht, ich lasse das sites-Verzeichnis ja drauf, weil dort meine Änderungen sind. Ich lösche und installiere ja nur den Rest neu. Ich weiß aber trotzdem nicht, ob und wie die Fehlermeldungen mit den .htaccess-Dateien zusammenhängen können. Denn auch in der alten .htaccess war kein '#' als Kommentarzeichen vor den zwei Zeilen, die mit options beginnen. Ich habe es aber trotzdem probiert. Hat nichts gebracht. Allerdings gibt es auch eine Fehlermeldung, wenn ich versuche die zuvor gesicherten Dateien wieder hochzuladen:
Fatal error: Call to undefined function webform_menu_load() in C:\Inetpub\vhosts\xxx.de\httpdocs\includes\menu.inc on line 593
Und das ist ja genau die .htaccess, die bis zum Upload-Versuch exakt im Netz stand. Und damit geht es dann auch nicht.

Momentan geht gar nichts mehr. Nachdem die gesicherten Daten nicht mehr liefen. Habe ich bis auf den sites-Ordner (der lässt sich auch gar nicht löschen), alles gelöscht und versucht die Version 7.32 aus dem Download-Ordner wieder zu installieren (das hat eigentlich bis jetzt immer geklappt). Aber nun geht nicht einmal das mehr. Statt dessen wird wieder der 500-Interner Serverfehler angezeigt. Das kann doch nicht sein, oder? Nun ist die Seite nicht mehr erreichbar und ich kann gar nichts mehr machen? Nicht einmal sozusagen auf Null setzten?

Gruß Jani

Manchmal (selten) kommt auch ein 500-Fehler, wenn die max_execution_time nicht reicht oder auch das memory_limit. Dazu müßte man aber in den Server-Logfiles nachsehen.
Ich mach ein neu Aufsetzen immer so:

• Alle Dateien (ohne files) auf den Server kopieren
• In sites/default/files die default.settings.php in die settings.php umkopieren (evtl. die alte settings.php sichern)
• Leeres files-Verzeichnis in sites/default anlegen
• Neue Datenbank anlegen
• Seite aufrufen und die Installationsroutine mit der neuen Datenbank durchlaufen.
• Modul Backup&Migrate aktivieren
• Files-Verzeichnis nach sites/default/files kopieren
• Mittels Backup&Migrate den Datenbank-Dump wieder einspielen, den ich mit Backup&Migrate gesichert hatte (sonst für das Einspielen phpMyAdmin verwenden)
• Alle Caches leeren

Danach sollte die Seite wieder da sein.

Hallo, die Seite ist jetzt wieder da, weil der Provider ein backup mit der alten Version machen konnte (läuft jetzt wieder in Version 7.32).

Da ich noch eine Testseite bei einem anderen Provider habe, die noch keine Veränderungen aufweist (bis auf einen Artikel noch die original nackte Drupalversion). Wollte ich hier das Update auf 7.34 ausführen. Hier hatte ich im letzten Jahr schon erfolgreich das Update von 7.32 auf 7.33 durchgeführt. Wollte gucken, ob das Problem der ersten Seite vielleicht irgendwas mit Modulen zu tun hat, die es hier ja noch nicht gibt.

Um Komplikationen wie auf der anderen Seite zu vermeiden habe ich noch einmal die Video-Anleitung zum Drupal-Core-Update aufgerufen und bin Schritt für Schritt vorgegangen: Wartungsmodus, Cache leeren, Datenbank sichern, Dateien für Version 7.34 runterladen, alte Dateien sichern, außer Ordner „sites“ und Verzeichnisse des Providers alle Dateien löschen, neues Dateien (bis auf den Ordner „sites“) hochladen. Nächster Schritt wäre gewesen noch einmal den Statusbericht ansehen. Doch dazu kam es nicht mehr. Der Webauftritt war komplett verschwunden incl. Adminbereich. Keine Fehlermeldung nur eine komplett weiße Website.

Daraufhin habe ich wie von Berthold Lausch in einem thread empfohlen in die index.php die Anweisung zur Fehlerausgabe eingebaut und erhielt dann folgende Fehlermeldung:

Fatal error: Interface 'DatabaseStatementInterface' not found in /xxx.de/httpdocs/includes/database/prefetch.inc on line 22

Das ist ja die gleiche Fehlermeldung wir bei der anderen Website. Was ist denn mit der Version 7.34 los? Anderer Provider gleiche Fehlermeldung? Hat jemand eine Idee?
Viele Grüße Jani

Da ich auch lokal diese Fehlermeldung bekomme, habe ich jetzt doch Xdebug installiert (hat leider alles gedauert). Nun bekomme ich folgende Meldung:

( ! ) Fatal error: Interface 'DatabaseStatementInterface' not found in C:\xampp\htdocs\drupal\drupal\includes\database\prefetch.inc on line 22
Call Stack
# Time Memory Function Location
1 0.0008 333736 {main}( ) ..\index.php:0
2 0.0171 962384 drupal_bootstrap( ) ..\index.php:20
3 0.0486 970880 _drupal_bootstrap_page_cache( ) ..\bootstrap.inc:2252
4 0.0614 1079304 drupal_bootstrap( ) ..\bootstrap.inc:2394
5 0.0614 1079256 _drupal_bootstrap_database( ) ..\bootstrap.inc:2256
6 0.1699 1216192 require_once( 'C:\xampp\htdocs\drupal\drupal\includes\database\database.inc' ) ..\bootstrap.inc:2475
7 0.2153 1324808 include_once( 'C:\xampp\htdocs\drupal\drupal\includes\database\prefetch.inc' ) ..\database.inc:13

Leider bringt mich das auch nicht wirklich weiter, weil ich die Meldungen nicht verstehe. Weiß jemand, was man hieraus ableiten kann?

Viele Grüße Jani

Hast du inzwischen eine LOG-Datei vom Provider bekommen?

Ich bin ziemlich sicher, dass die Funktion fehlt, weil sie nicht mehr geladen wurde, weil es vorher ein out of memory gegeben hat.

Ja, ich schlisse mich Ronald an.
Du hast vermutlich nicht mehr Speicher als 128MB für Deine Site:

Ich vermute der Fehler spielt sich ab wenn 128MB Speicher überschritten werden.

Das Interface DatabaseStatementInterface welches nicht gefunden wird befindet sich in database.inc.
Dieses soll in prefetch.inc geladen werden, dort knallt es.

MfG

Robert

Nein, die Logfiles hatte ich jetzt nicht angefordert. Ich dachte, ich sollte erst einmal den Xdebug ausprobieren?
Dies hatte ich jetzt lokal getestet, auch bei der lokalen Installation tritt der Fehler auf. Muss man da auch von zu wenig Speicherplatz ausgehen? Und da es erst ab Version 7.34 auftritt (7.26 läuft ja), ist den die Version 7.34 so viel umfangreicher als 7.26?

Grüße Jani

dass die LOG-Files im Zugriff sind, und du die Settings in der PHP.ini selbst beeinflussen kannst.

Was steht denn in deiner php.ini unter max_memory?
Was sagt die error.log im php?

500er erzeugen eigentlich immer einen Errorlogeintrag.

Hallo Ronald,
meinst Du diesen Eintrag:

Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
memory_limit = 128M

Die php_error_log sagt mehrfach dies:

[09-Mar-2015 08:58:23] PHP Fatal error: Interface 'DatabaseStatementInterface' not found in C:\xampp\htdocs\drupal\drupal\includes\database\prefetch.inc on line 22 [09-Mar-2015 08:58:23] PHP Stack trace: [09-Mar-2015 08:58:23] PHP 1. {main}() C:\xampp\htdocs\drupal\drupal\index.php:0 [09-Mar-2015 08:58:23] PHP 2. drupal_bootstrap() C:\xampp\htdocs\drupal\drupal\index.php:20 [09-Mar-2015 08:58:23] PHP 3. _drupal_bootstrap_page_cache() C:\xampp\htdocs\drupal\drupal\includes\bootstrap.inc:2252 [09-Mar-2015 08:58:23] PHP 4. drupal_bootstrap() C:\xampp\htdocs\drupal\drupal\includes\bootstrap.inc:2394 [09-Mar-2015 08:58:23] PHP 5. _drupal_bootstrap_database() C:\xampp\htdocs\drupal\drupal\includes\bootstrap.inc:2256 [09-Mar-2015 08:58:23] PHP 6. require_once() C:\xampp\htdocs\drupal\drupal\includes\bootstrap.inc:2475 [09-Mar-2015 08:58:23] PHP 7. include_once() C:\xampp\htdocs\drupal\drupal\includes\database\database.inc:13

Ist das im Prinzip nicht dasselbe, was Xdebug auch gesagt hat?
Gruß Jani

da hst Du ja den Fehler schon.
Wie bereits erwähnt Deine Seite benötigt mehr als 128MB.
Schreib dort mal 256MB ein und starte den Webserver neu.

Und ja, ziemlich sicher benötigt die Seite mehr Speicher als üblich wenn man Sie updatet.
Es kann durchaus sein, dass NACH dem update 128MB Speicher wieder genügen.

MfG

Robert

Ich habe jetzt 256 MB reingeschrieben. Aber wie bekomme ich den Webserver neu gestartet? Startet der neu, wenn ich den PC neu starte? Ich habe nämlich versucht im XAMPP Control Panel beim Apache auf stop zu gehen, aber das hat nichts bewirkt, außer Error: Xampp is alredy running.
Jani

gibt es einen Button "restart" der ist OK.

Allerdings, da es eine Windowskiste ist, gilt sowieso - ein reboot tut immer gut ;-)

Habe jetzt alles neu gestartet, auch den PC, leider hat es wohl nichts gebracht, es erschein wieder genau die gleiche Fehlermeldung. Auch in der Log-Datei.

Gruß Jani

Du hast die php.ini innerhalb des xampp verândert? Danach must Du lediglich im xampp den apachen neu starten, nicht den PC!

Bist Du sicher dass die korrekte php.ini gesetzt ist? Also xampp/php/php.ini?

Ich kann mich daran erinnern dass es da früher verschiedene Stellen gab, ist bei mir aber lange her. Trotzdem schaue noch mal nach.

Um zu sehen ob die anderen 2 recht haben, deaktviere einfach mal ein paar Module. Du kannst sie nachher ja wieder aktivieren, da geht nichts verloren!

Wenn du dann immer noch den Fehler hast, liegt es wahrscheinlich nicht an der config!

Ja, ich habe die php.ini im php-Verzeichnis von Xampp verändert. Ich finde auch keine andere.

Wenn ich wüsste wie, würde ich in xampp auch den apachen neu starten, aber einen Button „restart“ habe ich nicht gefunden und wenn ich im xampp Control Panel stop drücke bekomme ich nur eine error-Meldung.

Wie soll ich denn die Module deaktivieren? Über Drupal-Module? Muss man dazu erst wieder Version 7.26 installieren, dann die Module deaktivieren und dann das update versuchen? Weil die Version 7.34 läßt sich ja über den Browser nicht aufrufen, da habe ich ja dann nur meine Fehlermeldung auf dem Bildschirm.

Jani

Hi Jani,

ruf mal in xampp phpinfo auf.
Dort ssteht der Pfad welchen PHP verwendet, ggf:
php-ini-path="c:\Windows\php.ini" ?

MfG

Geh über den phpmyadmin vom xampp. Dann system Tabelle, dann bei verschiedenen Modulen status auf 0. Nachdem Du einige aud 0 gesetzt hast musst du in die cache_bootstrap Tabelle. Dort die Zeile mit cid="system_list" löschen.

Dann einfach mal F5 drücken im Browser.

Meinst Du den Eintrag:
Configuration File (php.ini) Path C:\windows
oder den
Loaded Configuration File C:\xampp\php\php.ini

Gruß Jani

Hallo Jani,

der Inhalt deises Konfigurations Files sollte geladen worden sein:

Schau auch mal in phpinfo nach memory_limit
Hast Du dort auch 256M drin, was zeigt das an?

LG

Robert

Hallo Robert,

Ja, 256M werden dort angezeigt.

Gruß Jani

Und was steht im Statusbericht unter php-Memory?

Habe die Version 7.26 wieder aufgerufen, dort steht jetzt im Statusbericht auch 256M.

Hallo Jani,

wenn dort 256M steht solltest Du nun auch 256M für PHP haben.
Mach ein Backup (cache leeren,DB exportieren,und Files kopieren) probier jetzt Dein update mal mit 256M.
Einen Versuch ist es Wert.

Sollte es nicht klappen hier ein paar Tipps:

Mir ist aufgefallen, dass der Fehler evtl. doch nicht nur am memory limit liegt, denn:

1324808 = 1.3M das macht keinen Sinn und erwartet hätte ich hier eine solche Meldung:

Versuch mal diese Funktion irgendwo ein zu bauen:
http://php.net/manual/de/function.memory-get-peak-usage.php
mit real_usage, um nicht nur den Speicher des Sktipts zu ermitteln, sondern den gesamten Speicher den das System benötigt zu ermitteln.
echo memory_get_peak_usage (true);

Irgendwie habe ich hier die vermutung, dass der Apache Prozess "out of memory" läuft bevor das PHP-Skript out of memory ist (Es wurden bis dahin ja nur 1.3M geladen)

Viel Glück

In welcher Datei wäre das den sinnvoll? In einer Datei die zu Xampp gehört oder in der Drupal-Version, die neu installiert werden soll? Ich weiß ohnehin nicht so recht, was ich von der Speicherplatztheorie halten soll. Der Fehler tritt ja auch online auf meiner Website auf und ich habe einmal beim Provider in den Statitiken nachgesehen. Dort steht bei bei Disk space: 1,46 GB, davon useed: 2%, also 15,1 MB für Web und 11,0 MB Database. Sollte das nicht eigentlich für das Upload reichen?

Sorry, memory hin oder her! Ich glaube nicht an den Ansatz! Es ist doch irgendwie ein großer Zufall, dass es sowohl auf dem localhost nach dem Umzug als auch auf dem Produktivserver ein memory Problem geben soll.
Und das, obwohl jetzt klar ist dass 256MB vorliegen.
Hast Du jetzt mal den xdebug ausgeführt? Also line 19 (vor Aufruf des Fehlers) in der prefetch.inc einen Haltepunkt gesetzt und dann geschaut wohin der springt? Oder eben nicht springt?

Hi, hast Du update mit 256M schon probiert und es hat nicht geklappt?
Immer noch die gleiche Fehlermeldung?

LG

immer noch die gleiche Fehlermeldung.

die prefetch.inc habe ich noch nicht mit Haltepunkten versehen. Hätte auch nicht gewußt wo. So vertraut mit Eclipse bin ich noch nicht. Ich versuche es einmal

habe die prefetch.inc in Eclipse aufgerufen, den Haltepunkt in Linie 19 gesetzt. Der kleinen Käfer geklickt und Debug as PHP Web Applikation geklickt. Aber passiert ist nichts.

@maen ich dachte das mit xdebug hätte er schon gemacht:

LG

das habe ich angenommen, diese erweiterte Fehlermeldung zeigt er aber auf dem Browser an, nachdem ich in Eclipse Xdebug ausgewählt hatte und Drupal aufgerufen hatte. vorher war im Browser ja immer nur C:\xampp\htdocs\drupal\drupal\includes\database\prefetch.inc on line 22 zu sehen. Von daher nahm ich an, dass der Xdebugger nun gearbeitet hat, aber in Eclipse war da auch nichts zu sehen. Nur wird leider jetzt nichts im Browser angezeigt, wenn ich dort die prefetch.inc aufrufe kommt nur:

Zugriff verweigert!

Der Zugriff auf das angeforderte Objekt ist nicht möglich. Entweder kann es vom Server nicht gelesen werden oder es ist zugriffsgeschützt.

Jani,

in xdebug musst du die Startseite (index.php) Deiner Seite ausführen und nicht prefetch.inc
In prefetch.inc den breakpoint setzen und drupalroot/index.php mit xdebug ausführen !

LG

Du hast also innerhalb einer viertel Stunde gelernt, den xdebug einzurichten und zu nutzen. Hierzu meinen Glückwunsch!

Damit habe ich mich wochenlang beschäftigt, sonst hätte ich mich schon früher wieder wegen des eigentlichen Problems zurück gemeldet. Aber trotzdem habe ich noch so meine Probleme mit dem Debugger. Die Anleitungen sind meist nur sehr allgemein.

ich habe jetzt in Eclipse die index.php aufgrufen, das grüne Käferchen angeklickt, Debug as PHP Application ausgewählt und o.k. gedrückt. In Eclipse ist nichts passiert (sieht man an irgendwas, ob der Debugger überhaupt gelaufen ist?). Dann habe ich im Browser (Firefox) den Pfad: http://localhost/drupal/drupal/index.php aufgrufen. Aber da ist genau die Fehlermeldung, die ich ganz am Anfang schon gepostet habe.

https://www.youtube.com/watch?v=Dm2ivX3uwR4
https://wiki.eclipse.org/Debugging_using_XDebug

LOL, @maen in 15 min. xdebug lernen wäre echt ne Leistung.
@Jani, Rechtsklick auf index.php und Debug as PHP Webpage nicht as PHP Application!

MfG

ich habe aber in der Auswahl nur PHP CLI Application oder PHP Web Application.

Hmm,

PHP Web Application wäre richtig.
Rechtsklick mal auf Dein PHP Projekt and schau unter PHP Debug
nach was dort eingestellt ist.
Speziell bei : PHP Debugger und Server

LG

Beim Rechtsklick finde ich nur Debug as oder run as, PHP Debug steht dort nicht. Meinst Du vielleicht unter Debug as die Debug Configurations?

Sorry,
Rechtsklick auf auf den Projektordner -> Properties -> PHP Debug

LG

du hast in den letzten 2 stunden 5 mal wegen des xdebugs gefragt. Das entspricht alle 24 min eine mail. Es gibt im netz hunderte Anleitungen, ich habe dir vor 1 stunde 2 hier gesendet.

Meiner Meinung nach hast du jetzt 2 Möglichkeiten:

Du gibst das als offiziellen Auftrag heraus, ( für einen Hunderter oder so), dann nehme ich deine DB und deine Daten, knalle es bei mir auf den Testserver, und Du erhältst innerhalb der nächsten 3 - 4 Stunden die Analyse.

ODER:
Du musst wie wir alle am Anfang mal 2-3 Tage kämpfen, die Tutorials und Anleitungen und Videos reinziehen, lernen welche Funktion wohin kommt und warum, wie was debugged wird etc. Das ist halt Handwerkszeug bei uns, Du wirst hier wenige finden wo das anders gelaufen ist. Und das ist anstrengend und dauert länger, sorry.

Also wähle.

Ich habe jetzt unter Windows-Preferences den Eintrag PHP Debug gefunden: da steht:
PHP Server: Default PHP Web Server
Debugger: Zend Debugger

CLI Settings
PHP Executable : None Defined
Debugger: None Defined
Häkchen bei Enable CLI Debug
Encoding Transfer Encoding: UTF-8
Debug Output Encoding UTF-8
Häkchen bei Break at First Line

Unter Properties PHP Debug

Steht dasselbe nur zusätzlich noch:
Default Base URL: http://localhost/drupaltest

Jani,

bei Debugger XDebug einstellen und nicht Zend.
@maen Du hast echt absolut Recht wir posten hier alles zu.
Deshalb @Jani biite lies die Tutorials die er Dir geposted hat.

LG

es ist ja nicht so, dass ich keine Anleitung gelesen hätte. Ich kenne sogar eine von den beiden links und habe auch nach der gearbeitet. Ich habe seitdem im letzten Jahr in diesem Thread vorgeschlagen wurde Xdebug zu benutzen, mich wochenlang damit rumgequält Eclipse, Java und was man sonst noch so braucht zu installieren und halbwegs zu verstehen. Aber bei Eclipse gibt es verwirrend viele Stellen wo man was einstellen kann und ich hatte die Anleitungen bislang so verstanden, dass man unter Debug as Configuration was einstellen muss und das hatte ich auch gemacht. Scheinbar war es nicht die richtige Stelle. Das war mir aber bis eben nicht klar. Es tut mir Leid, ich wollte das Drupal Forum nicht zutexten. Mir wäre ein deutschsprachiges Eclipse-Forum auch lieber, aber ich habe noch keines gefunden.

Danke für dein Angebot, ich muss jetzt erst einmal überlegen, ob es überhaupt Sinn macht, mit Drupal weiter zu arbeiten.

Hyp1, ich hatte eines der 2 Tutorials bereits gelesen, aber wohl doch nicht so gut verstanden. Aber alle Anleitungen haben die Einstellungen immer unter Debug Configurations vorgenommen. Selbst im PDT User Guide wird unter dem Stichwort "Working with the Debugger" die Einstellung unter Debug Configurations vorgenommen. Ich hatte gedacht, die Fehlermeldung die ich im Browser erhalten hatte, wäre aussagekräftig genug, um an dem eigentlichen Problem weiter zu arbeiten. Vielen Dank für Deine Hilfe.

Viele Grüße Jani

Hey,

lass Dich durch Rückschläge nicht entmutigen sondern bleib dran,
dann bist Du auf dem richtigen Weg.
Ich habe damals Monate gebraucht bis ich XDebug am laufen hatte, und musste es am Schluss selber kompilieren(x64).

Viel Glück weiterhin

Liebe Forumnutzer, falls jemand einmal eine ähnliche Fehlermeldung hat, hier die Auflösung: es war weder ein Speicher-, noch ein Zeitlimit-Problem, noch ein Datenbank-Problem. Es waren beschädigte Dateien im Ordner Database (database.inc, query.inc, schema.inc und select.inc). Was immer beim Download der CoreUpdate Version 7.34 schief gegangen ist, diese Dateien waren zu klein und daher vom Inhalt nicht vollständig. Leider tauchte in der Fehlermeldung am Anfang ja immer die prefetch.inc auf. Deshalb hatte ich die auch mit der gleichnamigen Datei aus der Version 7.26 verglichen und keine Abweichungen festgestellt. Erst beim Vergleich mit der Version 7.36 fielen die Abweichungen im Ordner Database auf. Mit der Installation der Version 7.36 sind nun auch die Fehler behoben.

Noch einmal vielen Dank an alle Forumnutzer, die mir so ausdauernd bei der Fehlersuche geholfen haben.

Viele Grüße Jani

P.S. Danke Hyp1 für den letzten Eintrag, bin mittlerweile auch mit Eclipse weiter gekommen!