SNMP-Sortierung: mehr Kriterien als nur "Beschreibungsfeld"

Naja die auswahlliste nützt solange nichts weil ja neu gescannt wird und der Eintrag wieder überbügelt wird ggf. wäre es ähnlich der Standort Pflege ja auch möglich dieses manuelle SNMPSystem Typ Zuordnung dann höher zu bewerten und den Eintrag (Feld SNMPType) nicht anzupassen. Thosts Werte sollte ja per default auch her eine nicht snapshotabhängig sein . sind sie auch in der Regel ja nicht.... (ok, es gibt ein paar kleine Ausnahmen) Sorry, ein Trigger ist hier für mich hier eine unschöne Lösung ... Du musst bei der Variante ja den Wert pro neuem System ohen filterbares Beschreibungsfeld per IP oder Systemname nachpflegen. TSQL ! Ich bin der Meinung das es in der GUi gelöst werden muss und kann ;-) Die Möglichkeit den Typ einmalig zu überschreiben bzw. so scansicher zu überschreiben (Feldauswahl auf snmptype) fände ich sinnvoller. Also analog Standort Pflege eines Asset / System , welcher ja auch nicht mehr nach manuellen setzen von Discovery Einstellung oder Zuordnungskriterium verändert wird.

Jepp, ich mach das per Trigger mit Wenn dann sonst aber schön ist das nicht (erstetzt zumindest mal deine Listbox).

Grundsätzlich eine gute Idee auch solche schlecht von Hersteller oder auch manchmal von kundenseite gepflegten Beschreibungsfelder im SNMP type dann doch einsortieren zu können. eigentlich gehört es inhaltlich aber dann doch zu dem Thema: Idee: SNMP Typen erweiterbar :-) (docusnap.com) Die Nutzung der SNMP Type filter mit IPAdresse, oder hostname wäre allerdings dann eine eindeutige direkte Zuordnung des Typs . Dafür ist der generische Konstrukt (Namensfilter für typen) ja nicht gedacht, Besser wäre es wenn eine solcher thosts Eintrag manuell Überschreibbar und somit auswählbar wäre. :-) Es sollte dann in dem Kontext der obigen verlinkten Idee eingebaut werden. so quasi in der Art ... (siehe Bild mit Dropdown Maske) Das funktioniert ja theoretisch gut. :-) und wäre vollkommen ausreichend , aber .... Leider wird der manuell gesetzte Thosts Eintrag des SNMPtypes beim nächsten Scan überschrieben :-( aber das könnte der Hersteller ja ggf. ändern :-)