So, Vergleiche:
Tabelle "text" bei Dir: utf8_general_ci
Tabelle "text" bei mir: utf8_general_ci
Beiträge von Synonym
-
-
Und, man sieht definitv auch, wo er seine Daten herholt. SQL 1 und 2, also aus "node" und "text".
-
Man sieht auch, dass der die Datenbank "words" vorher abfrägt, ob das Wort schon drinnen ist (SQL 5). Wenn nicht, dann folgt der Insert (SQL 6). Bei 7 fragt er dann die neuen wordids ab um die dann bei 8 in die Wortlisten zu packen.
Genau SQL 6 bringt bei Dir die Fehlermeldung. Wohl auch daher, weil der Select davor sagt, "nee, wort ist nicht drinnen". Und das wohl damit begründet, dass der da irgendwo ein Problem mit dem Zeichensatz hat.
Frage: Die Einstellung $config['Mysqli']['charset'] = 'utf8'; in der config.php hast Du, oder?
-
Das ist ein schöner Mist, wenn man da ständig die DB wechseln muss ...
So, das ganze nun nach gelöschten Daten:
PHP
Alles anzeigensql: SELECT * FROM forumcache WHERE `cacheid` IN ('vb_types.types') sql: SELECT * FROM forumnode AS node WHERE contenttypeid NOT IN (23,29) LIMIT 25,1 sql: SELECT text.previewtext, text.previewimage, text.previewvideo, text.imageheight, text.imagewidth, text.rawtext, text.moderated, text.pagetextimages, text.pagetext, text.htmlstate, text.allowsmilie, text.showsignature, text.attach, text.infraction, text.reportnodeid FROM forumtext AS text WHERE text.nodeid = 40 sql: SELECT * FROM forumcache WHERE `cacheid` IN ('vBAtchmnts_40') SELECT a.*,'a' as suffix FROM forumsearchtowords_a a WHERE a.nodeid = 40 UNION SELECT b.*,'b' as suffix FROM forumsearchtowords_b b WHERE b.nodeid = 40 UNION SELECT c.*,'c' as suffix FROM forumsearchtowords_c c WHERE c.nodeid = 40 UNION SELECT d.*,'d' as suffix FROM forumsearchtowords_d d WHERE d.nodeid = 40 UNION SELECT e.*,'e' as suffix FROM forumsearchtowords_e e WHERE e.nodeid = 40 UNION SELECT f.*,'f' as suffix FROM forumsearchtowords_f f WHERE f.nodeid = 40 UNION SELECT g.*,'g' as suffix FROM forumsearchtowords_g g WHERE g.nodeid = 40 UNION SELECT h.*,'h' as suffix FROM forumsearchtowords_h h WHERE h.nodeid = 40 UNION SELECT i.*,'i' as suffix FROM forumsearchtowords_i i WHERE i.nodeid = 40 UNION SELECT j.*,'j' as suffix FROM forumsearchtowords_j j WHERE j.nodeid = 40 UNION SELECT k.*,'k' as suffix FROM forumsearchtowords_k k WHERE k.nodeid = 40 UNION SELECT l.*,'l' as suffix FROM forumsearchtowords_l l WHERE l.nodeid = 40 UNION SELECT m.*,'m' as suffix FROM forumsearchtowords_m m WHERE m.nodeid = 40 UNION SELECT n.*,'n' as suffix FROM forumsearchtowords_n n WHERE n.nodeid = 40 UNION SELECT o.*,'o' as suffix FROM forumsearchtowords_o o WHERE o.nodeid = 40 UNION SELECT p.*,'p' as suffix FROM forumsearchtowords_p p WHERE p.nodeid = 40 UNION SELECT q.*,'q' as suffix FROM forumsearchtowords_q q WHERE q.nodeid = 40 UNION SELECT r.*,'r' as suffix FROM forumsearchtowords_r r WHERE r.nodeid = 40 UNION SELECT s.*,'s' as suffix FROM forumsearchtowords_s s WHERE s.nodeid = 40 UNION SELECT t.*,'t' as suffix FROM forumsearchtowords_t t WHERE t.nodeid = 40 UNION SELECT u.*,'u' as suffix FROM forumsearchtowords_u u WHERE u.nodeid = 40 UNION SELECT v.*,'v' as suffix FROM forumsearchtowords_v v WHERE v.nodeid = 40 UNION SELECT w.*,'w' as suffix FROM forumsearchtowords_w w WHERE w.nodeid = 40 UNION SELECT x.*,'x' as suffix FROM forumsearchtowords_x x WHERE x.nodeid = 40 UNION SELECT y.*,'y' as suffix FROM forumsearchtowords_y y WHERE y.nodeid = 40 UNION SELECT z.*,'z' as suffix FROM forumsearchtowords_z z WHERE z.nodeid = 40 UNION SELECT other.*,'other' as suffix FROM forumsearchtowords_other other WHERE other.nodeid = 40 /**fetch_indexed_words**/; sql: UPDATE forumnode SET `CRC32`=2283396213 WHERE (`nodeid` = 40) /**node**/ sql: SELECT * FROM forumwords WHERE `word` IN ('hundebürstenhalterung','wort','lang','hundebürsten') sql: INSERT INTO forumwords (`word`) VALUES ('hundebürstenhalterung'),('wort'),('lang'),('hundebürsten') /**words**/ sql: SELECT * FROM forumwords WHERE `word` IN ('hundebürstenhalterung','wort','lang','hundebürsten') sql: INSERT INTO forumsearchtowords_h (`nodeid`,`wordid`,`is_title`,`score`,`position`) VALUES (40,137,1,11951,1),(40,140,0,10000,4) /**searchtowords_h**/ sql: INSERT INTO forumsearchtowords_w (`nodeid`,`wordid`,`is_title`,`score`,`position`) VALUES (40,138,0,10000,2) /**searchtowords_w**/ sql: INSERT INTO forumsearchtowords_l (`nodeid`,`wordid`,`is_title`,`score`,`position`) VALUES (40,139,0,10000,3) /**searchtowords_l**/
Wie man sieht, nun werden die Tabellen benutzte, also die searchtowords und die words. Auch sieht man, dass die Daten richtig kodiert sind. -
Ok, sehe es mir gleich an. Bin gerade an was anderem dran. Nee, auch Suche, aber eher die Frage nach dem wie. Daher hier mal ein paar Querys, die mein System ausspukt.
PHP
Alles anzeigensql: SELECT * FROM forumcache WHERE `cacheid` IN ('vb_types.types') sql: SELECT * FROM forumnode AS node WHERE contenttypeid NOT IN (23,29) LIMIT 3,1 sql: SELECT text.previewtext, text.previewimage, text.previewvideo, text.imageheight, text.imagewidth, text.rawtext, text.moderated, text.pagetextimages, text.pagetext, text.htmlstate, text.allowsmilie, text.showsignature, text.attach, text.infraction, text.reportnodeid FROM forumtext AS text WHERE text.nodeid = 18 sql: SELECT * FROM forumcache WHERE `cacheid` IN ('vBAtchmnts_18') sql: UPDATE forumsession SET `lastactivity`=1396265013,`languageid`=3 WHERE (`sessionhash` = '52dba9396889859aecb92ccf84800bb2') /**session**/ sql: UPDATE forumuser SET `lastactivity`=1396265013 WHERE (`userid` = 1) /**user**/ sql: /** saveDbCache */REPLACE INTO forumcacheevent (cacheid, event) values ('52dba9396889859aecb92ccf84800bb2','perms_changed'), ('52dba9396889859aecb92ccf84800bb2','userChg_1'), ('52dba9396889859aecb92ccf84800bb2','userPerms_1') sql: UPDATE forumsession SET `loggedin`=2 WHERE (`sessionhash` = '52dba9396889859aecb92ccf84800bb2') /**session**/ sql: UPDATE forumuser SET `lastactivity`=1396265013 WHERE (`userid` = 1) /**user**/
Das waren alle Query für den Rebuild des Suchindexes für einen Datensatz. Man sieht hier also eigentlich auch, dass in die Worttabellen nichts geschrieben wurde.Jetzt mache ich das ganze nochmal mit zuvor gelöschten Tabellen.
-
Also ich kann aber schon mal einen Zwischenbericht geben. Hier in der DB hackt es irgendwo. Hundeb(mit ü)rste (will das Wort extra nicht schreiben), sondern katzenbürste, wurde wieder zu "hundebrste". Das Ü wurde also einfach wieder verschluckt. Wenn ich nun richtig liege, dann ist dieses katzendingens dann richtig in der DB. Also richtig sind die Wörter, die beim Posten direkt gesendet werden.
Falsch sind die Dinger, die per Admin-Aufruf neu gebildet werden. Das aber nicht allgemein bei vBulletin, sondern spezifisch hier im Forum. Bei mir sind die alle richtig, wenn die im Post richtig waren.
Aber mal sehen, welche der beiden Tierbürsten dann letztendlich wirklich da ist.
-
Ok, er ist anscheinend ja bei 70.000 von 115.000, geht also doch recht flott. Dachte das dauert Stunden

