Post by Ulrich MöllerPost by Peter DoeringPost by Lars P. WolschnerPost by Ulrich MöllerSELECT T1.*
FROM [E:\Projekte\Lang\DB\nwind2000.mdb].Orders AS T1
LEFT JOIN [E:\Projekte\Lang\DB\nwind.mdb].Orders AS T2
ON T1.CustomerID = T2.CustomerID;
mmmpf. Vielen Dank für Deine Mühe und Geduld, auch an die
anderen in diesem Thread. So funktioniert es bei mir auch und
ich lasse mein Framework das in dieser Form mit dem
geklammerten Dateinamen ohne weitere Angaben erzeugen.
Aber werkelt da nicht nach wie vor nur ODBC?
Leider ist sind solche Art Zugriffe aber relativ langsam und
sollten vielleicht die Ausnahme bleiben.
Das ist auch der Fall und findet überhaupt nur zu diagnostischen
Zwecken statt. Zu diagnostischen Zwecken können dann auch Access-
Abfragen erzeugt werden. Im normalen Ablauf wird das nicht mehr
benötigt. Geflechte aus einer Vielzahl voneinander abhängigen
Abfragen sind schwer wartbar.
Post by Ulrich MöllerEine weitergehende Dokumentation für diese Syntax habe ich
nicht gefunden, sondern es wird immer nur auf den IN-Operator
verwiesen (from .... in).
Mit diesem Modifikator kann man AFAIR nur eine weitere externe
Datenquelle in der FROM-Klausel anzapfen. Die o.a. Notation
erlaubt dagegen für jede Tabelle eine andere Herkunft. Liegt die
Tabelle auf einem MS SQL-Server, muß der Name der Datenbank
("Katalog") im Connectstring in der eckigen Klammer im Database-
Attribut genannt werden, während der Schemabezeichner dem
Tabellennamen selbst voranzustellen ist und beide gemeinsam in
einer eckigen Klammer zusammenzufassen sind. Dabei ist dann auch
eine Alias-Deklaration Pflicht, weil sich dieses Paar aus Schema-
und Tabellenname nicht direkt an den übrigen Stellen des SQL-
Kommandos verwenden läßt.
Post by Ulrich MöllerPost by Peter DoeringIch hab nicht den ganzen Thread nachgelesen, aber Access zu
Jet(ACE) per ODBC geht nicht, das geht nur von Anwendungen <>
Access. Gerade unter 2010 getestet: "You cannot use ODBC to
import from, export to, or link an external Microsoft Access or
ISAM database table to your database."
Stellt man per DAO eine Verbindung zu einem MS SQL Server-Katalog
her, findet man die Tabellennamen sämtlich mit dem Namen des
Schemas qualifiziert, zu dem sie gehören. Weil die o.a. Notation
in der FROM-Klausel das auch so fordert, kam ich auf den Gedanken.
Das habe ich aber nur aus Neugierde gemacht, ich nutze DAO fast
gar nicht mehr; meine ADO-Codebasis ist der für DAO mittlerweile
überlegen. Microsoft verweist zur Erzeugung von Access-Abfrage-
Objekten auf DAO, obwohl sich solche Objekte auch per ADOX anlegen
lassen. Der Unterschied: Per DAO angelegte Abfrageobjekte sind
bereits nach dem Neuaufbau der Anzeige im Datenbankfenster
sichtbar, per ADOX angelegte dagegen erst nach dem nächsten
Access-Neustart.
Post by Ulrich MöllerSollte man beim Anwendungsentwurf immer im Hinterkopf behalten!
Verbindungsorientiert mit ADO und mit meinem Framwork geht es sehr
gut, Tabellen außerhalb eines MS SQL- oder Oracle-Server sind die
Ausnahme. Zumal ich auch die feldbezogenen Informationen aus dem
Datenbankschema nutze und dabei auch per VBA ADO-basiert sehr viel
performanter arbeite als per DAO mit verknüpften Tabellen.
--
Mit freundlichen Grüßen
Lars P. Wolschner