Text in settings.php

Hallo,
hier wird gar nichts protokolliert, sondern nur die Zugriffsdaten für die DB gespeichert.
Wenn mit xampp (oder so) arbeitest findest Du die DB-Fehlermeldungen unter xampp/mysql/data/mysql_error.log
In 90 Prozent dieser Ajax-Fehlermeldungen reicht allerdings das PHP-Memorylimit nicht aus. Das kannst Du in der xampp/php/php.ini (dort memory_limit = xxxM) erhöhen.
Gruß
Christian

Danke! Dann klappen wenigstens einige Zugriffe und ich kann davon ausgehen, dass die DB-Verbindugn funktioniert, oder?

Das memory_limit hab ich auf memory_limit = 256M gesetzt (in der php.ini - ist bei mir in /etc/php/apache2/php.ini)

Nützt allerdings alles nichts, bleibt immer beim AJAX HTTP Error stehen. Auf der Fehlerseite nebst diversen warnings
(Notice: Undefined property: stdClass::$disabled in _node_types_build() (line 747 of /var/www/modules/node/node.module).)
die Fehlermeldung
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal.block_custom' doesn't exist: SELECT bid, info FROM {block_custom} ORDER BY info; Array ( ) in block_block_info() (line 208 of /var/www/modules/block/block.module).

Für jegliche Hinweise, wäre ich extrem dankbar...

Gruss

Adriana

1) Hast Du in Deiner D6-Installation Inhaltstypen dabei, die von einem Modul erzeugt wurden?
2) Hast Du Blöcke dabei, die von einem Modul angelegt wurden? Auf alle Fälle deaktivieren, eigene Blöcke eventuell löschen, wenn es kein großer Verlust ist...
Gruß
Christian

Danke, aber mir ist nicht ganz klar wie:

...die Inhaltstypen hab ich mit Hilfe von CKK erstellt, alle nicht-Core Module habe ich deaktiviert

Wie kann ich die Inhaltstypenzusätzlich deaktivieren?

...beim Garland-Theme sind nur die normalen Blöcke (Primary LInks, Navigation, User Login aktiv)- habe jetzt aber trotzdem alle eigenen gelöscht, die Fehlermeldung bleibt aber wie beschrieben.

Gruss

Adriana

CCK ist ja auch nicht-Core. Hast Du das hier alles gemacht: http://drupal.org/node/1144136
Gruß
Christian

ja, deshalb deaktiviert... alles in http://drupal.org/node/1144136 beschriebene kommt ja nach dem Upgrade Prozess- oder verstehe ich das falsch?
und bis dorthin bin ich noch gar nie gekommen...(nur bis zu apply pending updates. Danach kommen die Fehler)

oder darf ich die CKK-Teile, die neu in Core sind vor dem Upgrade nicht deaktivieren?

Gruss

Adriana

Ist schon richtig.
Ich überlege gerade, ob der Update-Prozess vorher richtig durchgelaufen ist, da hattest diverse "AJAX HTTP errors" erwähnt, die auf Speichermangel hinweisen. Kannst Du mal in Deine DB schauen ob die Table "block_custom" da ist oder nicht.
Hast Du mit erhöhtem Speicherlimit von vorne angefangen, oder an der Stelle weitergemacht?
Gruß
Christian

nein, die tabelle gibt es nicht-
nur blocks, blocks_roles
seit der erhöhung des speicherlimits habe ich schon mehrmals den server neu gestartet und alles wieder von vorne angefangen- ist auch aufgeführt, wenn ich die php.ini mit phpinfo() anzeige.

strange... Ich würde den da fragen, wie er es gelöst hat: http://drupal.org/node/1012382
edit:
Ich habe mal kurz in den update-Prozess reingesehen, die block_custom entsteht durch eine Unbennung der alten (D6) 'boxes'-table in Abhängigkeit vom Update des Filter-Moduls, das wiederum abhängig vom User-Modul (roles) ist.
Irgendwo in diesem Bereich könnte das Problem liegen - wenn man jetzt davon ausgeht, das alle Schritte nach Anweisung durchgeführt wurden.

Hallo,

vielen Dank für Deine Nachforschungen. Ich versuche, mit xdebug und netbeans ein bisschen näher dahinter zu kommen, was da los sein könnte...(bisher nicht sehr erfolgreich).

Gruss

ich habs gefunden....
der Code in meinen Settings wa mit ?> abgeschlossen...d.h. die beim update hinzugefügten db-zugriffe wurden nie ausgeführt... ...

:)