SchILD ID für Schüler-Export nach WebUntis

[G.Schulte]

Hallo zusammen,

Für die Nutzung des digitalen Klassenbuchs (WebUntis) muss man die Schüler aus SchILD exportieren. In dem Export muss eine eindeutige SchülerID enthalten sein. SchILD liefert dafür zwei Möglichkeiten:

1. GUID, die sieht in der Exportdatei dann z.B. so aus: {C7149433-E857-4B52-9025-B0C6FF7B0576}
2. Interne ID, die ist einfach nur vierstellig: 2546
(3. externe ID ist bei Export leer)

In einer Testversion vor zwei Jahren sagte mir der Herr bei Pedav, ich solle die GUID nehmen. Auf kürzliche telefonische Nachfrage sagte man mir, dass man nicht wisse, welche ID man beim SchILD Export nehmen muss, man verwies mich auf einen kundigen Kollegen bei Pedav. Der antwortete nun das:

"Eine eindeutige ID ist wichtig - ob dies in SchILD die GUID ist, vermag ich nicht zu sagen. Bitte NICHT jene mit den "{}" herum nehmen, sondern die andere. Diese Sonderzeichen machen hinterher Probleme."

GUID ist ja die mit den Klammern, also soll ich die vierstellige interne ID nehmen. Diese soll aber wegen der Kürze auch unweigerlich zu Problemen (irgendwann Doppelungen) führen.

Hat jemand Erfahrungewerte und kann mir einen Rat geben, welche ID man schlussendlich benutzen sollte bzw. welche langfristig problemlos funktioniert?

Vielen Dank im Voraus!

[Pfotenhauer]

Hallo.

Die Schild_ID ist eindeutig, solange man sich in einer DB bewegt.
In Logineo haben wir einen kleinen Trick angewandt, wir haben die SchildID mit der Schulnummer kombiniert z.B. 123456-2345.

Mir wurde mal gesagt, dass dir GUID nicht exportiert werden darf, weil die so eindeutig ist, dass das ein Datenschutzproblem ist.
aber das ist so lange her.... ich weiß gar nicht mehr in welchen Zusammenhang das war.

Ist schon interessant, dass der Weltmarktführer für Stundenplansoftware Probleme mit Sonderzeichen hat...

[G.Schulte]

Ja, ich dachte auch, ich höre nicht richtig und find es richtig nervig, dass die nicht wissen, wie ihr eigenes Programm funktioniert.

Ich kann ja die interne ID nehmen; selbst bei nur vier Stellen gibt es ja genügend Kombinationsmöglichkeiten. Bin ja nur skeptisch, weil es -wie auch immer- zu ID Doppelungen kommen kann. Die Lehrer ID kommt ja aus Untis. Wenn die zufällig vierstellig ist, kann's schon nen Konflikt geben mit nem Schüler.
Vielleicht sollte ich ne Abstimmung starten und mich der Mehrheit anschließen...
Sie würden also die interne ID nehmen tendenziell?

[M. Plümper]

Es kann keine ID-Dopplungen geben, so lange nur Schüler aus einer DB in WebUntis verwendet werden, weil die Schüler-ID pro Schild-DB eindeutig ist.

[G.Schulte]

Vom Grundsatz bin ich da bei Ihnen. Ich habe mich nur verunsichern lassen. Ein Kollege sagt, er habe bei acht Schüler*innen ID Konflikte (weil Doppelung) gehabt.
Danke für die Infos!

[GE Schwerte]

Ich verstehe das Problem nicht.

Die Identifikation eines Schülers erfolgt doch über die Kombination von Name, Vorname und Geburtsdatum.
Hat der Kollege 8 Schüler mit gleichem Namen und Geburtsdatum? Er sollte Lotto spielen.

Ich gehe davon aus, dass wenn Sie WebUntis haben, auch Untis vorhanden ist.

In Untis habe ich doch bereits die Schüler, jeder hat passenden zu seinen Kurswahlen seinen
individuellen Stundenplan und ggf. bei Änderungen den Vertretungsplan.

Die Daten der Schüler (in Untis-Speak: "Studenten") bekommen Sie doch dann einfach per Exportbutton nach WebUntis.

Und weil Untis (und nach dem Export auch WebUntis) weiß, in welchem Kurs der Schüler sitzt,
ist er beim Kollegen auch im Klassenbuch.

Was wollen Sie sich denn mit der ID rumägern?
Die kommt doch auch beim z.B. Import der Umwahlen aus Lupo in Untis gar nicht mit...

[G.Schulte]

Nein, die Schüler sind nicht in Untis. Untis ist schließlich ein Stundenplanprogramm. Wenn Sie mit Untis blocken, weil Sie das Kursmodul benutzen, dann -nur dann haben Sie die Schüler in Untis. Wir blocken mit Kurs42, Schüler kommen also auf keinen Fall in Untis bei uns, schon gar nicht, um sie von da dann nur weiterzuexportieren in WebUntis. Sie haben andere Voraussetzungen, ich muss definitiv aus SchILD exportieren und da war eben die Unsicherheit mit der eindeutigen ID. Da Pedav mir schreibt, dass eine eindeutige ID im Import Datensatz vorhanden sein muss, wird Webuntis vermutlich nur die ID als Marker für den Import und später die Synchronisation benutzen. Macht ja auch Sinn; eine Kombination aus Name, Vorname, Geburtsdatum, Klasse und Geschlecht wäre sonst vermutlich schon eindeutig genug. Da war Pedav aber weder schriftlich noch telefonisch richtig eindeutig.

[wschrewe]

"Bitte NICHT jene mit den "{}" herum nehmen, sondern die andere. Diese Sonderzeichen machen hinterher Probleme."

Das ist nur die String-Repäsentation der eigentlichern GUID, die eine 128-Bit-Ganzzahl ist. Pedav (oder besser G&P) sollte in der Lage sein, so einen String in die GUID zu wandeln. Notfalls könnte man in der mit Delphi mitgelieferten Unit "SysUtils" nachsehen, da gibt es eine Funktion "StringToGUID", die genau das macht (vermutlich findet man das in einer Bibliothek wohl jeder modernen Entwicklungsumgebung) .

[011marTusch]

Es kann keine ID-Dopplungen geben, so lange nur Schüler aus einer DB in WebUntis verwendet werden, weil die Schüler-ID pro Schild-DB eindeutig ist.

Das ist doch der Punkt - Untis bzw. hier WebUntis wird europaweit vertrieben. Die Fa. G&P hostet m.W. die Daten in Österreich - vermutlich in einer mandantenfähigen Datenbank. Da werden eben seeeehr viele Datenbanken abgebildet.

Unklar ist mir an dieser Stelle, wieso es Aufgabe der Kunden sein soll, die sichere Zuordnung der Daten zu gewährleisten. Für den Kunden ist es doch nur interessant, die ausgelagerten Daten mit dem eigenen Datenbestand abzugleichen. Solange auf beiden Seiten nichts verändert wird, reicht da die vierstellige ID. Die Eindeutigkeit jeden Datensatzes zu gewährleisten und jedem Kunden nur die eigenen Daten zu präsentieren ist Aufgabe des Anbieters.

[M. Plümper]

Wenn es mandantenfähig ist, dann bestimmt der Mandant die Daten und nicht der Betreiber. Sonst ist es nicht mandantenfähig.

Und eben für den Datenabgleich innerhalb des Mandaten ist die ID relevant. Für mehr nicht.