get_user_data()

Liest einen benutzerbezogenen Datensatz für den aktuell angemeldeten Benutzer über dms.GetUserData. Jeder Eintrag wird durch einen frei wählbaren Namen (maximale Länge 100 Zeichen), einen Typ und die Benutzer-ID identifiziert. Die Benutzer-ID wird vom Server automatisch aus der aktiven Sitzung ermittelt.

1. Signatur

  • Sync

  • Async

ecm.system.get_user_data(
    name: str,
    data_type: ECMUserDataType | int,
    *,
    as_string: bool = False,
) -> bytes | str | None
await ecm.system.get_user_data(
    name: str,
    data_type: ECMUserDataType | int,
    *,
    as_string: bool = False,
) -> bytes | str | None

2. Parameter

Parameter Typ Standard Beschreibung

name

str

—

Bezeichner des Datensatzes (max. 100 Zeichen).

data_type

ECMUserDataType | int

—

Typkennung. ECMUserDataType enthält die dokumentierten Standard-Typen (z. B. STORED_QUERIES, EXTERNAL_PROGRAMS, AS_INI, ADDITIONAL_APP_CONFIG_80…85). Eigene registrierte Typen können als int übergeben werden.

as_string

bool

False

Steuert die Server-Rückgabe (OutputUnicode). Bei True liefert der Server einen String, bei False rohe bytes. Siehe Hinweis unten.

3. Rückgabewert

  • bytes — wenn as_string=False (Standard) und der Eintrag existiert.

  • str  — wenn as_string=True und der Eintrag existiert.

  • None  — wenn kein Eintrag mit dem angegebenen Namen und Typ existiert.

4. Wichtiger Hinweis: Unicode-Server und text-typisierte Einträge

Auf modernen Unicode-Servern weist dms.GetUserData text-typisierte Einträge ab, wenn sie ohne OutputUnicode=1 angefragt werden. Das Server-Protokoll liefert dann den Fehler:

Under Unicode systems the job 'GetUserData' is not allowed anymore for text values, use the job 'GetUserDataAsString' for text values instead

Praktische Konsequenz:

  • Für binäre Datentypen (z. B. ADDITIONAL_APP_CONFIG_80…85, benutzerdefinierte BLOB-Slots): as_string=False (Standard) verwenden.

  • Für textuelle Datentypen (z. B. STORED_QUERIES, AS_INI, EXTERNAL_PROGRAMS): as_string=True verwenden, sonst lehnt der Server die Anfrage ab.

Welche Typen text- oder binär-flagged sind, entscheidet die Server-Konfiguration und kann sich zwischen Installationen unterscheiden.

5. Beispiele

5.1. Binäre Daten lesen

  • Sync

  • Async

from ecmind_blue_client.ecm import ECMUserDataType

value = ecm.system.get_user_data(
    "my_settings",
    ECMUserDataType.ADDITIONAL_APP_CONFIG_80,
)
if value is None:
    print("Eintrag existiert nicht")
else:
    print(f"{len(value)} Bytes gelesen")
from ecmind_blue_client.ecm import ECMUserDataType

value = await ecm.system.get_user_data(
    "my_settings",
    ECMUserDataType.ADDITIONAL_APP_CONFIG_80,
)

5.2. Text-Daten lesen

  • Sync

  • Async

from ecmind_blue_client.ecm import ECMUserDataType

config = ecm.system.get_user_data(
    "my_query_name",
    ECMUserDataType.STORED_QUERIES,
    as_string=True,
)
from ecmind_blue_client.ecm import ECMUserDataType

config = await ecm.system.get_user_data(
    "my_query_name",
    ECMUserDataType.STORED_QUERIES,
    as_string=True,
)

5.3. Existenz prüfen ohne den Wert zu verarbeiten

Da None für „nicht vorhanden" steht, reicht ein einfaches is not None:

if ecm.system.get_user_data("foo", ECMUserDataType.ADDITIONAL_APP_CONFIG_80) is not None:
    print("Eintrag existiert")

6. Siehe auch

  • dms.SetUserData — Wert speichern (noch nicht in der Python-API)

  • dms.DeleteUserData — Wert löschen (noch nicht in der Python-API)

  • dms.GetUserDataAsString — spezialisierte Variante nur für Strings (noch nicht in der Python-API)

  • dms.GetUserDataNames — alle Namen für einen Typ auflisten (noch nicht in der Python-API)