Access Beziehungen: Nur Kunden löschen ohne Ausleihe

[Henning_Meier]

Hallo,
wir sollen eine kleine Bücherreichdatenbank in Access schreiben.

Dabei habe ich jetzt 2 Tabellen:
KundenId, Vorname, Nachname <= Kunden-Tabelle
AusleihId, Buch_id, Kunden_id <= Tabelle mit den Ausleihen.

So wenn ich jetzt aus der Kunden-Tabelle einen Kunden lösche, möchte ich überprüfen, ob dieser auch alle Bücher zurückgegeben hat, sprich ob in der Ausleih-Tabelle noch ein Datensatz mit seiner Kunden_id vorhanden ist.

Also unser Lehrer (...) meinte, dass man dies mit Beziehungen & Referentieller Integrität lösen könnte.

Ich bekomme es aber immer nur so hin, dass wenn ich unter Tabelle einen Kunden-Datensatz lösche, dass dann auch in der Ausleih-Tabelle die entsprechenden Datensätze gelöscht werden, allerdings möchte ich das ja genau anders rum haben, dass der Datensatz nur gelöscht werden kann, wenn die KundenId nicht mehr in der Ausleihe auftaucht.

Weiß jmd. Rat, wie dies mit Beziehungen geht?

P.S. Ich persönlich bin kein Freund von Access ;)

MFG

[globe]

n'abend,

Ich bekomme es aber immer nur so hin, dass wenn ich unter Tabelle einen Kunden-Datensatz lösche, dass dann auch in der Ausleih-Tabelle die entsprechenden Datensätze gelöscht werden, allerdings möchte ich das ja genau anders rum haben, dass der Datensatz nur gelöscht werden kann, wenn die KundenId nicht mehr in der Ausleihe auftaucht.

keine Ahnung ob Access mit Foreignkey-Constraints klar kommt, aber das wär ein Stichwort um mal zu schauen...

P.S. Ich persönlich bin kein Freund von Access ;)

gibt es access-freunde?

weiterhin schönen abend...

[Vinzenz Mai]

Hallo globe,

keine Ahnung ob Access mit Foreignkey-Constraints klar kommt, aber das wär ein Stichwort um mal zu schauen...

an die DDL-Codierung der Access-DB-Objekte zu kommen, ist nicht so einfach. Das sind genau die Dinge, die vor dem Access-Benutzer gut versteckt werden. Wie üblich kommt man mit den grafischen Frontends von Access, die z.T exzellent sind, irgendwann an die Grenzen, wo man um "normale" SQL-Kenntnisse nicht herumkommt.

Mit Constraints kann Access prinzipiell ausgezeichnet umgehen, allerdings klickt der Benutzer sich diese Beziehungen in einem grafischen Editor zusammen. SQL-Kenntnisse sind dazu nicht erforderlich.

Freundliche Grüße

Vinzenz

PS: Die Antwort auf Deine Frage ist übrigens: Ich, wie viele andere auch.

[Henning_Meier]

Hallo,

keine Ahnung ob Access mit Foreignkey-Constraints klar kommt, aber das wär ein Stichwort um mal zu schauen...

Danke ich werde mal schaun.

P.S. Ich persönlich bin kein Freund von Access ;)

gibt es access-freunde?

Ja mein Lehrer (...), (Zitat) weil die HTML Strukturierung soooo schwer und kompiziert ist....

Vorallem kotzt es mich an, dass Access keine normalen SQL Abfragen richtig bearbeitet, wo es z.B. mit MySQL keine Probleme gäbe...

MFG

[Chris]

Hallo,

Vorallem kotzt es mich an, dass Access keine normalen SQL Abfragen richtig bearbeitet, wo es z.B. mit MySQL keine Probleme gäbe...

MySQL ist gegenüber der Leistungsfähikeit der JET-Engine Spielzeug. Allerdings sollte man auch bedenken, dass es eben eine Client-Server-DBE ist und keine File-Server-DBE.

Außerdem wirst Du, sofern Du den Weg in die EDV nimmst, im Leben noch oft mit Werkzeugen arbeiten müssen, die Dir zumindest auf den ersten Blick nicht schmecken. Alternative: Du erfindest alles selbst, dann weißt Du wenigstens, bei wem Du dich beschweren musst :-)

