Also, ich muß eine Access Datei über ODBC öffnen, das sieht bei mir so aus:
Dim WS As Workspace
Dim DB As Database
Dim RS As Recordset
' Microsoft Jet Workspace-Objekt erstellen. dbUseJet
Set WS = CreateWorkspace("", "Admin", "", dbUseODBC)
Set DB = WS.OpenDatabase("Datenbank", _
dbDriverNoPrompt, True, _
"ODBC;DATABASE=Datenbank;UID=Admin;PWD=;DSN=Datenbank")
Set RS = DB.OpenRecordset("Tabelle")
So, das ganze ich jetzt im Prinzip aus der ganzen VB Online Hilfe
zusammengestrickt :-)
Jetzt kommt meine eigentliche Frage:
Wie kann ich jetzt in den Tabellen suchen?
Mit RS.Index = "Nr" bekomme ich immer "Operation wird für diesen Objekttyp
nicht unterstützt"
Kann ich die DB irgendwie so öffnen, das es wieder mit .Index funzt?
Gruß
Christian
Mit welchem VB Version Arbeitest du? Wenn du mit VB6 Arbeitest, rate ich dir mit
ADO zu Arbeiten anstatt mit DAO. DAO ist etwas Veraltet. Hier mußt du noch ein
CommandDialog in dein Formular einfügen.
Per ADO gehts so:
Dim DB As Database
Dim RS As Recordset
Set db = New ADODB.Connection
With cmdStandartdialog
.DialogTitle = "Wählen sie die Datenbank aus!"
.Filter = "Jet-Datenbanken(*.mdb)|*.mdb" ' | = Zeigt nur Endung *.mdb an
db.CursorLocation = adUseClient
.ShowOpen
If .FileName = "" Then
MsgBox "Sie müssen eine gültige Datenbank angeben"
End
End If
db.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & .FileName
End With
Hier erscheint dann ein Fenster wo du die Position der Datenbank eingeben mußt.
Dann müssen wir den Recordset vorbereiten:
Set re = New Recordset
Set re.ActiveConnection = db
re.CursorType = adOpenKeyset
re.LockType = adLockReadOnly
re.Open "SELECT * FROM Tabelle ", , , , adCmdText
dyHaupttabelle.MoveFirst
Eine kleine Abfrage von mir:
Private Sub bssuchen_Click()
mName = InputBox(" Bitte geben sie den Nachnamen ein den sie finden möchten!")
If mName = "" Then
MsgBox "Bitte den Korrekten Namen eingeben!"
Exit Sub
Else
przDatenbankvorbereiten
rs.Filter = "Name LIKE '" & mName & "%'"
If rs.RecordCount = 0 Then
MsgBox "Es wurde kein Datensatz gefunden"
Exit Sub
Else
tfName.Text = rs
End If
End If
End Sub
Hoffe das ich dir ein bischen weitergeholfen habe
mfg Ramses
Wenn ich das hier probiere:
Set db = New ADODB.Connection
With cmdStandartdialog
.DialogTitle = "Wählen sie die Datenbank aus!"
.Filter = "Jet-Datenbanken(*.mdb)|*.mdb" ' | = Zeigt nur Endung *.mdb
an
db.CursorLocation = adUseClient
.ShowOpen
If .FileName = "" Then
MsgBox "Sie müssen eine gültige Datenbank angeben"
End
End If
db.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & .FileName
End With
bekomme ich an der Stelle 'Set db = New ADODB.Connection' folgenden Fehler:
Benutzderdefinerter Typ nicht gefunden
Als was muß ich ADODB definieren?
Und mein größeres Problem ist eigentlich, daß ich auf eine DB zugreife die
vorher eine normale Access Datei war, also mein Programm komplett fertig ist
und auch funktiert(e). Demensprechend arbeite ich überall mit dem '.Index'
und '.Seek'. Wenn ich das richtig verstanden habe, muß ich jetzt SQL
abfragen machen, oder? Muß ich jetzt mein ganzes Programm umstricken? :-(
Gruß
Chrisitan
"Steffen Rachel" <Rams...@web.de> schrieb im Newsbeitrag
news:ea3401c0c973$99822880$19ef2ecf@tkmsftngxa01...
Hi Christian,
> Mit welchem VB Version Arbeitest du? Wenn du mit VB6 Arbeitest, rate ich dir
mit
> ADO zu Arbeiten anstatt mit DAO. DAO ist etwas Veraltet. Hier mußt du noch ein
> CommandDialog in dein Formular einfügen.
Himmel, warum jetzt alles wieder umstricken, wenn er nun mal mit DAO arbeitet?
Muß doch nun wirklich nicht sein, so genial ist ADO z. Zt. auch noch nicht.
So Christian, das Suchen mit DAO geht ganz einfach
With RS
.Index="IndexName" 'z. B. PrimaryKey
.Seek "=",VariableMitWert
if .NoMatch Then
msgbox "Nicht gefunden"
Else
msgbox "Wert gefunden! :-) "
End If
.Close
End With
Viel Erfolg
Gerrit
--
-----------------------------------------------------
KUH-SOFT http://www.kuh-soft.de
Bahrenfelder Steindamm 100
22761 Hamburg
Gerrit Kuhlendahl <g...@kuh-soft.de> schrieb in im Newsbeitrag:
O1X6SnayAHA.1972@tkmsftngp03...
"Christian Hellwig" <hel...@acordsoft.de> schrieb im Newsbeitrag
news:eXUCbNbyAHA.892@tkmsftngp05...
> Danke Gerrit, daß auch Du Dich noch bemüht hast, aber das war nicht die
> Lösung meines Problems.
> Ich kann dem Recordset kein Index zuweisen und dementsprechend nicht mit
> Seek suchen. Jetzt frag aber mich nicht was das genau für ne DB ist, ich
> weiß nur, jetzt kann man sie nur noch über ODBC öffnen, nicht mehr dirkt mit
> OpenDatabase("C:\xxx.mdb") und ich muß darin suchen, ganz viel :-(
>
Na, dann mal frei nach Wilhelm Busch:
Und hilft auch alles dieses nicht,
so hilft ein Blick ins SQL(icht)...
pvStrSql="SELECT * FROM Tabelle WHERE Feldname = " & Variablenwert
Set RS=db.openrecordset(pvStrSql,dbopendynamic)
Das Rec.Set enthält dann alle die Datensätze, auf die die WHERE-Bedingung
zutrifft. Wenn Du Strings sucht, mußt Du noch mit Anführungszeichen
arbeiten:
pvStrSql="SELECT * FROM Tabelle WHERE TextFeldName = '" & variable & "'"
Um eine bessere Performance zu erzielen, solltest Du u. U. auch nicht alle
Felder einlesen sondern nur die, die Du auch benötigst, also die SELCET-
Bedingung nicht so allgemein fassen.
Ok, ich kann das Ziel schon fast sehen, aber eine Hürde scheint es da noch
zu geben, also ...
Ich muß aus mehreren Tabellen Daten zusammentragen. Die SQL Suche
funktioniert in der 1. Tabelle ohne Probleme, nennen wir das ganze RS1. RS1
liefer mir genau 427 Einträge, das ist ok. Jetzt muß ich zu jedem dieser 427
Datensätze einen passenden aus einer 2. Tabelle suchen, also hab ich das
ganze SQL Zeug nochmal mit RS2 gemacht. Mal ganz davon abgesehen, daß noch
ein paar Tabelle fehlen bekomme ich entweder die Fehlermeldung 'Nicht
genügend Stapelspeicher' oder, naja, hab ich mir gedach machste halt vorher
immer RS2.Close und dann verabschiedet sich gleich das ganze VB.
... ist mir ja fast schon peinlich, aber was ist jetzt noch falsch ?
Gruß
Christian
"Christian Hellwig" <hel...@acordsoft.de> schrieb im Newsbeitrag
news:#01NNPcyAHA.1560@tkmsftngp03...
> Hi Gerrit
>
> Ok, ich kann das Ziel schon fast sehen, aber eine Hürde scheint es da noch
> zu geben, also ...
Oooch, komm, so schlim wird es schon nicht sein... :-)
>
> Ich muß aus mehreren Tabellen Daten zusammentragen. Die SQL Suche
> funktioniert in der 1. Tabelle ohne Probleme, nennen wir das ganze RS1. RS1
> liefer mir genau 427 Einträge, das ist ok. Jetzt muß ich zu jedem dieser 427
> Datensätze einen passenden aus einer 2. Tabelle suchen, also hab ich das
> ganze SQL Zeug nochmal mit RS2 gemacht. Mal ganz davon abgesehen, daß noch
> ein paar Tabelle fehlen bekomme ich entweder die Fehlermeldung 'Nicht
> genügend Stapelspeicher' oder, naja, hab ich mir gedach machste halt vorher
> immer RS2.Close und dann verabschiedet sich gleich das ganze VB.
>
> ... ist mir ja fast schon peinlich, aber was ist jetzt noch falsch ?
>
Ist ja schön, daß Du so große Stücke auf mich hälst (mußt Du aber nicht,
ehrlich), aber ich kann echt nicht hellsehen, wirklich nicht, ehrlich ;-))
Also, da mußt Du schon mal ein bißchen Code sehen lassen.
Im übrigen gibt es bei SQL die Möglichkeit, mit sog. JOINs mehrere Tabellen
für eine Abfrage zu verknüpfen, um es einmal stark vereinfacht auszudrücken.
Eine entsprechende Abfrage könnte dann z. B. so aussehen:
pvStrSql="SELECT Tab1.*, Tab2.* FROM Tabelle1 AS Tab1 INNER JOIN " & _
"Tabelle2 AS Tab2 ON Tab1.Feldvergl=Tab2.Feldvergl2 " & _
"WHERE Tab1.SuchFeld=" & VariableMitSuchwert
Diese Abfrage würde Dir alle Felder der Tabellen 1 und 2 liefern, und zwar
von allen Datensätzen, in denen die Werte der Felder "Feldvergl" (aus Tabelle1)
und "Feldvergl2" (aus Tabelle2) übereinstimmen *und* wo das Feld "SuchFeld"
aus Tabelle1 den Wert der Variablen "VariableMitSuchwert" hat.
Aber aufpassen: Das obige Beispiel ist ACCESS-SQL. Da Du mit ODBC-Direct
arbeitest, kann es sein, daß Du die Syntax an den bei Dir benötigen SQL-
Dialekt anpassen mußt, wenn Du nicht mit Access arbeitest.
Im übrigen solltest Du Dir zum Thema SQL auch mal die Online-Hilfe oder auch
Sekundärliteratur zu Gemüte führen, z. B.:
SQL - Der Standard
Chis J. Date, Hugh Darwen
Addison-Wesley, ISBN 3-8273-1245-7
Das ist sogar auf Deutsch, somit leicht verdaulich und daher als Bettlektüre
hervorragend geeignet.
Dim WS As Workspace
Dim DB As Database
Dim RS1 As Recordset
Dim RS2 As Recordset
Dim Suche1, Suche2, Suche3
DIM Plan(5000, 100)
Set WS = CreateWorkspace("", "Admin", "", dbUseODBC)
Set DB = WS.OpenDatabase("Datei", _
dbDriverNoPrompt, True, _
"ODBC;DATABASE=Easy;UID=Admin;PWD=;DSN=Datei")
Monat = Val(Text1.Text)
Jahr = Val(Text2.Text)
Suche1= "SELECT * FROM Tabelle1 WHERE Monat = " & Monat & " AND Jahr = "
& Jahr
Set RS1= DB.OpenRecordset(Suche1, dbOpenDynamic)
Q = 0
Do Until RS1.EOF
Q = Q + 1
Plan(Q, 1) = RS1!Nummer
Suche2 = "SELECT * FROM Tabelle2 WHERE Nummer = " & Plan(Q, 1)
Set RS2= DB.OpenRecordset(Suche2, dbOpenDynamic)
If RS2.EOF Then
Plan(Q, 2) = "unbekannt"
Plan(Q, 7) = ""
Else
Plan(Q, 2) = RS2!A
Plan(Q, 7) = RS2!B
End If
RS1.MoveNext
Loop
Gruß
Christian
"Christian Hellwig" <hel...@acordsoft.de> schrieb im Newsbeitrag
news:e7BmAmoyAHA.2004@tkmsftngp02...
> Also, hier ist der Code :-)
> Wie schon gesagt, entweder hängt sich das VB ganz auf oder es gibt die
> Fehlermeldung: Nicht genug Stapelspeicher
Wundert mich so nicht mehr unbedingt. Vorweg mal ein paar kleine Bemerkungen:
1. Bei Dir scheint Option Explicit zu fehlen, Q wird z. B. nirgens
deklariert.
2. Wähle nach Möglichkeit beschreibende Variablennamen, z. B. "Ergebnis"
oder "Zwischenspeicher" etc., das macht den Code wartbarer.
>
> Dim WS As Workspace
> Dim DB As Database
> Dim RS1 As Recordset
> Dim RS2 As Recordset
> Dim Suche1, Suche2, Suche3
> DIM Plan(5000, 100)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Zum einen sind die Variablen SucheX und auch das Array Plan hier unnötiger
Weise als Variant deklariert. Wähle die Typen, die Du auch brauchst, bei
Plan anscheinend STRING.
Zum anderen erstellst Du hier ein Array mit 500.000 Feldern. Da dieses Array
als Variant deklariert ist, sind das erstmal 2 Byte pro Feld für die
Typbeschreibung,
somit schon mal 1 Mb Speicher, daß Du verschenkst. Wenn ich dann mal davon
ausgehe,
daß Du in jedes Feld mal 10 Zeichen speicherst, sind das pro Feld
2 Byte für Datentypbeschreibung
4 Byte für die Stringlänge
10 Byte für die eigentlichen Daten
---
16 Byte pro Feld an Daten * 500.000 Feldern = 8.000.000 Byte =7.8 MB
Speicher,
die Du verbrätst.
Da Du nun auch noch u. U. etwa genauso viele Daten aus der Datenbank in den
Speicher ziehst, kann es auf kleineren Systemen schon mal eng werden.
Überleg Dir mal, ob Du die Daten wirklich alle im Speicher halten mußt.
Wozu brauchst Du überhaupt 100 Felder, wenn Du nur bis zum Index 7 in der
2. Dimension gehst?
>
> Set WS = CreateWorkspace("", "Admin", "", dbUseODBC)
>
> Set DB = WS.OpenDatabase("Datei", _
> dbDriverNoPrompt, True, _
> "ODBC;DATABASE=Easy;UID=Admin;PWD=;DSN=Datei")
>
> Monat = Val(Text1.Text)
> Jahr = Val(Text2.Text)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Wozu das? Wird doch eh wieder in einen String gewandelt. Besser die Inhalte
der Textboxen im Validate-Ereignis oder vor Beginn der Auswertung / Suche
auf Gültigkeit prüfen (Stichwort: IsNumeric)
[schnibbel]
Versuchs mal so:
Dim WS As Workspace
Dim pvDb As Database
Dim pvRecSetDy As Recordset
Dim pvLngN As Long 'Schleifenzähler
Dim pvStrSqlStatem As String
DIM Plan(5000, 100) As String
Set WS = CreateWorkspace("", "Admin", "", dbUseODBC)
Set DB = WS.OpenDatabase("Datei", _
dbDriverNoPrompt, True, _
"ODBC;DATABASE=Easy;UID=Admin;PWD=;DSN=Datei")
pvStrSqlStatem="SELECT Tab1.*,Tabelle2.A AS T2FA, Tabelle2.B AS T2FB " & _
"FROM Tabelle1 As Tab1 LEFT JOIN Tabelle2 ON " & _
"Tabelle1.Nummer=Tabelle2.Nummer"
Set pvRecSetDy=pvDb.OpenRecordset(pvStrSqlStatem, dbOpenForwardonly)
'Zum reinen Suchen/Lesen bietet
'dbOpenForwardonly die bessere Performance
With pvRecSetDy
pvLngN==0
Do While not .Eof
Plan(pvLngN,1)=cstr(.Fields("Nummer).Value)
if isNull(.Fields("T2FA").Value) Then
'Wert von T2FA ist NULL, wenn kein
'Datensatz in Tabelle2 vorhanden.
Plan(pvLngN,2)="unb."
Plan(pvLngN,7)=""
Else
Plan(pvLngN,2)=cstr("" & .Fields("T2FA").Value)
Plan(pvLngN,7)=cstr("" & .Fields("T2FB").Value)
End If
.MoveNext
pvlngN=pvLngN + 1
loop
End With
Genaueres kann ich Dir so auch nicht sagen (auch nicht zur Optimierung),
solange ich nicht weiß, worum es geht (Glaskugel ist immer noch in der
Reparatur).
natürlich mal wieder die Hälfte vergessen: Die Abfrage muß
selbstverständlich so aussehen:
pvStrSqlStatem="SELECT Tab1.*,Tabelle2.A AS T2FA, Tabelle2.B AS T2FB " & _
"FROM Tabelle1 As Tab1 LEFT JOIN Tabelle2 ON " & _
"Tabelle1.Nummer=Tabelle2.Nummer WHERE Tab1.Monat = " & _
Text1.Text & " AND Tab1.Jahr = " & Text2.Text
ups, so eine simple Lösung, war man Array doch ein bisschen groß :-)
Jetzt läuft es, so hoffe ich. Danke. Die Woche ist gerettet.
Gruß
Christian
Jetzt hab ich noch ein ganz großes Performance Problem. Ich hab das mit dem
INNER JOIN hinbekommen, allerdings nur mit 2 Tabellen:
pvStrSql = "SELECT Tab1.*, Tab2.* FROM Dis_Kopf AS Tab1 INNER JOIN " & _
"Filme AS Tab2 ON Tab1.Filmtitel = Tab2.Nummer" & _
" WHERE Tab1.Monat = " & Monat & " AND Tab1.Jahr = " & Jahr
Set rs_DisKopf = DB.OpenRecordset(pvStrSql, dbOpenForwardOnly)
Also, ich versuche das jetzt mal irgendwie zu erklären:
Es gibt insgesamt 4 Tabellen die ich benötige.
1. Tabelle: Dis_Kopf
Hier stehen die Grundlegenden Informationen für die Tabelle
a) Monat und Jahr, das sind die beiden Werte nach den ich suche, also
Monat = 04 und Jahr = 2001
b) Filmtitel, das ist die Nummer des Films, welcher sich dann in der 2.
Tabelle, Filme, wiederfindet
c) LiefNr, das ist die Nummer des Lieferanten, welcher sich dann in der
3. Tabelle, Lieferanten, wiederfindet
d) Sortiment
e) Datum
f) Preis
dementsprechend gibt´s die
2. Tabelle: Liefer
Bestehnd aus Nummer, Name und noch viel Müll den ich nicht brauche
3. Tabelle: Filme
Nummer und Name, auch hier steht in Form von 'Lieferant' noch mal die
Lieferantennummer drin
Mit meiner obigen Abfrage fehlt mir jetzt der Lieferant, was allerdings
nicht mal das große Problem ist, den getrennt rauszusuchen geht noch
verhältnismäßig schnell. Ich bekomme jetzt 731 Datensätze. Daraus setzen
sich jetzt die "Grundinformationen" der Tabelle zusammen:
Datum, Titel, Lieferant, Sortiment, Preis
So, und jetzt kommt das wirklich schwierige, die 4. Tabelle, denn meine
Tabelle muß so aussehen:
Datum, Titel, Lieferant, Sortiment, Preis, Zahl1, Zahl2, ... Zahl40
Ich muß jetzt also noch schlappe 29240 Datensätze zusammensuchen :-(
Vorher ging das recht flott, aber jetzt, wenn ich jeden einzelnen suche, hab
ich das gefühl das wird erst fertig wenn ich´n grauen Bart habe.
Also in der 4. Tabelle (Dis_Pos) sieht´s so aus:
a) Monat
b) Jahr
c) Filmtitel
d) Art keine Ahnung was das genau ist, aber da brauche ich
nur alles was "L" ist
e) Nummer Da gibt´s meine Spalten 1-40
f) Summe und da steht der passende Wert dazu drin
Ok, ich gestehe, ich hab mir noch kein Buch gekauft, und ich habe immer noch
nicht so richtig den Durchblick.
Kann man jetzt das ganze mit so einer Art Mamut Abfrage in einem Rutsch
machen?
Ich hab jetzt mal versuch, einfach eine neu Abfrage zu machen, in der ich
mich dann auf das Recordset 'rs_DisKopf' beziehe, aber das geht wohl nicht.
... hm, ja, ich weiß, ich werde wohl etwas nervig, aber Du weißt doch: Jeden
Tag eine gute Tat :-)
Gruß
Christian
Aber kann ich jetzt noch meine ersten 3 Tabellen mit dem INNER JOIN
miteinander verbinden?
(Dis_Kopf - Filme - Lieferanten)
Gruß
Christian
"Christian Hellwig" <hel...@acordsoft.de> schrieb im Newsbeitrag
news:O2$u2a9yAHA.1620@tkmsftngp05...
> Hm, irgendwie wirst Du mich nicht mehr los :-)
Och, so'n Colt Peacemaker macht seinem Namen Ehre und
beschert Ruhe (gilt übrigens auch für meine beiden
Freunde Smith und Wesson) :-)))))))))))))
[schnipp]
Das mit dem Performanceproblem erklärt sich recht leicht: Du hast hier eine
reine Access-SQL-Abfrage. Wenn Du nun aber nicht auf eine Access-Datenbank
zugreifst, muß diese Abfrage in das andere Format konvertiert werden. Das
kann manchmal dauern. Ich hab das mal bei einer Oracle-Datenbank und 15(!)
Datensätzen gehabt: Auf diese Art über 20 Sekunden und über ODBC-Direct
in Nullkommanichts...
> Also, ich versuche das jetzt mal irgendwie zu erklären:
^^^^^^^^^^^^
konkret wäre mir lieber ;-)
[schnipp]
>
> Mit meiner obigen Abfrage fehlt mir jetzt der Lieferant, was allerdings
> nicht mal das große Problem ist, den getrennt rauszusuchen geht noch
> verhältnismäßig schnell. Ich bekomme jetzt 731 Datensätze. Daraus setzen
> sich jetzt die "Grundinformationen" der Tabelle zusammen:
Man kann JOINs auch schachteln. Die Frage ist dann aber letztlich, wie
performant das Ganze schlußendlich wird. Ohne eine genauere Kenntnis
der zu Grunde liegenden Datenbank, der ggf. vorhandenen Relationen und
Indizes kann ich Dir da aber auch nicht weiterhelfen.
[schnipp]
> d) Art keine Ahnung was das genau ist, aber da brauche ich
> nur alles was "L" ist
Einfach die WHERE-Bedingung erweitern: "... AND Art LIKE 'L*'"
Achtung: SQL-Server und Oracle erwarten als Wildcard statt "*" ein "%"
> e) Nummer Da gibt´s meine Spalten 1-40
> f) Summe und da steht der passende Wert dazu drin
>
> Ok, ich gestehe, ich hab mir noch kein Buch gekauft, und ich habe immer noch
> nicht so richtig den Durchblick.
Da empfehle ich Dir
Datenbankprogrammierung mit VisualBasic 6
Doberenz / Kowalski
MicrosoftPress, ISBN3-86063-4485-2
(für Einsteiger)
Professionelle Datenbankprogrammierung
Michael Kofler
(genauers hab ich im Moment nicht, ist gerade verliehen)
> Kann man jetzt das ganze mit so einer Art Mamut Abfrage in einem Rutsch
> machen?
Kann man schon (s.o.)
> Ich hab jetzt mal versuch, einfach eine neu Abfrage zu machen, in der ich
> mich dann auf das Recordset 'rs_DisKopf' beziehe, aber das geht wohl nicht.
>
> ... hm, ja, ich weiß, ich werde wohl etwas nervig, aber Du weißt doch: Jeden
> Tag eine gute Tat :-)
>
Ne gute Tat schon, aber keine Einführung in SQL und Datenbankprogrammierung.
Deck Dich mit Literatur ein und versuch erstmal hinter die Grundlagen zu kommen.
Übe dann an einer Access-Datenbank und kleineren, überschaubaren Beispielen.
Später kannst Du Dich dann an größere Sachen trauen. Mal anders ausgedrückt:
Wenn Du zwar ein 100m Läufer bist, würdest Du Dich dann einfach mal so beim
Maraton anmelden und dann auch noch erwarten, daß Du ankommst? :-))
Viel Spaß beim Lesen
"Christian Hellwig" <hel...@acordsoft.de> schrieb im Newsbeitrag
news:eb6Smg#yAHA.720@tkmsftngp03...
Wie gesagt, Du kannst JOINs schachteln. Erstell Dir in Access mal
ein paar Tabellen und laß Dir mit dem Abfrageassistenen mal eine
Abfrage über mehrere Tabellen erstellen. Den SQL-Code kannst Du
Dir dann mal ansehen, damit Du das Prinzip erkennst. Aber Obacht:
Derartige Abfragen sind nicht unbedingt ausreichend performant.