Herausfinden, ob ein DB-Feld ein Pflichtfeld ist

[torud]

Hallo Leute!

Ich bin derzeit damit beschäftigt ein kleines CMS zu bauen, welches mit einer ACCESS-DB funktionieren soll, oder besser gesagt schon etwas tut.

Da dies relativ offen ist, weiss ich natürlich nicht, welche Struktur ein späterer User anlegen wird. Der User kann also Tabellen anlegen und darin Felder. Natürlich auch Pflichtfelder. Nun müsste ich bei der späteren Dateneingabe prüfen, ob der User sich daran hält und dieses Pflichtfeld auch befüllt, damits keine Exception wird.

Wie also kann ich herausbekommen, ob ein Feld ein Pflichtfeld ist?

[GuenterS]

Ich kann Dir auf Deine gestellte Frage keine Antwort geben, sondern nur einen Workaround.

Du könntest Dir "Systemtabellen" anlegen in denen du die Struktur, Datentyp, Pflichtfeld oder nicht, Beschriftung und so weiter abspeicherst.

Damit kannst auch Spaltennamen haben die in der Datenbank eigentlich nicht erlaubt wären, die Formulare darf der User bzw. Admin des CMS dann natürlich nicht mehr direkt in der Datenbank anlegen sondern über ein eigenes Tool oder Du baust auch gleich eine Administration/Configuration dazu ein.

[marabu]

Hallo torud,

die TField-Komponente importiert die "NOT NULL" Klausel in der Eigenschaft Required. Vielleicht hilft dir das?

Grüße vom marabu

[Hansa]

Du kannst doch nicht ernsthaft von einem DAU erwarten, daß er weiß was eine Tabelle ist oder ein DB-Feld. Und dann willst Du noch zulassen, daß der da dran macht was er will und im Programm sollen unbekannte Plausibilitäten überprüft werden ? Sorry, das ist zwar hart, aber durch sowas werden genau die Probleme verursacht, die ohne Computer gar nicht aufgetaucht wären. Und haben will die schon mal gar keiner.

Wenn schon, dann mußt Du alle Fälle selber abdecken und Prozeduren einbauen, die auch die Sonderfälle erträglich machen. Eine Änderung der Tabellenstrukturen per User würde ich von Anfang an ausschließen !

Ein Pflichtfeld als solches würde ich beim Abspeichern überprüfen. Falls nicht bestückt : Abspeichern verweigern und fertig.

[GuenterS]

Zitat:

Zitat von Hansa

Du kannst doch nicht ernsthaft von einem DAU erwarten, daß er weiß was eine Tabelle ist oder ein DB-Feld. Und dann willst Du noch zulassen, daß der da dran macht was er will und im Programm sollen unbekannte Plausibilitäten überprüft werden ? Sorry, das ist zwar hart, aber durch sowas werden genau die Probleme verursacht, die ohne Computer gar nicht aufgetaucht wären. Und haben will die schon mal gar keiner.

Wenn schon, dann mußt Du alle Fälle selber abdecken und Prozeduren einbauen, die auch die Sonderfälle erträglich machen. Eine Änderung der Tabellenstrukturen per User würde ich von Anfang an ausschließen !

Ein Pflichtfeld als solches würde ich beim Abspeichern überprüfen. Falls nicht bestückt : Abspeichern verweigern und fertig.

Ich gehe stark davon aus, dass nicht jeder User dazu berechtigt ist, Tabellen für das CMS System anzulegen, das wird typischerweise nur von einer beschränkten Useranzahl gemacht, die aber in der Regel dann wissen was sie tun.

Die normalen "User" des Programs befüllen dann lediglich die Felder der angelegten Tabellen.

Das System das der Threadersteller schreiben möchte, soll anscheinend eine möglichst generische Lösung sein so, dass das Programm dynamisch abhängig von der vorliegenden Tabellenstruktur entsprechende Eingabemasken erzeugt.

