Daten bearbeiten

Das Menü 1 / Daten stellt das interne Menü zur Bearbeitung aller benutzerdefinierten Tabellen zur Verfügung. Zunächst kann mittels einer vereinfachten Suche eine Tabelle ausgewählt werden. Für diese wird eine Maske erzeugt, wie sie anderen internen Menüs entspricht: Pulldownfelder oder Checkboxen für Detailspalten von Relationen und Ja/Nein-Felder, TextArea-Felder, falls für die Spalte <Höhe des Eingabefeldes> größer 1 gesetzt ist, ansonsten gewöhnliche Textfelder. Diese Maske wird direkt zum Hinzufügen einer neuen Zeile oder zur Suche und anschließenden Bearbeitung einer gefundenen Zeile genutzt.

Der Erstaufruf bietet die folgende Maske zur Suche nach Tabellen:

Suchen

Abbruch

Hilfe

Übersicht  (1/3)
≪ < 1 > ≫
-    Artikel
-    Umsatz
-    Vertreter

Id	↑↓
Tabellenname	↑↓
Owner

Hier sind nur die Tabellen-Id, der Name und der Besitzer der Tabelle mögliche Optionen. Da intern für alle Textfelder Latin1_General_BIN als Sortierung verwendet wird, ist bei Tabellennamen Groß/Kleinschreibung zu beachten. Falls sd-Kunden diese Regelung gewöhnungsbedürftig finden, wird empfohlen, alle Tabellen- und Spaltennamen klein zu schreiben.

Ein Klick auf die Zeile 'Artikel' wechselt zur Ein-Tabellen-Ansicht. Falls Spaltenalias definiert sind, werden diese als Beschriftungstext herangezogen. Hier kann über diese Tabelle gesucht oder sofort eine neue Zeile erzeugt werden:

Übersicht (1/1) ▲
≪ < 1 > ≫
- Artikel

Id	↑↓
Artikel-Name	↑↓
Artikel-Preis	↑↓
Owner
Protokoll

Der Aufwärts-Pfeil neben 'Übersicht' ermöglicht es, wieder zur Liste der Tabellen zurückzukehren. Ferner ist nun das Pulldown-Feld neben dem Button <Abbruch> zugänglich, sofern es mindestens einen View zu dieser Tabelle gibt. <(Standard)> nutzt die gewöhnliche Suche mit der ersten Spalte in der Listenausgabe. Wird ein anderer View gewählt, so ist ein erneutes Suchen notwendig, um die Wahl zu aktivieren. Pro Tabelle und Nutzer wird der zuletzt verwendete Suchview gespeichert. Wechselt ein Nutzer den View und ruft er dieselbe Tabelle einige Tage später erneut auf, so wird sofort dieser View genutzt.

Sind für die Tabelle 'Umsatz' die naheliegenden Verknüpfungen auf die beiden Grundtabellen 'Artikel' und 'Vertreter' definiert und sind dem View 'myUmsatzView' die beiden Spalten 'ArtikelId' sowie 'A_Stueck' zugeordnet, so erzeugt die Suche die folgende Ausgabe:

Übersicht (1/9) ▲
≪ < 1 > ≫
- Umsatz

- Hose (110.50)	35
- Hose (110.50)	5
- Mantel (360.00)	10
- Mantel (360.00)	35
- Oberhemd (39.80)	40
- Oberhemd (39.80)	10
- Oberhemd (44.20)	70
- Oberhemd (44.20)	20
- Oberhemd (44.20)	20

Id	↑↓
Artikel	↑↓
Vertreter	↑↓
Stueckzahl	↑↓
Datum	↑↓
Owner
Protokoll

Die Relation ist hier, wie im Beispiel von Menü 7, als

A_Name + ' (' + Cast(A_Preis as nvarchar(15)) + ')'

deklariert. Sie gibt den Artikelnamen sowie, in Klammern, den in eine Textzeichenfolge konvertierten Artikelpreis aus. Ein View liefert für die Detailspalte einer Relation nicht den unverständlichen Primärschlüssel (hier: 11, 12, 13 oder 22), sondern die Klartext-Version, wie sie sich aus dem 'gezeigten Ausdruck' ergibt. Die Sortierung nach Relationenspalten berücksichtigt ebenfalls die Textdarstellung und sortiert nicht nach den internen Nummern. Bei dieser internen Darstellung wird immer die erste Spalte als Link ausgegeben.