LG
Chris

[Vinzenz Mai]

Hallo Henning,

Vorallem kotzt es mich an, dass Access keine normalen SQL Abfragen richtig bearbeitet, wo es z.B. mit MySQL keine Probleme gäbe...

was verstehst Du unter einer normalen SQL-Abfrage?

Wie ist Dein Kenntnisstand hinsichtlich verschiedener SQL-Dialekte und deren Inkompatibilitäten. Ich lerne in diesem Bereich gerne und ständig hinzu. Gerade das, was als "normal" angesehen wird, ist oft davon abhängig, wo man herkommt. Denn das umgekehrte gilt auch für den Access-User. Es gibt Dinge, da liefert die Jet-Engine wunderbar das Gewünschte, aber kein anderes mir bekanntes DBMS.
z.B. TRANSFORM ... PIVOT, die "Kreuztabellenabfrage".

Freundliche Grüße

Vinzenz

[Henning_Meier]

Hallo,

Vorallem kotzt es mich an, dass Access keine normalen SQL Abfragen richtig bearbeitet, wo es z.B. mit MySQL keine Probleme gäbe...

was verstehst Du unter einer normalen SQL-Abfrage?

Also es gibt eine (ANSI) SQL-Funktionen, vorallem im JOIN bereich, die so unter Access nicht richtig implementiert sind, bzw. unter MySQL eine ganz andere Wirkung haben.

Es nervt schon wenn man genau weiß wie die Abfrage unter SQL aussieht, man dann aber lange nach dem Access Äquivalent suchen muss.

MFG

[Vinzenz Mai]

Hallo

was verstehst Du unter einer normalen SQL-Abfrage?

Also es gibt eine (ANSI) SQL-Funktionen, vorallem im JOIN bereich, die so unter Access nicht richtig implementiert sind, bzw. unter MySQL eine ganz andere Wirkung haben.

Könntest Du das bitte präzisieren. Daran bin ich sehr interessiert, weil ich unter anderem an einem Feature-Artikel zu Joins arbeite, siehe Archivposting von Tim mit Hinweis auf die Reviewversionen.

Es nervt schon wenn man genau weiß wie die Abfrage unter SQL aussieht, man dann aber lange nach dem Access Äquivalent suchen muss.

Ja, es nervt ganz gewaltig, wenn man genau weiß, wie die Abfrage als SQL-Statement aussieht und man dann lange nach dem MySQL-Workaround suchen muss.

Freundliche Grüße

Vinzenz

[Ilja]

yo,

Könntest Du das bitte präzisieren. Daran bin ich sehr interessiert, weil ich unter anderem an einem Feature-Artikel zu Joins arbeite, siehe Archivposting von Tim mit Hinweis auf die Reviewversionen.

ich bin strickt dagegen, die Access JOIN syntax mit aufzunehmen. man muss meiner ansicht nach dummes nicht noch vervielfältigen ;-)

Ilja

[Axel Richter]

Hallo,

Könntest Du das bitte präzisieren.
ich bin strickt dagegen, die Access JOIN syntax mit aufzunehmen. man muss meiner ansicht nach dummes nicht noch vervielfältigen ;-)

Toll! Nun habe wir hier zwei angebliche "ACCESS-Hasser", die behaupten, es gäbe eine "spezielle ACCESS-JOIN-Syntax", die super schlecht wäre, ohne dies konkret zu belegen. Da ich keine "spezielle ACCESS-JOIN-Syntax" kenne, behaupte ich mal, Ihr redet beide von etwas, wovon Ihr keine Ahnung habt. Ihr plappert einfach Vorurteile nach, die Ihr aus dritter Hand irgendwo gehört habt. Die einzige "spezielle JOIN-Syntax", die ich kenne, ist die mit dem (+) für Outer-Joins in der WHERE-Klausel und die ist von Oracle.

viele Grüße

Axel

PS: Ja, das ist eine Provokation, weil Vinzenz es ja im Guten nicht geschafft hat, konkretes aus Euch herauszukitzeln. Und ja, ich habe etwas gegen diffuse Verunglimfungen ohne konkrete Substanz.

[Ilja]

yo,

