Office: (Office 2003) Anfügeabfrage Schlüsselverletzung

Hallo,

ich habe ein Problem mit einer Anfügeabfrage. Access gibt mir immer die Fehlermeldung "1 Schlüsselverletzung" und kann deswegen nichts anfügen.

Tabellen:
tbl_Mitarbeiter

tbl_MitarbeiterAuto

tbl_Auto

Ich weiß das das Feld "AutoWert" bei der INSERT INTO - Anweisung nicht berücksichtigt werden muss. Hier mein SQL Code
Code:

kann mir jemand sagen warum die Schlüsselverletzung entsteht und wie ich es beheben kann?

mfg

:)

 

Hi,

du hast in der Tabelle ein zusammengesetzten Primärschlüssel oder einen eindeutigen Index. Heißt: die Tabelle lässt nicht zu, dass es doppelte Mitarbeiter-Auto-Sätze gibt. Dein fraglicher Satz aber scheint ein solches Duplikat zu erzeugen. Das wird dann abgelehnt. Zu Recht.

Deine SQL ist syntaktisch völlig ok. Diesen Satz würdest du auch manuell nicht anfügen können.

 

Heisst Klartext das ich in der Tabelle "tbl_MitarbeiterAuto" die "MitarbeiterAuto_id" entfernen müsste?

 

... das ist das 2-te Problem: einen Autowert kannst'e nicht hinzufügen, der wird ja vom System veregeben...

 

Hi,

wenn es Duplikate geben darf, dann dürfen die duplikatausmachenden Felder halt nicht gemeinsam Primärschlüssel oder eindeutig indiziert sein.

Ein Autowert ist immer gut: er kostet wenig Platz, macht keinen Wartungsaufwand und ist immer ein Kandidat für den Primärschlüsseljob.

 

Hi,

schau dir die Indizes in der Tabelle an. Kann ein Mitarbeiter mehrere Autos haben? Dann darfst du dem Datenfeld keinen eindeutigen Index geben, der eindeutige Index sollte über beide Datenfelder gehen!

 

In der gezeigten Form ganz sicher nicht. Für die Datenquelle bedarf es zusätzlich VALUES oder SELECT.

Das wird ja auch nicht getan. Hier werden sichtbar Fremdschlüssel in eine Verknüpfungstabelle einer m:n-Beziehung eingetragen. Also müsste darauf geachtet werden,

a) dass die Schlüssel vorher als Primärschlüssel in den Mastertabellen vorhanden sind (Datenherkunft im Formular unklar) und
b) und dass über beide Fremdschlüssel nur ein zusammengesetzter eindeutiger Index angelegt ist.
Einzelne Indizes auf diese beiden Fremdschlüsselfelder benötigst Du nicht, da für ein Fremdschlüsselfeld in einer 1:n-Beziehung mit referentieller Integrität automatisch ein (nicht ohne weiteres sichtbarer) Index angelegt wird.
Ein eigener Einzel-Index auf ein Fremdschlüsselfeld ist da eher schädlich, da er zusätzlich ausgewertet werden muss (Mehrarbeit) und ggf. die Möglichkeit, eigene gewünschte Indizes anzulegen (max. 32 pro Tabelle möglich), stört.

 

...

hast'e Recht, das alte Problem: Wer lesen kann...

 

Ich war auch unsicher. Aber ich habe es in Access 2007 geprüft. Es geht!

Mit dem aus den Fremdschlüsseln zusammengesetzten eindeutigen Index werden Duplikate in der Tabelle verhindert. Das ist aber nur sinnvoll, wenn es auch tatsächlich keine Duplikate dort geben darf. Wenn Duplikate zulässig sein sollen, darf ein solcher Index nicht eingerichtet werden. Für die Nutzung als Zwischentabelle einer m:n-Beziehung ist er jedenfalls nicht zwingend nötig.

 

Hey danke schon einmal für die Antworten!