-
ok, ist gelöscht, ich sehe es. Daten sind alle weg. Nun bitte neu aufbauen lassen. Habe wieder zwei Post mit Kennungen versehen, mal sehen, welche der nun zieht.
-
Bitte Rückmeldung, wenn gelöscht
-
Also, dann lösche den Suchindex jetzt bitte mal. Aber bitte nur löschen, nicht neu erstellen !!!
-
Ach Du heiliger Mist, bei jedem Umlaut eine Fehlermail .... Allerdings kann man nach der Mail nun nicht gehen, denn dort wäre der Umlaut falsch. Fraglich nun, ob der nur in der Mail falsch ist oder versucht wird, falsch abzusetzen, also die Query wirklich so ist.
Frage: Wie lange dauert es denn, bis der Suchindex neu erstellt ist und könnte man das während dem Tag machen? Oder geht da der Server in Schlafmodus?
-
ok, identisch. Dann mal Moment, muss mal das System wechseln und noch mal was nachsehen.
-
Ok, das Post vorher. Connect per mysql oder mysqli, also die Einstellung in der config.php Weil Du schreibst ja auch was in der Fehlerliste von mysqli-Fehler bei der Suche - habe ich auch nicht bei mir.
-
Connectest Du das vb per mysql oder per mysqli, also die Einstellung in der config.php?
-
Bis auf character_set_server und collation_server schaut das gut aus. Gut, also die utf8-Umsetzung von vb haste drinnen.
Nimm die Tablle wieder raus, das geht keinen was an. Die angegeben Werte hätten gereicht