Toll! Nun habe wir hier zwei angebliche "ACCESS-Hasser", die behaupten, es gäbe eine "spezielle ACCESS-JOIN-Syntax", die super schlecht wäre, ohne dies konkret zu belegen.

einen Link dazu habe ich bei Google auf die schnelle nicht finden können. aber es geht um verknüpfungen bei Access mit mehr als zwei tabellen. die syntax ist mir ein wenig aufgestossen. ein beispiel, dass du leicht selbst ausprobieren kannst.

SELECT spalten....
FROM tab1
INNER JOIN tab2 ON (tab1.spalte = tab2.spalte)
INNER JOIN tab2 ON (tab2.spalte = tab3.spalte)

meiner meinung nach eine korrekte Syntax, wo Access sich aber dagegen verwehrt und einen fehler ausgibt. läßt man sich nun per clicky, clicky die query von access erzeugen, dann wird auch der unterschiedliche aufbau deutlich.

SELECT spalten....
FROM tab1
INNER JOIN (tab2 INNER JOIN tab2 ON tab2.spalte = tab3.spalte)
ON tab1.spalte = tab2.spalte

nun will ich micht nicht hinstellen und sagen, dass geht so gar nicht. letztlich weiß ich noch nicht mal genau, was ASNI SQL dazu sagt. aber mir gefällt diese schreibweise ganz und gar nicht, obwohl ich mit access nicht auf kriegsfuß stehe, entwickle ja gerade die inventars-datenbank unseren edv abteilung damit. also eine allergie kann dann ja nicht vorliegen.....

Ilja

[Axel Richter]

Hallo,

aber es geht um verknüpfungen bei Access mit mehr als zwei tabellen. die syntax ist mir ein wenig aufgestossen. ein beispiel, dass du leicht selbst ausprobieren kannst.

SELECT spalten....
FROM tab1
INNER JOIN tab2 ON (tab1.spalte = tab2.spalte)
INNER JOIN tab2 ON (tab2.spalte = tab3.spalte)

Dieser Join kann nie funktionieren, weil unklar ist, welche Rolle tab3 hier innerhalb der Beziehungen spielt.
Solltest Du

SELECT spalten....
FROM tab1
INNER JOIN tab2 ON (tab1.spalte = tab2.spalte)
INNER JOIN tab3 ON (tab2.spalte = tab3.spalte)

meinen, dann funktioniert das so:

SELECT spalten....
FROM (tab1
INNER JOIN tab2 ON (tab1.spalte = tab2.spalte))
INNER JOIN tab3 ON (tab2.spalte = tab3.spalte)

auch im Access. Meiner Meinung nach sind die Klammern auch sinnvoll, um zu zeigen, welche Zwischenschritte beim Join gemacht werden.

läßt man sich nun per clicky, clicky die query von access erzeugen, dann wird auch der unterschiedliche aufbau deutlich.

SELECT spalten....
FROM tab1
INNER JOIN (tab2 INNER JOIN tab2 ON tab2.spalte = tab3.spalte)
ON tab1.spalte = tab2.spalte

Auch hier: Welche Rolle spielt tab3?

viele Grüße

Axel

[Ilja]

yo,

die zweite tab2 tabelle soll natürlich tab3 heißen, da habe ich mich verschrieben, da ich es mit realen tabellen probiert habe. der punkt ist der, die erste schreibweise geht in mysql, geht aber nicht unter access. ich finde die art & weise von access syntax nicht gut, aber das ist wohl ansichtssache. aber darum ging es ja, um seine meinung.

was aber nun hoffentlich geklärt sein sollte ist, dass access bei mehreren tabellen (> 2) eine andere syntax will.

Ilja

[Axel Richter]

Hallo,

was aber nun hoffentlich geklärt sein sollte ist, dass access bei mehreren tabellen (> 2) eine andere syntax will.

Nein, es will eine andere (bessere, weil eindeutigere) Klammersetzung, die auch MySQL nicht weh, sondern eher gut tut. Wegen diese zwei zusätzlich nötigen Klammern von anderer Syntax zu sprechen, halte ich für Übertrieben.

viele Grüße

Axel

[Ilja]

yo,

Nein, es will eine andere (bessere, weil eindeutigere) Klammersetzung, die auch MySQL nicht weh, sondern eher gut tut. Wegen diese zwei zusätzlich nötigen Klammern von anderer Syntax zu sprechen, halte ich für Übertrieben.