1.Also es darf keine Duplikate geben. Jetzt meine Frage. Wie bekomme ich mit Access einen zusammengesetzten Fremdschlüssel hin :-\?

2. Die Daten der Formularfelder kommen direkt aus der Tabelle.
Ergo:
Textfeld[=[tbl_Mitarbeiter].Mitarbeiter_id

Gruß

 

Im Tabellenentwurf Ansicht/Indizes, dort ist ein 3spaltiges Fensterchen zu sehen.

Die erste Spalte nennt den Indexnamen. Zu dem Index gehören die Felder (mittlere Spalte) in dieser und den folgenden Zeilen, bis wieder ein neuer Index beginnt (1. Spalte).

Wenn der Cursor in einer Zeile steht, wo der Index beginnt, siehst du im unteren Teil einige Eigenschaften des Index. Da kannst du auch einstellen, ob der Index eindeutig sein soll.

Ein zusammengesetzter Primärschlüssel wirkt übrigens ganz genauso wie ein eindeutiger Index, aber er erzwingt zusätzlich zur Eindeutigkeit auch noch die physische Reihenfolge der Datensätze auf der Platte.

Wenn die Tabelle also Eindeutigkeit in diesen beiden Felder erzwingt, ist ihr völlig wurscht, woher die Daten kommen (Hand, Datei, VBA, ...): was die Eindeutigkeit verletzt, wird verweigert, Ende. Dein fraglicher Satz ist also ein Duplikat und wird daher abgelehnt.

 

Sorry wenn ich das grade nicht verstehe. Ich weiss das es nervig ist, ich rege mich grade selber über mich auf. Irgendwie hats bei mir noch nicht klick gemacht...

Also:
Code:

So sind jetzt meine Einstellungen. Wie gesagt ich weiß das ich das Feld noch einmal von neu aufräume *frown.gif* Ich möchte mich jetzt auch nicht dumm anstellen...

 

Hi,

die Feldeigenschaft "Indiziert", die du hier zitierst, hilft dir da nicht weiter, weil sie nur die Indizes zeigt, die das Feld selbst hat. Es gibt aber auch Indizes, die mehrere Felder umfassen. Die bleiben da unberücksichtigt. Die siehst du nur im erwähnten Fenster Ansicht/Indizes. Machs mal auf, beweg den Cursor durch die Zeilen und schau genau hin.

M.E. ist die Feldeigenschaft Indiziert völlig entbehrlich, da sie über den Indexfenster komplett dargestellt werden kann. Wie wir sehen, kann es sogar irritieren, dass dort bei beiden "Duplikate zulässig" steht, beide gemeinsam aber eben doch keine Duplikate zulassen.

 

So sind meine Einstellungen. Von meiner Logik her ist das richtig, funktioniert aber leider nicht

Access sagt mir das Felder mehrfache Werte enthalten könnte.

 

Acc2000 weigert sich (Gott sei Dank).

Bei Syntaxgeschichten würde ich auf extreme Einsparungen verzichten und mich eher an die vollständige und korrekte Syntax halten, weil gerade hier bei der Fehlertoleranz eine hohe Abhängigkeit vom Softwarehersteller besteht.
Manchmal staunt man ja, was alles so akzeptiert und interpretiert wird. Das "Wissen" darüber steht aber auf wackligen Füßen, undokumentierte Funktionalitäten sind mit Vorsicht zu genießen.

Jeder Wechsel der Version oder ein neues Servicepack oder ein Hotfix bergen die Gefahr, dass die gewohnte Fehlertoleranz bei Anweisungen reduziert wird und damit "überraschend" Fehler auftreten, wo bisher immer alles bestens funktioniert hat.
Die Gefahrenquote und auch der Aufräumaufwand ist dabei ungleich größer als bei der Verwendung von Bezeichnungen, vergleiche Acc2010 - Wann muss man eckige Klammern für ….