So würde ich seinen Post interpretieren. ;)

[Bernhard Geyer]

Zitat:

Zitat von Hansa

Du kannst doch nicht ernsthaft von einem DAU erwarten, daß er weiß was eine Tabelle ist oder ein DB-Feld. Und dann willst Du noch zulassen, daß der da dran macht was er will und im Programm sollen unbekannte Plausibilitäten überprüft werden ? Sorry, das ist zwar hart, aber durch sowas werden genau die Probleme verursacht, die ohne Computer gar nicht aufgetaucht wären. Und haben will die schon mal gar keiner.

Nicht jeder DAU, aber die Administratoren von solch einem System.

Zitat:

Zitat von Hansa

Eine Änderung der Tabellenstrukturen per User würde ich von Anfang an ausschließen !

Jedes größere flexiblere System wird solche Möglichkeiten haben (Entwickle selbst für solch ein flexibles System). Und solange es "nur" einfache Felder sind ohne Primärschlüssel oder Fremdschlüsselcharakter ist diese flexibilität auch gar nicht so kompliziert.

[torud]

Und hier schreibt dann doch mal der Threadersteller etwas zum Vorhaben, um eventuelle Irrtümer zu beseitigen oder Gesagtes zu bestätigen!

Also es wird genau so sein, dass für diese Anwendung 2 Arten von User möglich sind. Einmal der Administrator, welcher die Tabellen und Felder anlegt und dann natürlich die Redakteure, Dateneingeber, usw. Der Admin wird hier natürlich wissen, was er tut und welche Auswirkungen z.B. Pflichtfelder haben.

Die Eingeber können nichts weiter machen, als sich anzumelden und die DB mit Daten zu befüttern.

Der Administrator hat die Aufgabe die Struktur der DB, bzw. der Tabellen so sinnvoll zu gestalten, dass er die Daten später einfach entweder exportieren oder in anderen verschiedenen Formen veröffentlichen kann.

Es ist dann auch so, dass die DB-Felder für die Eingabe dynamisch generiert werden. Soweit bin ich schon. Ich wollte/musste nun aber auch abfangen, dass eben solche Pflichtfelder auch wirklich befüllt werden. Bisher hat es mit dem Required nicht geklappt. Im absoluten Notfall werde ich diese Information auch noch auslagern und dann explizit abarbeiten.

Es ist also so gut wie nichts vorhersehbar in diesem Projekt und muss alles abgefangen werden. bisher war das aber noch kein Problem.

[Catbytes]

Zitat:

Zitat von torud

Und hier schreibt dann doch mal der Threadersteller etwas zum Vorhaben, um eventuelle Irrtümer zu beseitigen oder Gesagtes zu bestätigen!

Also es wird genau so sein, dass für diese Anwendung 2 Arten von User möglich sind. Einmal der Administrator, welcher die Tabellen und Felder anlegt und dann natürlich die Redakteure, Dateneingeber, usw. Der Admin wird hier natürlich wissen, was er tut und welche Auswirkungen z.B. Pflichtfelder haben.

Und wer sagt Dir, daß der Admin weiß, was er tut?

Nennen wir den Admin mal "Chefredakteur" - und nun? Kann genauso ein DAU sein, der halt das Sagen über seine Redakteure hat.

Ich würde dem Admin zwar anbieten Tabellen/Felder anzulegen/ändern, aber nicht auf DBMS-Ebene, sondern auf Programmebene und schließe mich deshalb meinen Vorrednern an. Auf Programmebene kannst Du dann nämlich mitspeichern was Pflichtfelder sind und was nicht (z.B. in einer Extratabelle). Und dann kann auch Deine Programmlogik eingreifen, wenn da mal was nicht stimmt.

[torud]

Zitat:

Zitat von Catbytes

Und wer sagt Dir, daß der Admin weiß, was er tut?

Nennen wir den Admin mal "Chefredakteur" - und nun? Kann genauso ein DAU sein, der halt das Sagen über seine Redakteure hat.