wie gesagt, ist es geschmackssache, das kann jeder halten wie ein dachdecker. meine ist, ich mag sie nicht.

und zum anderen ist es mehr als nur zwei klammern, die ON bedingung verschiebt sich. ist dir das nicht aufgefallen ?

Ilja

[Axel Richter]

Hallo,

und zum anderen ist es mehr als nur zwei klammern, die ON bedingung verschiebt sich. ist dir das nicht aufgefallen ?

Nein.

Wenn Du die Query aus https://forum.selfhtml.org/?t=120298&m=772600 meinst:

SELECT spalten....
FROM tab1
INNER JOIN tab2 ON (tab1.spalte = tab2.spalte)
INNER JOIN tab3 ON (tab2.spalte = tab3.spalte)

funktioniert so:

SELECT spalten....
FROM (tab1
INNER JOIN tab2 ON (tab1.spalte = tab2.spalte))
INNER JOIN tab3 ON (tab2.spalte = tab3.spalte)

auch in Access.

viele Grüße

Axel

[Ilja]

yo,

und zum anderen ist es mehr als nur zwei klammern, die ON bedingung verschiebt sich. ist dir das nicht aufgefallen ?
Nein.

aye, es geht auch mit den klammern. ich habe nur die syntax wiedergegeben, die mir access selbst ausgespuckt hat. ich bin wie gesagt kein fan davon, was aber ansichtssache ist.

warum es mir stört liegt daran, dass ich einen sql befehl wie "gewohnt" eingeben wollte und eine fehlermeldung erhielt. und das stört eben den arbeitsbetrieb. ich will nicht sagen, dass man sich die access syntax nicht aneignen kann und ich will auch nicht bestreiten, dass es keine vorteile hat. ABER meiner meinung nach ist SQL deshalb so stark, weil es eben eine mehr oder wenige grosse basis gibt, welche von den dbms akzeptiert werden, sozusagen einen hohen wiedererkennungswert.

ein weiteres beispiel wäre oralce, die bis version 8 ihre eigenen syntax hatten, einen OUTER JOIN auszuführen. das würde ich genauso kritisieren und oracle hat das sinnvollerweise auch geändert.

Ilja

[Henning_Meier]

Hallo,
also ich finde die JOIN Setzung auch sehr Umständlich bei Access.

Aber desweiteren hält Access mit * und ? nicht an die ANSI-SQL Platzhalter (bei Access 2000), und LIMIT gibt es dort auch nicht.

Anstatt muss man Umständlich ein TOP in die Spaltenabfrage einbaun.

MFG

[Ilja]

yo,

die fehlende LIMIT syntax würde ich access nicht ankreiden, es ist ein spezielles feature von mysql. ANSI SQL sollte es vielleicht mal übernehmen, es ist eine sehr sinnvolle erweiterung.

mit allem anderen stimme ich dir bekanntlich zu. man kann schon seinen eigenen dialekt reinbringen, aber sollte doch so weit es geht ANSI SQL unterstützen. wie gesagt sehe ich gerade darin einen vorteil von relationalen dbms.

Ilja

[Axel Richter]

Hallo,

also ich finde die JOIN Setzung auch sehr Umständlich bei Access.

Ahh! Beispiel! Bitte Bitte bring ein Beispiel für solche Behauptungen!

Aber desweiteren hält Access mit * und ? nicht an die ANSI-SQL Platzhalter (bei Access 2000),

Ja, _das_ ist wirklich ein Problem. Noch dazu, weil man hierbei auch noch sehr genau beachten muss, wie man auf Access zugreift, ob via DAO (z.B. Access-Application) mit "*" und "?" oder ADO bzw. ODBC mit "%" und "_".

und LIMIT gibt es dort auch nicht.

Das soll es häufiger geben.

viele Grüße

Axel

[Ilja]

yo,

Ahh! Beispiel! Bitte Bitte bring ein Beispiel für solche Behauptungen!

ich denke mal, es ist klar, dass die fur "normale" syntax über mehr als zwei tabellen unter access nicht funktioniert, jedenfalls nicht ohne geeignete klammerung oder verschiebung der ON bedingung. das beispiel dafür habe ich dir schon gegeben, keine ahnung warum du immer noch danach fragst.

