[# eof]

Hallo Zusammen,

vielleicht könnt ihr mir bei einem Problem helfen bei dem ich so nicht mehr weiter komme:

Um die Inkompatibilität meiner typo 4.0.x Installation mit dem installierten HTMLArea RTE (1.3.8) zu meinem Firefox 2.0.0.3 zu beseitigen habe ich eine Patch installiert der auf Basis vom dem typo patch http://bugs.typo3.org/view.php?id=5266 erstellt wurde.

Danach lief der Editor leider immer noch nicht. Dann habe ich eine neuere Version vom HTMLArea RTE runter geladen (1.4.4) und über den Ext Manager installiert. Nach der Installation war auf der Info Seite ne Meldung das die Extension ein Verzeichnis benötigt welches noch nicht existierte. Ich habe den Button geklickt um dieses nachzuholen und ich denke danach hatte ich folgendes Problem:

Wenn ich über das Seitenmodul oder das Listenmodul ein ContentElement editiere wird folgende Warnung geworfen:

Warning: mysql_fetch_assoc(:sad: supplied argument is not a valid MySQL result resource in /home/00000000455/pages/typo3_src/t3lib/class.t3lib_db.php on line 796

augenscheinlich schein alles zu funktionieren, aber ich möchte jetzt auch nicht wer weiß am Inhalt verändern. Um das Problem zu beheben habe ich ein Update auf Typo 4.1.1 gemacht (dies hat die existierende 1.4.4 Extension als Lokal (Local SL) eingetragen.
Diese habe ich wieder gelöscht und dadurch die durch typo 4.1.1 mitinstallierte RTE 1.5.2 wieder als System Ext eingetragen).

Natürlich habe ich auch im Install Tool sämtliche Optionen geprüft und die Datenbank gecheckt.

Hat jemand ne Idee wie ich das Problem lösen kann?

Viele Dank,

# eof

[mstuebner]

Bitte doch mal die Suche mit "supplied argument is not a valid MySQL result resource" füttern.

[# eof]

Hallo,

bevor ich poste gehen in aller Regel mindestens drei Stunden Recherche voraus. Als Tip zu dem Suchstring kriege ich hier auf dem Board, genauso wie bei google den Tip einen Datenbank-Compare durchführen zu lassen und wenn dies fehlschlägt die Extension zu deinstallieren und danach neu zu installieren.

Den Datenbankcompare habe ich mehrfach durchgeführt, (wird ja auch in jedem Fall bei dem erwähnten Typo Update durchgeführt) Die Extension deinstallieren kann ich nicht so einfach, da mit typo3 4.1.1 die RTE 1.5.2 kommt und über das Extension Repository nur die Version 1.4.4 downloadbar ist. Oder empfiehlst du mir den "downgrade"?

Gruß,

# eof

[mstuebner]

Zitat von # eof

Den Datenbankcompare habe ich mehrfach durchgeführt, (wird ja auch in jedem Fall bei dem erwähnten Typo Update durchgeführt) Die Extension deinstallieren kann ich nicht so einfach, da mit typo3 4.1.1 die RTE 1.5.2 kommt und über das Extension Repository nur die Version 1.4.4 downloadbar ist. Oder empfiehlst du mir den "downgrade"?

Was spricht dagegen die 1.5.2 vorher mit einem Klick auf das Diskettensymbol im Ext.-mgr. lokal zu speichern?

[# eof]

Hallo,

Zitat von mstuebner

Was spricht dagegen die 1.5.2 vorher mit einem Klick auf das Diskettensymbol im Ext.-mgr. lokal zu speichern?

Ja, so naheliegend das ich nicht drauf gekommen bin. Allerdings hilft mir das auch nicht:

Ich kann die Extension nicht deinstallieren da es ja eine System Extension ist.

An den Datenbankeinträgen kann es eigentlich nicht liegen. Wenn ich das SQL Backup über den Ext Manager ausführe, die benötigten Tabelle lösche und dann neu erzeugen lasse besteht der Fehler weiterhin.

Wenn ich auf die Information zu der Ext gehe kriege ich eine lange Liste von Dateien nach der Warnung: "A difference between the originally installed version and the current was detected!, Modified Files:"

Dann habe ich die Extension manuell gelöscht (Aus dem sysext Verzeichnis) und mein t3x Backupfile als lokale Extension hochgeladen. Der Fehler bleibt.

Danach habe ich lokale Ext wieder gelöscht und die System Ext wieder hergestellt.

Was mir auch noch aufgefallen ist: Die Warnung wird nur bei Übersetzungen der CEs ausgegeben, nicht bei der Originalsprache. In diesem Zusammenhang ist vielleicht noch relevant das ich mit TemplaVoila FCEs arbeite.

Viele Dank,

# eof

[Edit]
Ich habe gesehen dass das ResultSet in der Klasse class.t3lib_db.php immer an eine Methode debug_check_recordset($res) übergeben wird die Loggininformationen über t3lib_div::sysLog bzw t3lib_div::devLog irgendwo hin schreibt.

Wie komm ich denn an diese Infos dran?
[/Edit]

[mstuebner]

Zitat von # eof

Ich kann die Extension nicht deinstallieren da es ja eine System Extension ist.

Das kann man aber im InstallTool einschalten, und zudem bin ich mir nahezu sicher, dass local Installationen über allen anderen stehen.

Zitat von # eof

An den Datenbankeinträgen kann es eigentlich nicht liegen. Wenn ich das SQL Backup über den Ext Manager ausführe, die benötigten Tabelle lösche und dann neu erzeugen lasse besteht der Fehler weiterhin.

An der DB ALLEINE nicht, aber es gibt diverse TCA files die zur Struktur der DB passen MÜSSEN, es aber nicht tun. Da TYPO3 nicht die DB-Stuktur liest, sondern seine TCA konf. stellt es dann Abweichungen fest und bemängelt diese.

Zitat von # eof

In diesem Zusammenhang ist vielleicht noch relevant das ich mit TemplaVoila FCEs arbeite.

Dann bin ich raus. Was aber an keiner meiner Aussagen was ändert.

[# eof]

Hallo,

Zitat von mstuebner

An der DB ALLEINE nicht, aber es gibt diverse TCA files die zur Struktur der DB passen MÜSSEN, es aber nicht tun. Da TYPO3 nicht die DB-Stuktur liest, sondern seine TCA konf. stellt es dann Abweichungen fest und bemängelt diese.

Nein, hier liegt es alleine daran das der php Funktion sql_fetch_assoc kein valides ResultSet übergeben wird sondern false übergeben wird. Der Fehler wird nicht von typo sondern vom php interpreter geworfen.

Es wäre halt nur gut rauszukriegen wodurch der Fehler verursacht wird bzw welches ungültigte sql diesen verursacht hat. Kann mir denn keiner Sagen wo ich die angesprochenden Logs finde?

btw: wie kann eine Metode auch ein ResultSet oder false zurück geben. Das hat mich bei php schon immer genervt, anstelle dessen sollte php eine Exception werfen mit der man was anfangen kann...

Gruß,

# eof

[mstuebner]

Zitat von # eof

Nein, hier liegt es alleine daran das der php Funktion sql_fetch_assoc kein valides ResultSet übergeben wird sondern false übergeben wird. Der Fehler wird nicht von typo sondern vom php interpreter geworfen.

Das ist richtig, aber woher weiss denn T3 was für Datenfelder existieren? Schau Dir mal TCA.php etc. an.

Zitat von # eof

btw: wie kann eine Metode auch ein ResultSet oder false zurück geben. Das hat mich bei php schon immer genervt, anstelle dessen sollte php eine Exception werfen mit der man was anfangen kann...

Ich kann in einer Funktion zurückgeben was ich will und danach richtet sich dann der Typ. Das ist Vorteil und Fluch.

Exceptions kommen bei OOP ins Spiel und bis v4 wird wohl niemand php als Basis für OOP ansehen wollen.

[# eof]

Zitat von mstuebner

Das ist richtig, aber woher weiss denn T3 was für Datenfelder existieren? Schau Dir mal TCA.php etc. an.

Ja, schon klar, aber mir hilft der Inhalt der tca nicht weiter, außer ich mache einen manuellen Abgleich aller Tabellen, aller Felder. Kann man den nirgendwo den "debug-log" einsehen, falls es so was bei typo gibt?

Zitat von # eof

Ich kann in einer Funktion zurückgeben was ich will und danach richtet sich dann der Typ. Das ist Vorteil und Fluch.

Ich habe bei den nicht typisierten Sprachen noch keine Vorteil erkannt, außer dass man viel schneller dreckigen Code produzieren kann. Wobei ich dies hier natürlich relativieren muss, für php ist typo wirklich sauber gecodet. Das Problem -und das meinte ich eingangs- liegt in der API von php. Diese ist nicht durchdacht, unsauber und inkonsistent.

Exceptions kommen bei OOP ins Spiel und bis v4 wird wohl niemand php als Basis für OOP ansehen wollen.

Selbst durch die Objektorientierung seit php5 wird php nicht zur objektorientierten Sprache und mit Sicherheit nie Basis für Irgendwas was mit OOP zu tun hat.

trotzdem Danke für die Hinweise,

ich schreibs hier kurz hin falls ich noch ne Lösung finden sollte,

Gruß,

# eof

[# eof]

Lösung:

Die Extension static_info_tables musste aktualisiert werden. (Auf jetzige Version 2.0.2)

Eine wirklich tolle Extension ist CCDevLog. Hiermit kann der von mir gesucht devlog ausgegeben werden. Dies hat mich darauf gebracht das der Fehler in Datei class.tx_rtehtmlarea_base.php entstand wo static_languages.lg_country_iso_2 als Feld mit angegeben wurde. Dieses gab es nicht. Die DB Compare Funktion hatte hier nicht weiter geholfen.

Gruß,

# eof