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.

[torud]

Hallo!

Danke für den Tipp!

Natürlich gibt es in der DB auch Bereiche, die selbst den Admin nichts angehen, aber die bekommt der gar nicht zu sehen. Da mir diese Bereiche bekannt sind, kann ich auch das Handling dafür beeinflussen.

Ich will das Problem nicht herunterspielen, aber es schon so, dass ich denke zu wissen, was ich tue.

Es gibt, wie schon weiter oben erwähnt, die property Required die eigentlich bei einem Feld, welches als Not Null deklariert ist auf True stehen sollte. Ich habe nun extra ein solches Testfeld erzeugt, aber noch kein Erfolgserlebnis erfahren. Vielleicht finde ich den Fehler noch...

[nieurig]

Hallo Tom,
was die einfache Frage für eine Debatte auslöst :-)

Jeder der ein Admin-Tool schreibt, dürfte die Gefahren kennen. Aber ohne Admin-Tools ist das Leben schwerer und die Fehlermöglichkeiten sind trotzdem da. (Wer hindert denn den User, Access direkt zu starten und eine Tabelle oder ein Feld zu löschen?)

Zu Deiner eigentlichen Frage:

Wie Jasucol gesagt hat, hast Du die Möglichkeit die Requiered Eigenschaft des Feldes zu prüfen. Diese ist auch bei Access vorhanden, wenn das Feld mit NOT NULL (im Designer: Eingabe erforderlich) erstellt wurde. Weitere Möglichkeit zur Erstellung von Pflichtfeldern gibt es ja eigentlich auch nicht.

Wenn Du prüfen willst, ob das Feld ein FK Feld ist wird es schwieriger. Entweder versuchst du einfach den Datensatz mit dem aktuellen Wert zu speichern und fängst bei einem falschen FK die Exception ab, oder Du befaßt die mit den Systemtabellen (die gibt es auch in Access). Zumindest beim SQL-Server kann man mit Hilfe dieser Tabellen herausfinden, ob sich ein FK auf ein bestimmtes Feld bezieht.

Frohes Schaffen.
Niels

[torud]

Hallo Leute!

Hier mal mein Code, mit dem ich die DB-Objekte dynamisch erzeuge. Da zu finden ist auch der Code, wo ich die Abfrage mit dem Require mache. Komischerweise ist der NIE auf true, obwohl ich extra zum Testen einige solcher Felder angelegt habe.

Habe ich da einen Fehler im Code???

Delphi-Quellcode:

             for i:=0 to dm.ADODataSet1.FieldCount-1 do
               begin
                 case Dm.ADODataSet1.Fields.Fields[i].DataType of
                   ftString,ftWideString,ftDate,ftDateTime,ftCurrency,ftInteger, ftSmallint, ftFloat,ftWord :
                     begin
                      //label erzeugen
                      Labels:= TLabel.Create(new_ds);
                      Labels.Parent := new_ds;
                      Labels.Left :=10;
                      Labels.Width:=85;
                      Labels.Alignment:=taRightJustify;
                      Labels.Top  := int_gesamt_top + 3;
                      Labels.Caption:=dm.ADODataSet1.FieldList.Strings[i];
                      //dbfeld erzeugen
                      DBEdit:= TDBEdit.Create(new_ds);
                      DBEdit.Parent := new_ds;
                      DBEdit.Left :=100;
                      DBEdit.Top  := int_gesamt_top;

                      //und hier die abfrage, des aktuellen db-feldes
                      if dm.ADODataSet1.Fields.Fields[i].Required=True then
                      begin ShowMessage('not null'); DBEdit.Color:=clRed; end;

                      DBEdit.DataSource:=dm.DataSource1;
                      DBEdit.Name:=dm.ADODataset1.FieldList.Strings[i];
                      DBEdit.DataField:=dm.ADODataset1.FieldList.Strings[i];
                      int_gesamt_top:=int_gesamt_top + 30;
                    end;
                 //usw...

[marabu]

Zitat:

Zitat von marabu

die TField-Komponente importiert die "NOT NULL" Klausel in der Eigenschaft Required.

Dumm ist nur, dass ADO diese Eigenschaft nicht verwendet - das tut nur die BDE. Als nächstes verfällt man dann auf die Idee, die field properties von ADOTable.RecordSet.Fields[index] zu durchforsten. Nicht nötig - habe ich schon gemacht - nicht umsonst, aber dafür ohne Erfolg.

Der einzige mir momentan bekannte Weg führt über die ADO Extension Library. Ich habe dann zuletzt im AfterOpen-Ereignis des ADO-Dataset Code eingebaut, der die Required-Eigenschaft der Fields korrekt initialisiert. Wenn jemand eine komfortablere Lösung kennt, lerne ich gerne dazu.

Grüße vom marabu

[torud]

Zitat:

Zitat von marabu

Der einzige mir momentan bekannte Weg führt über die ADO Extension Library. Ich habe dann zuletzt im AfterOpen-Ereignis des ADO-Dataset Code eingebaut, der die Required-Eigenschaft der Fields korrekt initialisiert. Wenn jemand eine komfortablere Lösung kennt, lerne ich gerne dazu.

Hallo Marabu!

Interessanter Ansatz!

Könntest Du mir mit etwas Code auf die Beine helfen???

[marabu]

Hallo Tom,

hier eine kleine Demo - ich habe mit der Northwind-Datenbank für Access 2000 getestet.

marabu

[torud]

Hallo Marabu!

Vielen Dank für das Extra-Beispiel!
Es läuft zwar bei mir nicht, weil ADOX und TCatalog nicht gefunden wurde, aber ich denke, dass ich mit Hilfe einiger anderer Beispiele, in denen zur Laufzeit ein Catalogobjekt erzeugt wird mir helfen werden, Dein Beispiel umzuzusetzen.

[marabu]

Hallo Tom,

im Projektmenü kannst du die ADOX Typbibiliothek (Microsoft ADO Ext. 2.8 ...) importieren. Dabei solltest du das Präfix ADOX vor die angezeigten Komponenten setzen, damit es zu keinen Namenskonflikten mit der BDE kommt. Aus Table wird dann AdoxTable, ...
Ich speichere die erstellte Unit dann nochmal als ADOX.pas, weil mir der generierte Name ADOX_TLB.pas nicht gefällt. Dann kannst du die Unit ADOX als Komponenten in einem neuen Package oder wo du willst installieren (Menü Komponente).
Danach sollte mein Demo-Code auch bei dir laufen.

marabu

[torud]

Hallo Marabu!

Danke für die Hinweise!

Ich hatte mir die TypeLibary schon importiert und Dein Projekt eigentlich nur dahingehend geändert, dass ich aus Uses Adox - Uses Adox_Tlb gemacht habe und aus TCatalog ein TAdoxCatalog. Die Komponenten sind da und ich kann Sie mir auch auf ein Formular ziehen, aber mit Deinem Projekt funzt es leider nicht.

Aber wie gesagt, ich denke, dass ich es nun hinbekommen werde.