SELECT spalten...
FROM tab1
INNER JOIN tab2 ON (tab1.id = tab2.fk_spalte)
INNER JOIN tab3 ON (tab2.id = tab3.fk_spalte)

führt unter access eben zu einem fehler.

du kannst dazu deine eigene meinung haben, dass solche klammerung sinnvoll ist, aber finde es nicht besonders klug, so vorzugehen. wenn die klammerung eine erweiterung anstelle einer ersetzung darstellen würde, dann wäre nichts dagegen zu sagen.

Ilja

[Henning_Meier]

Hallo,
was mir vorhin noch aufgefallen ist:
'DELETE FROM tabelle'

Dies führt zu einem Fehler, denn es muss mind. 1 Spalte ausgewählt werden.

Richtig:
'DELETE FROM tabelle.*'

Wenn ich aber nur 1 Spalte angeben, z.B. Username:
'DELETE FROM tabelle.username'

Dann wird dennoch die gesamte Zeile gelöscht (bzw. hier alle), und nicht nur die Spalte in der Zeile.

Dann könnte man doch gleich die Tabelle angeben, oder nicht?

MFG

[Axel Richter]

Hallo,

was mir vorhin noch aufgefallen ist:
'DELETE FROM tabelle'
Dies führt zu einem Fehler, denn es muss mind. 1 Spalte ausgewählt werden.

Ja. Oder es müssen eben alle Spalten (*) ausgewählt werden. Auch das ist, wie die wildcards, eine Spezialität von Access.

Richtig:
'DELETE FROM tabelle.*'

Falsch ;-))
DELETE * FROM tabelle;
oder
DELETE tabelle.* FROM tabelle;

Wenn ich aber nur 1 Spalte angeben, z.B. Username:
Dann wird dennoch die gesamte Zeile gelöscht (bzw. hier alle), und nicht nur die Spalte in der Zeile.

Ja, das ist die Definition von DELETE. Es werden Datensätze gelöscht. Wie sollten auch Felder gelöscht werden? Für das leeren von Feldern ist UPDATE zuständig.

viele Grüße

Axel

[Henning_Meier]

Hallo,

'DELETE FROM tabelle.*'
Falsch ;-))
DELETE * FROM tabelle;
oder
DELETE tabelle.* FROM tabelle;

Ja das meinte ich, aber es war auch recht früh^^

Wenn ich aber nur 1 Spalte angeben, z.B. Username:
Dann wird dennoch die gesamte Zeile gelöscht (bzw. hier alle), und nicht nur die Spalte in der Zeile.
Ja, das ist die Definition von DELETE. Es werden Datensätze gelöscht. Wie sollten auch Felder gelöscht werden? Für das leeren von Feldern ist UPDATE zuständig.

Das logisch, aber ich meine nur, dass es ziehmlich unlogisch&überflüssig ist, wenn man unter Access Spalten angeben muss.

MFG

[Ilja]

yo,

Das logisch, aber ich meine nur, dass es ziehmlich unlogisch&überflüssig ist, wenn man unter Access Spalten angeben muss.

ist es auch, wenn sowieso ganze dantensätze betroffen sind, sollte der name der tabellle reichen.

Ilja

[Chris]

Hallo,

das Konzept, hier mit Datensätzen zu arbeiten, die wieder entfernt werden, halte ich zwar für weltfremd, aber es funktioniert bei Access mit Referenzieller Integrität.

Dazu muss der Primärschlüssel der Kundentabelle mit dem Fremdschlüssel der Ausleihtabelle verbunden werden, und die referenzielle Integrität hierfür eingerichet werden. Allerdings darfst Du nicht die Löschweitergabe aktivieren. Und die Schlüsselweitergabe an Detaildatensatz benötigst Du auch nicht, da der Primärschlüssel in der Kundentabelle nicht geändert werden sollte.

Besser wäre allerdings eine Ausschlussaubfrage.
Dann könnten die Ausleihdatensätze nämlich erhalten bleiben und müssten nur mittels "Rückgabe erfolgt" markiert werden, wenn das Buch wieder da wäre.

LG
Chris

