So ich habe den Fehler gefunden und ausgemerzt:
in src/classes/contact/dao/
isys_contact_dao_list_group.class.php - Line: 60
isys_contact_dao_list_organisation.class.php - Line: 82
isys_contact_dao_list_person.class.php - Line: 84
den Wert $l_arrListTitle["tablename__id"] in $l_arrListTitle["id"] ändern.
Löschen, verschieben etc. sollte dann funktionieren
Wäre es möglich diesen Fix zu erklären (wo wurde etwas geändert?)
Da mein System schon stark customized ist, ist ein einfach Update nicht möglich.
Vielen Dank!
ein kleiner Fix für den IE (getestet mit IE 7+8, FF 3), der die Seitengröße korrekt justiert (davor war im IE eine ewig lange Scrollleiste):
src/tools/js/onload.js
Line 91ff: (function fix_height)
L92: var hg = hg = document.documentElement.clientHeight;
L101: $('contentArea').style.height = (hg - 25 - $('top').getHeight()) + 'px';
Falls jemand suchen sollte 
Ihr seid Spitze!
Erspart mir jetzt einiges an Arbeit 
ich hatte bei mir die Objekte neu Importiert und das Problem war behoben.
Weiß jetzt leider auch nicht an was es genau gelegen hatte…
Hello,
hope this is the right "button":
in your config.inc.php file ist one setting "encoding" standard is latin1 you can change this to utf8 or whatever you need.
(Line 92: "encoding" => "latin1",)
Cheers
Gibt es schon einen ungefähren Releasetermin für die nächste Version?
Da es momentan einige Probleme gibt bei der 9.9.2 und ich nur ungern auf einen Nightly-Build (wo die Dinge wohl schon gefixed sind) zurückgreifen möchte, wenn die nächste Stable schon bald kommen sollte. Danke für die Bemühungen
Gibt es hier schon neue Informationen?
Wäre an einer solchen Übersicht auch interessiert.
Habe den Fehler auch, aber ganz egal wo ich den Standort editieren möchte, ich erhalte immer einen Fehler.
Bin jetzt auf eine "4 CPU 8GB RAM Linux"-Maschine umgezogen und habe ein wenig Geschwindigkeitszuwachs (max 10%) bekommen.
Habe jetzt erste Optimierungen am Code vorgenommen und unter anderem folgende Zeile auskommentiert:
src/classes/components/isys_component_list.class.php:422-428
Hier werden HTML-Tags (und JS-Events) um die Werte aus der DB gepuzzelt um diese in der Temp-Tabelle abzulegen, was leider die Datentransfermenge extrem erhöht.
Bei der Anzeige der Tabelle werden die Tags, da diese noch nicht vorhanden sind, eingefügt.
Geschwindigkeitsvorteil: min. 50%
Werde am Montag weiter an Optimierungen arbeiten, vor allem die Geschichte mit dem dtree werde ich mir anschauen.
(kann derzeit keine Workflows erstellen, weil 9000 Objekte zuviel sind für das Script)
Derzeit wird ja der dtree verwendet, dieser wird komplett aufgebaut => wenn der Benutzer nur die Daten unter Standort X sehen möchte, muss auch Standort Y komplett geladen werden.
Habe mich etwas umgeschaut was für Treeviews es noch so gibt und bin auf folgenden gestoßen:
http://webfx.eae.net/dhtml/xloadtree/xloadtree.html
(Apache Licence)
Baut sich dynamisch auf mit Ajax und holt die Daten aus einer XML (die von einem PHP-Skript generiert wird).
als Notiz hier mal ableg
In der Datenbank nachsehen wie die Tabellenspalten von "tempObjList…" heißen.
Wenn dort das "isys_"-Präfix nicht vorhanden ist, könnte dieser "Quickfix" helfen
ich hatte das gleiche Problem, nur das bei mir der Tabellen-Präfix (isys) fehlte, mein Fix:
classes/components/isys_component_list.class.php:143 ff
dort habe ich in meinem Fall "'isys_'.$key." LIKE " eingesetzt.
Wenn bei dir das "isys_" weg muss, dann einfach:
substr($key, 6)." LIKE "
einsetzen
(ist ein quick&dirty fix, aber funktioniert )
Hallo und danke für die schnelle Antwort
Ja, das Pageing war nur ein Bsp.
Ich war nur schockiert, als ich die Menge der Queries gesehen hatte.
Habe vorhin die Zeit gestoppt für ein Standortupdate (da werden wie es ausschaut die ganzen Positionen neu gesetzt): 3:20 Minuten und Logfile mit 7MB (69k Zeilen)
Werde das System spätestens morgen auf eine dedizierte Linux-Maschine migrieren, bin gespannt ob es sich dann verbessert (bin derzeit auf einem Win2k8,2GB RAM, Dual 2,4GHz,IIS und Testsystem mit 2k8,2GB RAM,Apache)
Hallo zusammen,
beschäftige mich nun seit 2 Wochen mit I-Doit und ich muss sagen, es ist wirklich ein hervorragendes System !
Vor allem die Konfigurationsfreiheit und klare Strukturierung gefällt mir.
Da ich auch daran Interesse habe, dass dieses System sich verbessert, habe ich ein paar Anmerkungen:
Ich habe ein größeres Problem mit der Performance der Javascript-Treeview bei der Anzeige nach Standorten. Wenn ich das korrekt gesehen habe, wird der gesamte Tree in JS zusammengepuzzelt, was auch bei ein paar hunder Objekten kein Problem dazustellen scheint. Da ich mittlerweile über 9000 Objekte habe dauert es (egal ob FF, IE, oder Opera) mindestens 20 Sekunden bis der Browser weiterarbeitet (mit dem wohl bekannten "Skript-Abbrechen"-Dialog).
In einigen Fällen ist es sinnvoll den Client per JS rechnen zu lassen, aber in Bereichen wo eine unbekannte Anzahl an Objekten erreicht werden kann, wäre ein serverseitiger Aufbau des Trees von Vorteil (oder das Javascript muss optimiert werden).
Ein weiteres Performanceproblem, welches wohl auch mit der Menge der Daten zusammenhängt, ist die Geschwindigkeit der einzelnen Seiten. Ich habe dazu die Logs aus der Datenbank angeschaut:
Ein Aufruf von "Clients" in der Infrastrukturübersicht erzeugte eine Logdatei mit über 38000 Zeilen, wobei jede ein Query darstellt.
Hier sollte auf jeden Fall etwas getan werden und die Abfragen Optimieren (wenn ich das beim Query-Log-lesen richtig gesehen habe, dann werden für jedes einzelne Objekt mehrere SQL-Abfragen abgesendet (WHERE isys_obj__id='52', WHERE isys_obj__id='53' usw.). Dies könnte mit einem sauberen Pageing behoben werden: "SELECT … FROM ... WHERE isys_obj__isys_obj_type__id=11 LIMIT 0,20" => "SELECT ... FROM ... WHERE isys_obj__isys_obj_type__id=11 LIMIT 20,20".
Leider kam ich selbst noch nicht dazu mich näher mit dem Aufbau und der Programmierung von I-doit auseinanderzusetzen, sonst wäre meine Kritik etwas präziser.
Ich habe auch irgendwo hier im Forum gelesen, dass mit dem nächsten Update auch Performanceoptimierungen zu erwarten sind, ich bin gespannt
Viele Grüße