Posts made by brische

Hallöchen,
wie ich eben selber gesehen habe, habe ich bei meinem Eintrag die Versionsnummer falsch geschrieben.
Es handelt sich hier um die Versionen 1.18.2pro und 1.19pro die ich getestet hatte.

Hallöchen,
die Versionen 1.82pro und 1.9pro haben wohl aktuell ein Problem bei IPv6 Adressen die in dem Werte-Bereich 'e0' bis 'ef' sind.

Festgestellt werden kann dieses wenn man ein Layer3 Netz z.B. mit den folgenden Werten anlegt:

Bereich: '1:1:1:e1:: / 64'

Es wird vor dem Speichern noch der richtige Adressbereich angezeigt:
'1:1:1:e1:0:0:0:0' - '1:1:1:e1:ffff:ffff:ffff:ffff'
Jedoch wenn man speichert wird der Adressbereich um die Einheit 'e1' gekürzt:
Adressbereich 1:1:1:: / 1:1:1:e1:ffff:ffff:ffff:ffff
Dieses sieht man erst wenn man noch mals den Netzbereich anschaut bzw. im linken Menuebaum auf "Netz" klickt.

Mit sonnigen Grüßen
Bernd

Hallöchen Kevin,

vielen Dank für den Hinweis zum Fullindex.
Also ich habe es nun bei uns getestet und kann berichten, dass dies meinen Fehler korrigiert.
Wir werden dies wohl jetzt per Cronjob einmal in der Nacht durch führen.
Bin aber der Meinung, dass das per Cronjob löschen der Tabelle und den Index neu aufbauen lassen, nur ein Workaround sein kann. Der bei ca. 3000 Objekten nur ca. 50 Sekunden dauert.
Aber da die Tabelle eh von I-doit geführt wird, sollten auch die Werte vom System selbst automatisch gelöscht werden.
Genauso könnte man einen weiteren Button Index Neu Aufbauen in der "Verwaltung / Systemtools / Cache - Datenbanken / Datenbank" einführen um solche Fehlerhaften Einträge löschen zu können…

Mit sonnigen Grüßen
Bernd

Hallöchen,

ich habe nun nochmal weiter gegraben…
Als Beispiel das oben genannte Feld Inventarnummer, welches sich in der Tabelle isys_catg_accounting_list und der Spalte isys_catg_accounting_list__inventory_no gespeichert wird, ist nicht als Index-Feld in der MySQL-DB definiert. Daher kann es kein MySQL-Indexierungsproblem sein.

Es sieht eher danach aus, dass eben I-DOIT selber den Index nicht sauber erstellt.
Denn nach dem das Feld gelöscht wird, ist der Wert weiterhin in der Tabelle isys_search_idx enthalten. Wie bereits geschrieben auch ein ReIndex über den Controller löscht es dort nicht.

Bevor ich aber einen TRUNCATE TABLE isys_search_idx; und den Index über den Controller neu aufbauen lasse, würde ich gerne die Meinung der Experten hören

Hallöchen jd,

wie ich bereits geschrieben habe:

Trotz eines search_index reindex per Controller sowie auch durchstarten der mySQL-DB und des Apaches und löschen des Caches auf dem Server wird immer der alte Wert weiterhin gefunden.

Das heißt das geleerte Feld wird nicht neu indexiert trotz des Befehles: $ ./controller -u admin -p admin -i 1 -m search_index reindex
(natürlich Benutzer/kennwort angepasst)
Was auch in eurer Anleitung als Erklärung zu finden ist:

Wortlänge

Eine wichtige Frage lautet, wie lang ein Wort mindestens sein muss, damit es indexiert wird. Häufig steht dieser Wert auf 3 Zeichen. Begriffe wie "PC 01" werden hiermit nicht gefunden. Geeignet wäre die Angabe von 2 oder sogar 1 Zeichen.
innodb_ft_min_token_size = 2 # minimale Zeichenanzahl eines Suchbegriffes

Diese Einstellung könnte dazu führen, dass der Index um ein vielfaches größer wird.
Worttrenner

Um Wörter voneinander zu unterscheiden, werden verschiedene Zeichen als Worttrenner herangezogen (z. B. Leerzeichen, Punkt, Strich). Damit der Begriff "PC-01" gefunden wird, wird dieser in "PC" und "01" aufgeteilt. Hier ist also wieder die Wortlänge entscheidend, ob "PC" und "01" indiziert werden oder nicht.

Das erklärrt auch warum das Sonderzeichen "-" nicht als neuer Wert erkannt wird….Bzw. der Index nicht erstellt wird, weil die Wortlänge dann wohl 0 oder 1 ist. Bisher habe ich mich nicht getraut die Wortlänge zu ändern bzw. zu reduzieren. Da die Reduzierung auf 0 glaube ich erst recht nicht vorteilhaft sein kann. Aber dazu habe ich zu wenig Erfahrung.

Mit sonnigen Grüßen
Bernd

Hallöchen,

vielen Dank für die schnelle Rückmeldung.
Dann bin ich beruhigt, dass nicht wir zu dumm waren das System sauber zu betreiben
Daher warten wir also ab und gehen dann wieder Tee trinken

Mit sonnigen Grüßen
Bernd

Hallöchen,

wir haben folgendes Problem:
Nachem wir in der Kategorie Buchhaltung eines Servers Daten z.B. in Inventarnummer gelöscht haben,
werden diese Werte weiterhin in der Suche gefunden und vorgeschlagen.
Folgt man dann dem Link der Suche wird es aber als Leeres Feld angezeigt.
Genauso wird er auch über den ./controller gefunden.
Trotz eines search_index reindex per Controller sowie auch durchstarten der mySQL-DB und des Apaches und löschen des Caches auf dem Server wird immer der alte Wert weiterhin gefunden.
Erst wenn der Wert mit was anderem als '0' oder '-' oder ' ' (Leerzeichen) überschrieben wird, wird nur noch der neue Wert gefunden.
Das Problem tritt aber auch in den anderen Felder wie z.B. Lieferschein-Nummer auf.
Der Fehler ist bei uns in der Version 1.8.1 PRO sowie auch nach dem Update 1.8.2 PRO reproduzierbar.

Mit sonnigen Grüßen
Bernd