Hi
Lies nochmal die Doku, ich glaub die Funktionalität ist "missverständlich".
Soweit ich das verstanden habe ist das nur für die Planung / Planungskalender. Der CMDB-Status wird aber nicht automatisch umgestellt.

Leo

Hi
Did you check
system settings > Tenantsettings > Unique checks > object title
But I don't know if this is only valid for the Extras > import mechanism or for API as well.

Du you really need global unique titles in your daily processes? Maybe "Unique (per Object type)" is sufficient (but not sure if this triggers the bug or not)

Regards
Leo

Hi
2147483648 ~ 2GB hört sich stark nach einer 32Bit Limitierung an.
Ich denke da kann nur der offizielle Support helfen.

Aus der Erfahrung würde ich Dir auch nicht raten einen kompletten Import zu machen, sondern immer Technologie bezogen (also ein oder mehrere Objekt-Typen zusammengefasst).

Zum einen wirst Du früher oder später unterschiedliche Anforderungen an den Import haben (Software Import, Aktualisierte Kategorien, etc.)

Zum anderen ist aus meiner Erfahrung die Dauer des Imports nicht linear zur Objektanzahl. Bei uns dauerten ~ 6.000 virtueller Server z.B. knapp 6 Stunden. Aufgeteilt in 2x 3.000 virtueller Server dauert jeder import unter 2 Stunden.

Grüße
Leo

Hi
Da würde ich ein Hersteller Ticket öffnen. Evtl. ist etwas an der Struktur kaputt.

Ansonsten
Wenn es wirklich nur ein Objekt Typ ist:
Exportiere die Daten dieses Typs mal nach CSV und schau das in Excel oder Notepad++ an (Show all Symbols). Evtl. findest Du nicht druckbare Zeichen, die i-doit zu diesem Verhalten veranlassen.

Alternativ geht natürlich auch ein anderes Export Format oder direkt in SQL (falls man sich damit auskennt)

Leo

Hi

Über jedes Kommentar einzeln eine Information zu bekommen finde ich etwas viel. Ich würde das mit einem Report lösen und den

• regelmäßig anschauen
• regelmäßig zuschicken lassen (Benachrichtigungen)

Rechte auf Attributebene geht wohl gerade nicht. Muss es das Beschreibungsfeld in Allgemein sein? Wenn nein, würde ich einfach eine benutzerdefinierte Kategorie für diese "nicht IT-Abteilung" machen, die ein Beschreibungsfeld hat. Meiner Erfahrung nach entsteht dann auch ganz schnell der Bedarf, dass die "nicht IT-Abteilung" weitere Felder pflegen will. Die passen da dann auch rein.

Leo

Hi
Zu Deiner ursprünglichen Frage
"Kategorie für jedes Objekt eine Liste mit verknüpften Objekten habe"

Erstelle einen Report, der alle Objekte zeigt, die mit dem fraglichen Objekt verknüpft sind. z.B. mit Bedingungen
Kategorie= Kontaktzuweisung
Attribut: Kontakt = Personengruppe > XYZ
Evtl. noch andere Parameter der Verknüpfung angeben.

An Stelle der hard kodierten "Personengruppe > XYZ" machst Du jetzt
Kontakt = Feldplatzhalter Objekt ID
Also einen dynamischen Report.

Jetzt erstellt Du eine benutzerdefinierte Kategorie, die nur einen Feld "Report" enthält. Dort gibst Du die ID des oben erstellen Reports ein.

Siehe auch die Antwort in https://community.i-doit.com/topic/4419/objekte-von-relationen-in-eigenen-kategorien-anzeigen

Hi
Lies nochmal die Doku, ich glaub die Funktionalität ist "missverständlich".
Soweit ich das verstanden habe ist das nur für die Planung / Planungskalender. Der CMDB-Status wird aber nicht automatisch umgestellt.

Leo

Hi

Depends on the pattern to identify/cluster these 1000 objects. Several solutions:

• Read https://kb.i-doit.com/display/en/Actions+in+Object+Lists and how to start the https://kb.i-doit.com/display/en/List+Editing within a category
• https://kb.i-doit.com/display/en/Mass+Change
• CSV Export > Edit in Excel/CSV > CSV Import
• API

Regards

Hallo

Hintergrund zur Frage:

• Unser Haupt-Datenbankschema ist 115GB groß:
• 56GB für isys_logbook (also knapp 50%) mit 73 Millionen Einträgen. Allein ein count(*) auf Datenbankebene dauert 14 Sekunden
• 36GB für isys_archive_logbook (also knapp 30%).
  Es werden also 80% der Datenbankgröße nur für das Logbuch benötigt. Das hat nicht nur Auswirkungen auf die Suche im Logbuch sondern auch auf die Backup- und ggf. Restore-zeiten.
• Wir nutzen JDisc. Es kommen täglich mehrere 10.000 Einträge hinzu. Diese sind für einige Tage/Wochen relevant. Nach einigen Monaten aber nicht mehr.
• Laut Support gibt es keine offizielle Möglichkeit alte Logbuch Einträge zu löschen.
• Archivierung ist momentan abgestellt, da alte (insb. manuelle) Logbuch Einträge relevant sind und durchsuchbar sein müssen. Die Archivierung bei Bedarf zurückspielen ist aktuell keine Option.

Einen Vorschlag zur Verbesserung der Suche und Filtermöglichkeiten des Logbuchs in der i-doit GUI haben wir schon geöffnet.

Meine Fragen:

1. Hat jemand Erfahrung mit dem Umgang dieser Größenordnung von Logbucheinträgen, die er hier teilen kann?
2. Hat jemand schonmal Logbuch Einträge in der DB gelöscht bzw. verschoben?

Aktuell evaluiere ich gerade die Möglichkeit die Logbuch Einträge in unserem DWH zu speichern, um die Einschränkungen bei der Suche zu umgehen. Dann könnte ich zwar wieder archivieren, die hohe Anzahl von DB Einträgen bleibt aber natürlich bestehen.

Danke für Eure Unterstützung
Leo