Verwendung von Multilang-Spalten

Die im Menü 2 definierbaren Multilang-Spalten / Länderverzweigungen werden beim Lesen und Bearbeiten über das Menü 1 und bei der Nutzung von Ausgabeseiten berücksichtigt. Hierbei gilt: Zur aktuellen Browsereinstellung wird die möglichst spezifische Nicht-Null-Version ausgeliefert. Ein Bearbeiten schreibt diese Version wieder in die Datenbank zurück. Existiert zwar eine Multilang-Spalte, fehlt jedoch noch der spezielle Datensatz, so wird der übergeordnete Wert ausgeliefert und - beim Speichern - zurückgeschrieben. Beim Speichern eines editierten Datensatzes wird der Inhalt einer Multilang-Spalte also nicht verschoben - weder von der allgemeinen zur speziellen Spalte noch umgekehrt.

Beispiel: Ist zu einer Spalte die Multilang-Version 'en' (englisch) definiert, nutzt der Leser eine Browsereinstellung 'en', 'en-US' oder ähnliches und existiert zum angeforderten Detail-Datensatz ein 'en'-Eintrag, so wird dieser ausgeliefert. Existiert kein Eintrag, bsp. weil noch nicht für alle Zeilen eine Übersetzung eingegeben worden ist, so wird der Grundeintrag zurückgegeben. Bearbeitet der Nutzer den Datensatz und versucht er, ihn zu speichern, so speichert er im ersten Fall bei vorhandener Berechtigung den 'en'-Eintrag, im zweiten Fall den Grundeintrag.

Es ist folglich möglich, bsp. zu allen Zeilen die Grundeinträge deutsch zu erstellen und zu einer Spalte mit einer Multilang-Verzweigung nur wenige Zeilen zu übersetzen. Oder es wird zu einer Spalte eine 'es'-Version (spanisch) sowie einige weitere spezifische Kulturen mit Spanisch als neutraler Kultur erstellt (bsp. es-MX - Mexico und es-CR - Costa Rica). Anschließend werden zu jeder Zeile ein 'es'-Eintrag, jedoch nur zu ausgewählten Zeilen wenige der spezifischen Einträge erzeugt. Damit lesen jene spanischen Leser, für welche sowohl eine Spalte als auch ein Eintrag zur angeforderten Zeile existiert, diesen Wert. Für alle anderen Zeilen bekommen sie, ebenso wie andere spanische Leser, den spanischen Grundwert. Weitere Leser nutzen die deutsche Version.

Bei der erstmaligen Eingabe eines Datensatzes hängt es von der verwendeten Browsereinstellung ab, welcher Eintrag für eine Spalte mit einer Multilang-Verzweigung erstellt wird. Ist für eine Spalte implizit 'de' als Haupteintrag sowie zusätzlich 'en' definiert und wird 'en', 'en-US' usw. als Browsereinstellung genutzt, so erzeugt die Erstellung eines neuen Datensatzes einen Eintrag in der 'en'-Verzweigung. Der Haupteintrag bleibt leer. Diese Konzeption wurde gewählt, um bei der Erstellung neuer Datensätze durch verschiedene Personen (deutsche oder englische Muttersprachler) nicht immer zunächst zwangsweise alle Datensätze mit der Sprache des Haupteintrages (hier: deutsch vom Engländer) erstellen zu müssen und die Multilang-Verzweigung anschließend zu ergänzen. Stattdessen können verschiedensprachige Personen Daten eingeben, ergänzen die sonstigen Felder und arbeiten die von der anderen Person neu eingegebenen Zeilen im Menü 2 nach.

Ferner ist zu beachten, daß die 'Grundsprache', die Sprache für die Haupteinträge, nirgends im System definiert werden kann und nicht definiert werden muß. Bei der Bearbeitung einer Leseanforderung wird geprüft, ob es zur vom Nutzer übergebenen Sprache spezielle Spalten gibt. Falls ja, werden diese ausgeliefert. Falls nein, wird der Hauptwert verwendet. Es steht jedem sd-Kunden frei bzw. es kann für jede Tabelle individuell gehandhabt werden, welche Sprache für die Haupteinträge verwendet wird.

