Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!

Mobiles Hauptmenü

Anfügeabfrage ohne Duplikate

Begonnen von Samurai2_de, April 24, 2016, 19:47:21

⏪ vorheriges - nächstes ⏩

Samurai2_de

Hallo ihr Wissenden!

Bei einem meiner Datenbankentwürfe bin ich auf ein neues Problem gestoßen:
Die Datenbank verfügt u.a. über die Tabellen "tbl_Ausbilder", "tbl_Azubis" und "tbl_PersGesamt". In der Tabelle "tbl_PersGesamt" soll per Anfügeabfrage automatisch ein Datensatz erzeugt werden, sobald in der "tbl_Ausbilder" oder "tbl_Azubis" ein neuer Datensatz erzeugt wird. Die Anfügeabfrage hierzu habe ich an den Button zum Speichern des aktuellen Datensatzes im Formular der "tbl_Ausbilder" bzw. "tbl_Azubis" gebunden.
In der Tabelle "tbl_PersGesamt" muss der Primärschlüssel des Datensatzes aus "tbl_Ausbilder" bzw. "tbl_Azubis" als Fremd-Schlüssel zur weiteren Verwendung mitgespeichert werden. Hierzu wurde das Feld "FremdID" ind der "tbl_PersGesamt" angelegt. So weit, so gut, das Problem kommt nun:
Es sollen natürlich beim Ausführen der Anfügeabfrage nur neue Datensätze der Tabellen Ausbilder oder Azubis übertragen werden und keine Duplikate angelegt werden.
Der SQL-Code meiner Anfügeabfrage lautet zur Zeit:
INSERT INTO tbl_PersGesamt ( FremdID, Nachname, Vorname, Benutzername, Passwort, UserLevel )
SELECT tbl_Ausbilder.ID, tbl_Ausbilder.Nachname, tbl_Ausbilder.Vorname, tbl_Ausbilder.Benutzername, tbl_Ausbilder.Passwort, tbl_Ausbilder.UserLevel
FROM tbl_Ausbilder
WHERE tbl_Ausbilder.ID not in (SELECT FremdID from tbl_PersGesamt);

Dieser Code funktioniert solange, bis ein Datensatz z.B. aus der Tabelle Azubis angelegt werden soll, der die gleiche ID hat, wie ein Datensatz der Tabelle Ausbilder, der in der Tabelle PersGesamt bereits existiert.
Ich habe testweise auch schon die WHERE-Klausel weggelassen und aus dem SELECT einen SELECT DISTINCT und SELECT DISTINCTROW gemacht, Beispiel:
INSERT INTO tbl_PersGesamt ( FremdID, Nachname, Vorname, Benutzername, Passwort, UserLevel )
SELECT DISTINCT tbl_Ausbilder.ID, tbl_Ausbilder.Nachname, tbl_Ausbilder.Vorname, tbl_Ausbilder.Benutzername, tbl_Ausbilder.Passwort, tbl_Ausbilder.UserLevel
FROM tbl_Ausbilder;

Leider brachte dies keine Besserung.

Daher nun meine Frage, ob ihr eine Idee habt, wie ich diese Anfrage realisieren kann.

Für eure Hilfe wäre ich euch wieder sehr dankbar!

Mit freundlichem Gruß

Samurai2_de
"Vegetarier" ist das indianische Wort für "zu doof zum jagen"!

Ein Tag ohne Lachen ist ein verschenkter Tag!

DF6GL

Hallo,

die Idee wäre, diese ganze Einfügerei wegzulassen und nur die tbl_PersGesamt  (--> tbl_Personen) zu führen..

D. H. die Normalisierungsregeln anzuwenden.

Die Unterscheidung, ob Ausbilder oder Azubi  geschieht dann über ein zusätzliches Statusfeld.


Ich empfehle nicht die Lösung, einen eindeutigen Index über diejenigen Tabellenfelder zu legen, die eine Person eindeutig identifizieren...
Viele Grüße vom Bodensee
Franz, DF6GL

Hilfestellung:  http://www.access-o-mania.de/forum/index.php?topic=6969.msg118738#msg118738

Links und Tipps:
1.   http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/
1a. http://www.tinohempel.de/info/info/datenbank/normalisierung.htm
1b. https://support.office.com/de-de/article/Grundlagen-des-Datenbankentwurfs-eb2159cf-1e30-401a-8084-bd4f9c9ca1f5#bmterms
2.   http://www.donkarl.com
3.   https://web.archive.org/web/20201201233522/http://www.dbwiki.net/
4.   http://www.access-tutorial.de/
5.   http://www.tty1.net/smart-questions_de.htm
6.   http://access.joposol.com/accept

Last but not least:   < F1 > für Hilfe
;) Learning by doing not by spoon-feed ;)

Tipp: Find and Replace for Access

Samurai2_de

Deine Lösung macht absolut Sinn, soweit hatte ich gar nicht gedacht.
Ich werde die Tabellen meiner Datenbank demnächst umstellen und alles Personal in einer Tabelle abspeichern.
Jaja, Wald und Bäume und so...  ;)

Vielen Dank noch einmal für die Hilfe und "Nebel lichten"!

Gruß

Samurai2_de
"Vegetarier" ist das indianische Wort für "zu doof zum jagen"!

Ein Tag ohne Lachen ist ein verschenkter Tag!