Ich würde dem Admin zwar anbieten Tabellen/Felder anzulegen/ändern, aber nicht auf DBMS-Ebene, sondern auf Programmebene und schließe mich deshalb meinen Vorrednern an. Auf Programmebene kannst Du dann nämlich mitspeichern was Pflichtfelder sind und was nicht (z.B. in einer Extratabelle). Und dann kann auch Deine Programmlogik eingreifen, wenn da mal was nicht stimmt.

Hallo!

Also vielen Dank für Deinen Beitrag. Folgendes entnehme ich den bisherigen Antworten:

1. Die Masse der Vorredner war nicht unbedingt ein Anhänger Hansas (und Deiner Meinung) => sicher subjektive Wahrnehmung!?

2. Die Meisten würden nicht das Feld selbst auslesen und prüfen ob es ein Pflichtfeld ist, sondern diese Information in einer anderen DB/Tabelle ablegen.!?

3. Ich frage mich, wie ich eine Struktur vorgeben soll, wenn dass CMS offen sein soll, somit für eine möglichst grosse Gruppe flexibel nutzbar sein soll. Nehmen wir eben mal nicht nur die Redaktion, sondern auch einen Zoo. Der eine will Artikel schreiben, während der andere seine Tiere eingeben und verwalten will. Da nützt es dem Admin gar nichts wenn ich eine Struktur für eine Redaktion vorbereitet habe. Er müsste sich trotzdem eine eigene und somit neue, respektive mir unbekannte Struktur erstellen. Das ist bisher auch kein Problem. Ich kann die meisten Sachen schon auswerten und umsetzen. Nur mit den Pflichtfeldern hapert es noch.

4. Der Nachteil, zumindest bisher ist natürlich, dass es zur Zeit noch nicht möglich ist Beziehungen zwischen den Tabellen und herzustellen. Das ist ein so komplexes Thema, dass dies vielleicht für ein Update ein Thema wäre.

5. Wer sagt, dass selbst ein unerfahrener Admin, der das System nicht lange kennt, fehlerfrei bedienen kann? Ich! Und warum? Weil ich es mit Assistenten versehe und eben genauso konstruieren will, dass keine Fehler möglich sind. Bin ich ein Hochstapler oder einfach nur ehrgeizig?

[Jasocul]

Um mal wieder zum Thema zu kommen:
Gibt es wirklich keine Möglichkeit die Information aus Access zu bekommen, ob ein Feld Required ist? Ich habe zwar mit Access noch nicht gearbeitet, aber das kann ich nicht wirklich glauben.
Gibt es in Access denn keine Systemtabellen, wo man das abfragen kann?

Zu den Anmerkungen der anderen DPler:
Lass bloß niemanden unkontrolliert an deiner DB rumfummeln!
Wenn jemand "versehentlich" an den Strukturen, die du für dein Programm benötigst, etwas ändert, dann hast du ein Problem. Beweise dann mal, dass das kein Programmfehler ist. Außerdem musst du auch noch das Passwort für die DB mitteilen. Wenn ich über die Gefahren nachdenke, wird mir fast schlecht.
Oder was passiert, wenn du etwas auf der DB ändern musst, wovon die Tabellen des Admins abhängen? Wenn der auf der DB direkt arbeiten kann, hast du keine Kontrolle mehr darüber.
Glaube mir, ich weiß wovon ich spreche. Wir haben hier genau die Situation, die du beschreibst. Ich bin dabei der Admin. Mit der Softwareschmiede wird jeder Handschlag abgestimmt und abgesprochen, wenn ich auf die Programm-Tabellen zugreifen muss. Selbst, wenn ich nur einen weiteren Index erstelle, wird das abgesprochen. Die Tests mache ich natürlich auf einem zweiten System. Ich habe natürlich noch abgegrenzte Bereiche für meine eigenen Anwendungen.
Nicht jeder Admin ist ein DB-Admin.