Sicherheit

Für die Erstellung neuer Zeilen ist das Add-Recht für den Objekttyp 'Tabellenzeilen' notwendig, entweder speziell für die aktuelle Tabelle oder global. 'Read' gestattet das Lesen aller Zeilen, 'read own Object' erlaubt nur das Lesen der selbst erstellten Zeilen. Bei 'read own Object' liefert die Standardsuche per View nur die eigenen Zeilen aus. 'manage own Object' umfaßt standardmäßig die drei einzelnen 'ownObject'-Rechte. Dieses Recht ist hier jedoch nicht mit einem Verwaltungsrecht verbunden, da für Zeilen keine eigenen Berechtigungssätze erstellt werden können. Das Execute-Recht bleibt unberücksichtigt.

'Read' bedeutet hier allerdings immer das zusätzliche Lesen einer Multilang-Version für die aktuelle Zeile. Der ausgegebene Inhalt ist - bei entsprechend vielen Multilang-Spalten - von der Browsereinstellung des Lesers abhängig. Es würde dem Sinn von Multilang-Spalten widersprechen, wenn hierfür eine eigene Berechtigung notwendig wäre und konfiguriert werden müßte. Der Hauptzweck von Multilang-Spalten besteht darin, unterschiedlichen Lesern automatisiert die möglichst korrekte Version auszuliefern. Das im Menü 16 mögliche Leserecht für Multilang-Spalten bedeutet, die gesonderten Masken für Multilang-Spalten im Menü 2 nutzen zu können. Die Berechtigung wird jedoch beim Schreiben für jede Multilang-Spalte gesondert überprüft. Damit ist es denkbar, einem englischsprachigen Nutzer Leserecht für die Tabelle sowie Editierrecht für alle englischen Multilang-Spalten zu erteilen. Damit kann er die deutschen Texte nicht ändern, die englischen Texte jedoch beliebig im Menü 2 gestalten.

Darf ein Nutzer Hauptzeilen erstellen, fehlt ihm jedoch die Editierberechtigung für englische Spalten und nutzt er einen Browser mit der Einstellung 'en', so wird ihm das Speichern verweigert. Nutzer mit eingeschränkten Rechten können folglich nicht aus Versehen fremdsprachige Einträge ändern. Nutzer mit globalen Rechten müssen bei der Erstellung neuer Einträge mit Multilang-Spalten relativ genau auf ihre Browsereinstellung achten, um nicht versehentlich einen deutschen Grundeintrag aufgrund ihrer 'en'-Browsereinstellung in die en-Multilang-Spalte einzutragen. Allerdings lassen sich solche Fehler aufgrund der spaltenweisen Darstellung im Menü 2 dort leicht korrigieren.

Bei benutzerdefinierten Tabellen gibt es eine Besonderheit in bezug auf den Besitzer der Datenzeile. Administratoren dieser Tabelle können beim Erstellen und Bearbeiten einer Zeile diese Zeile an einen anderen Besitzer übergeben. Über das readOwnObject / editOwnObject - Recht kann der Nutzer später seinen eigenen Datensatz lesen und bearbeiten. Dies ist für Mitgliedsverwaltungen u.ä. interessant: Ein Admin erstellt einen neuen autorisierten Nutzer (mit Nick und Mail) sowie einen neuen Datensatz in der Tabelle mit den Mitgliederdaten. Vor dem Speichern wählt er diesen Nutzer als Besitzer aus. Die Alternative besteht in der Erstellung einer UID-Tabelle. Hier erzeugen sich die Nutzer ihre Datensätze selbst. Versucht ein Nutzer, der nur das gewöhnliche Recht hat, zu dieser Tabelle eine Zeile mit einem anderen Besitzer hinzuzufügen, so erhält er eine Fehlermeldung, die explizit auf diesen Sachverhalt hinweist.

Link zur hiesigen Seite als QR-Code

Kontaktformular:

Schreiben Sie mir und wir bauen gemeinsam Ihre neue Web-Datenbank!

info@sql-und-xml.de - +49(0)30 420 200 60

nach oben

Kontakt-Formular