-
hi habe gelöscht und neu erstellt. hundebürste wird jetzt auch nicht gefunden...
was liegt denn vor?
So hast gelöscht und neu erstellt? Seltsam, denn die Datenbank sagt:
"Erzeugt am 24. Mrz 2014 um 09:59" bei der searchtowords
und
"Erzeugt am 24. Mrz 2014 um 09:59" bei der forum_wordsEdit: Sie ganzen searchtowords_xx haben das gleiche Datum
-
So, mal Stück für Stück. Ich habe hier so einiges zusammengeschrieben seit heute Morgen.
Erst mal das, damit das mal klar ist. Gehe mal ins APC -> Wartung -.> Diagnose -> Systeminformationen -> Mysql-Variablen. Und dort dann bitte alles von "character_set_client" bis "collation_server" posten.
-
Alex, wenn Du das schon gemacht hast (explizit gelöscht), erst kürzlich, dann kannst Du es bleiben lassen, dann liegt hier ein anderes Problem vor. Allerdings ein lokales.
Wobei, das war am 24. März
-
So, meine Empfehlung da nun, auch wenn das durchaus aufwändig ist und dauert.... Ist aber nur meine Empfehlung, die Entscheidung musst Du treffen.
1. Im ACP den Suchindex löschen lassen (Link oberhalb dem Formular in der Beschreibung)
2. Löschung bestätigen
3. Suchindex neu erstellenDeine Ängste bezüglich der dann möglicherweise wieder falschen Sonderzeichen kann ich Dir eigentlich nehmen. Nee, nehmen nicht, aber so auch nicht wirklich bestätigen. Die Sonderzeichen im Searchindex sind jetzt schon falsch bzw. fehlen halt einfach. Also kann es nicht falscher werden, nur besser oder genauso falsch.
Die Daten zieht er sich aus der forum_text und dort scheinen die Sonderzeichen richtig zu sein, habe zumindest gestern auf die Schnelle keine falschen gefunden von den üblichen ö, ü, ä und ß.
-
Ja, das musst Du auch. Die archive.php oder auch die archive.sh müssen auf der Console ausgeführt werden und dort eben vorzugsweise per Cron. Hat schon seinen Grund, warum Piwik den Ordner, wo die drinnen liegen, als "cron" bezeichnet hat

Manuell für die URL-Zeile gibt es keinen Request. Wenn Du das benutzerabhängig machen willst, dann nur über das Dashboard selbst, also dass der bei einem Zugriff darauf die Daten archiviert. Das ist aber nicht zu empfehlen. Letztendlich macht das Dashboard dann auch nichts anderes, als den Prozess per curl zu starten und das arbeitet auch im Hintergrund als "Konsolenprozess".
Als direkter Browseraufruf macht das auch nicht viel Sinn, denn das Script gibt nur Logdaten aus, keine sonstigen Inhalte. Auch ist es per Browseraufruf an die /apache2/php.ini gebunden und deren Timeouts sind wesentlich geringer als die von cli. Und drittens würde, selbst wenn die php.ini nicht zum Abbruch führt, der Browser selbst abbrechen und irgendwann sagen "der Server reagiert nicht" oder "Zeitüberschreitung" oder "Netzwerkverbindung zu langsam".