Office: (Office 2010) Access 2010 SQL

Nichts - ist zur Erklärung der Fehlermeldung hilfreich....

hat mit der Lösung zur eigentlichen Aufgabenstellung dann aber nichts mehr zu tun *wink.gif*

 

Eberhard, schau doch bitte erstmal etwas genauer hin, ehe du eine solche Antwort gibst! *rolleyes.gif*

 

Dem Glauben, dass sich die genannte Fehlermeldung nicht ergibt, wenn man das Feld irgendwie anders füllt, kann ich mich nicht anschließen, weil das einer Regel in einer Tabellendefintion egal ist.

Sorry, da habe ich nur auf diese Aussage geschaut. Sollte man wohl nicht tun.

 

Irgendwie hast Du die Aufgabenstellung nicht verstanden...*rolleyes.gif*

Es soll keines der Primary-Key-Felder gefüllt werden, sondern die leere Spalte Nachname soll mit dem Nachnamen der Tabelle Mitarbeiter anhand der verknüpften Mitarbeiter_ID aktualisiert werden.

Das Feld Nachname hat mit dem Index nichts zu tun

Aber mealin hat es ja umgesetzt (siehe #9)

 

... und ein Index hat mit einer Gültigkeitsregel nichts zu tun, unabhängig von einer Aufgabenstellung oder einer Art des Feldfüllens (Anfügen, Aktualisieren, per Hand einfügen, Hand auflegen o.a.). Ich unterstelle, dass die Meldung in #1 richtig abgeschrieben wurde - was man vielleicht auch nicht darf.

Mit der Aufgabenstellung habe ich mich gar nicht befasst. Klar ist, wenn man etwas anderes macht als ursprünglich, dann treten oft auf diesem Wege gemachte Fehler nicht auf. Eine in einer Tabellendefinition hinterlegte Regel lässt sich aber nicht umgehen. Wenn doch: Da kann man gleich würfeln, aber sich auf nichts mehr verlassen.

 

Unabhängig von der Lösung von mir doch noch ein Input zum Konzept (weil ich vielfach mit Kinderdaten zu tun habe):

Kinder können im Familiennamen anders heißen als ihre Erziehungsberechtigten. *wink.gif*
Geschwister können verschiedene Familiennamen haben.*biggrin.gif*
Die Möglichkeit mehrerer Elterndatensätze ist sinnvoll.*rolleyes.gif* (z.B. wer darf ein Kind abholen...)

 

Hi,

ich vermisse den Einspruch weiterer Mitstreiter gegen dieses Verfahren der doppelten Datenführung.

Es ist wirklich Unsinn, den Mitarbeiternamen in der Kind-Tabelle zu speichern, dazu noch per Update im Datenfeld "Vorname" (!).
Wenn dieser sich ändert, müsste die Änderung auf die Kind-Tabelle übernommen werden, aber wer denkt da wohl dran?
Dass der Familienname des Kindes sich nicht automatisch mit ändern muss, stehe mal auf einem anderen Blatt.
Ich denke es geht hier vorrangig um die Zuordnung des Kindes zum Mitarbeiter und nicht um die Zuordnung des Nachnamens zum Kind.
Dazu aber reicht die Mitarbeiter-ID völlig aus, für die Ermittlung weiterer Informationen gibt es schließlich Abfragen.

 

Aus meiner Sicht braucht's nur eine Tabelle ID-ElternCode-KindCode.

 

Wenn man das Anliegen verstanden hat, erübrigen sich Diskussionen über richtige Datenmodelle und was man sonst so tut, so sinnvoll sie auch sein mögen.
Etwas üben ist doch etwas anderes als irgendeine DB auf Funktionshöchststand zu bringen.

 

jo, so genau hatte ich mir den SQL-Code in #9 gar nicht angeschaut.*frown.gif*
Die Spalte Nachname ist danach immer noch frei...

Es müsste wohl heißen :

Code:

Nichtsdestrotz hast Du, Anne, natürlich recht mit Deinem Einwand der Mehrfachspeicherung - aber es ist ja nur eine Übung *wink.gif*

 

Okay in die Spalte Vorname zu tun war blöd, da diese nicht mehr atomar ist.
Wie kann ich denn mit Hilfe einer Abfrage eine weiter Spalte erstellen??

Würde dann mit der Update-Abfrage in die leere Spalte alles einfügen!!*wink.gif*

 

Mit Data Definition Language (DDL): SQL ALTER TABLE Statement

 

Dann ist die Spalte doch schon da, oder verstehe ich da was falsch?

 

Ne die gibt es noch nicht, falsch ausgedrück.
Also wenn ich die erstellen will muss ich dann eintippen:

ALTER TABLE "Nachname"
FROM Mitarbeiter

Oder wie, kann mir leider noch nix darunter vorstellen *frown.gif* *frown.gif*

 

okay habs


ALTER TABLE Mitarbeiter
ADD COLUMN Nachname TEXT