[Vinzenz Mai]

Hallo Chris,

das Konzept, hier mit Datensätzen zu arbeiten, die wieder entfernt werden, halte ich zwar für weltfremd, aber es funktioniert bei Access mit Referenzieller Integrität.

ich hatte in meinem Antwortposting schon einige Sätze dazu formuliert, die ich wieder rausgelöscht habe.

Und die Schlüsselweitergabe an Detaildatensatz benötigst Du auch nicht, da der Primärschlüssel in der Kundentabelle nicht geändert werden sollte.

Hat man beim Primärschlüssel 'AutoWert' als Datentyp gewählt kann man es noch nicht einmal, selbst wenn man es wollte. Die Art und Weise, wie in Access Autowert implementiert ist, ist meiner Meinung nach ungünstig. Ein Backup/Restore einzelner Tabellen wird damit effektiv verhindert (wenn Autowert verwendet wird). Da finde ich MySQL oder den MS SQL-Server wesentlich angenehmer.

Besser wäre allerdings eine Ausschlussaubfrage.
Dann könnten die Ausleihdatensätze nämlich erhalten bleiben und müssten nur mittels "Rückgabe erfolgt" markiert werden, wenn das Buch wieder da wäre.

Ein Ausleih- und Rückgabedatum wäre auch ganz nett. Das Rückgabedatum würde die Funktion von "Rückgabe erfolgt" übernehmen (ja, ist nicht ganz so einfach abzufragen). Dieses Beispiel zeigt wieder, das selbst anscheinend einfache Beispiele komplex werden können, wenn man ein paar vernünftige Features einbauen will.

Freundliche Grüße

Vinzenz

[Vinzenz Mai]

Hallo Henning,

Dabei habe ich jetzt 2 Tabellen:
KundenId, Vorname, Nachname <= Kunden-Tabelle
AusleihId, Buch_id, Kunden_id <= Tabelle mit den Ausleihen.

So wenn ich jetzt aus der Kunden-Tabelle einen Kunden lösche, möchte ich überprüfen, ob dieser auch alle Bücher zurückgegeben hat, sprich ob in der Ausleih-Tabelle noch ein Datensatz mit seiner Kunden_id vorhanden ist.

Das sollte kein großes Problem darstellen.

Also unser Lehrer (...) meinte, dass man dies mit Beziehungen & Referentieller Integrität lösen könnte.

Ja, kannst Du auch.

Ich bekomme es aber immer nur so hin, dass wenn ich unter Tabelle einen Kunden-Datensatz lösche, dass dann auch in der Ausleih-Tabelle die entsprechenden Datensätze gelöscht werden, allerdings möchte ich das ja genau anders rum haben, dass der Datensatz nur gelöscht werden kann, wenn die KundenId nicht mehr in der Ausleihe auftaucht.

Du hast beim Erstellen der Beziehung zwischen der Kunden- und Ausleihetabelle alle drei Kästchen angekreuzt. Da liegt der Fehler. Du darfst das Kästchen "Löschweitergabe an verwandte Datensätze" nicht ankreuzen.

Danach schlägt der Versuch, einen Kunden zu löschen, der noch Einträge in der Ausleihetabelle hat, fehl. Du erhältst die wie gefordert die Meldung, dass der Kunde nicht gelöscht werden kann, weil mit diesem Datensatz noch Daten in der Tabelle Ausleihe verknüpft sind.

P.S. Ich persönlich bin kein Freund von Access ;)

Es ist eine feine Sache, wenn ein DBMS referentielle Integrität unterstützt. Die Jet-Engine, das DBMS hinter Access, kann durchaus manches, wovon sich sogar DBMS-Server ein Scheibchen abschneiden können.

Freundliche Grüße

Vinzenz

[Chris]

Hallo,

Es ist eine feine Sache, wenn ein DBMS referentielle Integrität unterstützt. Die Jet-Engine, das DBMS hinter Access, kann durchaus manches, wovon sich sogar DBMS-Server ein Scheibchen abschneiden können.

Ich finde sie für eine Client-gestützte DBE auch klasse. Ist allerdings auch nicht von Microsoft :-)
Und die Fehler, die damals bei der (feindlichen) Übernahme drin waren, sind auch heute noch drin.

LG
Chris