Sub-SQL über Jet->ODBC->SQL-Server geht nicht

[Ralph Erdt]

Moin!<BR>
Wir haben in Delphi eine Anwendung geschrieben, die mit den Opus-Komponenten auf Access geht (Opus-DirectAccess ist ein 'Framework' für die Jet(DAO)-Engine, die die BDE ersetzt; sprich für den Entwickler ist der Zugriff komplett transparent).<BR>
Jetzt soll das Programm erweitert werden, damit es auch (bei Bedarf!) mit SQL-Server zusammenarbeitet. Dazu verwenden wir einfach eine ODBC-verbindung, anstatt einer Dateiverbindung.<BR>
Nach etlichen Hindernissen (SQL-Server und Access ist ja fast gleiche Engine, das dürfte gaaaar keine Probleme geben - Frust ) bin ich soweit gekommen:<BR>
Ich kann keine Sub-SQLs ausführen! Wenn ich folgende SQL per Programm ausführe (Ich habe mir ein Worksheet gebastelt):<BR>
'select * from test' (DB:Access) klappt.<BR>
'select * from test' (DB:SQL-Server) klappt.<BR>
'select * from (select * from test)' (DB:Access) klappt.<BR>
'select * from (select * from test)' (DB:SQL-Server) klappt nicht.<BR>
Diesen SQL direkt an der Server-Konsole klappt wiederrum (heul).<BR>
Als Fehlermeldung kommt dann: "DAOERROR(DAO.Database:3078): Das Microsoft Jet-Datenbankmodul findet die Eingangstabelle oder Abfrage 'select * from test' nicht. Stellen Sie sicher, dass sie existiert und der Name richtig eingegeben wurde." (Fehlerkode 3078)<BR>
Was kann ich da machen?<BR>
MFG,cu,LLAP Ralph Erdt

[Bernhard Geyer]

Hallo Ralph,

die Behauptung "SQL-Server und Access ist ja fast gleiche Engine" ist nur dann Richtig, wenn:

- Eine neue Access-version verwendet wird (>= 2000) und<br>
- Eine Datenbank als "Microsoft Access-Projekt" angelegt wird

und damit Access nur noch für die Oberfläche zuständig ist, da die Daten in der MS-SQL-Datenbank (Ob nun richtige Version oder "nur" MSDE ist dabei egal) liegen.

In allen anderen Fällen is die MS Jet-Engine beteiligt und dies ist eine komplett andere Datenbank (Syntax, Möglichkeiten, ...)

Was soll dies Abfrage 'select * from (select * from test)' bewirken? Für mich ist die keine gültie SQL-Anweisung.
"Frage alle Daten ab, die du aus der Tabelle bekommst, welchen Tabellennamen du mit "select * from test" bekommst". Dies kann wahrscheinlich der SQL-Parser von MS-SQL-Server nicht auflösen (und wahrscheinlich auch alle anderen DBMS außer Access auch nicht

[Ralph Erdt]

Moin!<BR>
&gt;die Behauptung "SQL-Server und Access ist ja fast gleiche Engine" ist nur dann Richtig, [...]<BR>
Das ist eben nu mal die landläufige Meinung unter Chefs, und Leuten, die sich nicht damit auskennen... :-/. Außerdem verkauft Mickysoft das ganze so.<BR>
<BR>
&gt;Was soll dies Abfrage 'select * from (select * from test) bewirken'? [...]<BR>
Das ist nur ein Beispiel, um das ganz einfach zu demonstrieren. Außerdem kann das so ziemlich jede Datenbank, die ich kenne (Access, FoxPro, M$-SQL-Server, Oracle, Intebase, BDE, etc...). Ist Sub-SQL nicht sogar ANSI?<BR>
Das wird schlimmstenfals so ausgeführt: Erst der Sub-SQL, und mit dem Ergebnis den Haupt-SQL ausführen.<BR>
<BR>
MFG,cu,LLAP Ralph Erd

[Bernhard Geyer]

Hallo Ralph,

Dein Beispiel ist aber für ein Subselect falsch, da das Subselect anstelle des Tabellennamens steht.

Grundsätzlich kann sicherlich jedes DBMS mit Subselects umgeben. Aber so wie es für C/C++ einen ANSI-Standart gibt den jeder Compilerhersteller nach eigenen Vorstellungen erweitert gilt dies auch für SQL. Es gibt zwar SQL-Standarts (SQL92, ...), jedoch stellen diese nur eine "Basis" dar, die jeder Hersteller nach eigenen Anforderungen erweitert. Evtl. verwendet deine Query+Subquery Spezialitäten von Access, die im MS-SQL-Server nicht oder in einer anderen Syntax unterstützt werden.<br>Dazu müsstest Du das genaue Beispiel posten und die Version von Access und MS-SQL-Server angeben

[Ralph Erdt]

Moin!<BR>
Hmmm...<BR>
Sub-Querys kann man in 'from' reinpacken. Jeder richtige Datenbank und selbst MS-SQL-Server und Access (Jet?) kann das.<BR>
Das ist z.B. notwendig, wenn man Gruppierungs- oder Zählungsfunktionen braucht.<BR>
Ein Beispiel:<BR>
<BR>
<PRE>
/* Die Anzahl Aufträge pro Kunde */
select kunde.name,
kunde.adresse,
anz.anzahl
from kunde,
(select kunden_nr,count(*) as anzahl from auträge group by kunden_nr) anz
where kunde.kunden_nr=anz.kunden_nr
</PRE>
<BR>
(Das habe ich mir eben aus den Finger gezogen, ist also kein real-Beispiel.<BR>
Es soll nur die Problematik verdeutlichen.<BR>
BTW: die join-Syntax ist Oracle. Die ANSI join-Syntax kann ich nicht so eben schnell auswendig... )<BR>
<BR>
Obwohl ich nicht glaube das es hilft:<BR>
Client: Win2K Pro Sp2, MDAC 2.7<BR>
Server: Win2K-Server Sp2, MS-SQL 7.00.1063<BR>
<BR>
MFG,cu,LLAP Ralph Erd

[Bernhard Geyer]

Hallo Ralf,

Ich bin mir nicht sicher, ob wirklich jede SQL-Datenbank deine Subquery <b>in dieser Art</b> versteht, aber ich habe es gerade mit Northwind nachvollzogen und da versteht es Acces und MS-SQL-Server schon (Access 200, MS-SQL-Server 7).
<pre>
SELECT Customers.CompanyName, Customers.City,
Anz.Anzahl
FROM Customers,
(SELECT Orders.CustomerId, COUNT(Orders.[EmployeeId])
AS Anzahl
FROM Orders
GROUP BY Orders.CustomerId) anz
WHERE Customers.CustomerId = anz.CustomerId
</pre>
funktionierte auf beiden DB's.

Ich vermute jetzt, da du von einem DAOERROR geschrieben hast, greift Du nicht mit ADO auf den Server zu sondern per DAO. Und hier scheint Access/DAO selbst die SQL-Query abarbeiten zu wollen.

Welche Access-Version hast Du

[Ralph Erdt]

Moin!<BR>
Jup, das "DAOError" ist von meinem Programm geschrieben. Wie gesagt, verwenden wir die DAO, und greifend darüber per ODBC auf eine MS-SQL-DB zu.<BR>
Und diese Verbindung scheint etwas 'schräg' zu laufen, als ob die Jet da nochwas am analysieren ist, wo die einfach nur durchreichen sollte.<BR>
Das ist ziemlich ungünstig, da ich das Projekt schon zu (schätzungshalber) 80%-85% umgestellt habe... .<BR>
Wir haben Access 2K und das Programm verwenden die Jet 4.0.<BR>
MFG,cu,LLAP Ral<B>ph</B> Erd

[Helge Marquardt]

Hallo,<br>

Das Beispiel "select * from (select * from test)" funktioniert auch auf einem MS-SQL-Server (6.5, 7.0 oder 2000) nicht, probier es doch mal mit<br>"select * from (select * from test) t".<br>Das vom "Sub-SQL"-Statement zurückgelieferte Ergebnis stellt eine temporäre Tabelle dar, die einen Namen zur Identifikation benötigt.<br>Das ursprüngliche Beispiel liefert auf dem MS-SQL-Server übrigens einen Syntaxfehler "Falsche Syntax in der Nähe von ')'".<br><br>Schöne Grüße<br>Helge Marquard

[Bernhard Geyer]

Schau mal ob Du es auf ADO umstellen kannst (und ohne ODBC-Eintrag) auskommst. Sollte auch bezüglich der Weiterverteilbarkeit besser sein. Auch ist es besser mit ADO nur noch eine Zwischenschicht zu haben als mit DAO->ODBC noch 2 zu haben.<br>
DAO ist ja ein Auslaufmodell und wird nicht mehr standardmäßig installiert. ADO (ist zwar im Rahmen von .NET auch schon wieder veraltet) ist die bessere Möglichkeit, da jedes neuere Windows (2000/XP) schon eine halbwegs neue ADO-Version installiert hat

[Ralph Erdt]

Moin!<BR>
@Helge: Jup. das hatte ich vergessen dazuzuschreiben, es ist mir aber schon bewusst. Das hilft leider nicht weiter.<BR>
<BR>
@Bernhard: Genau diese Möglichkeit besteht (noch ?) nicht. ADO ist auf Access einfach zu lahm.<BR>
<BR>
Mir bei weiteren Test aufgefallen: Jet interpretiert die Klammern anscheined als Datei. Könnte das irgendwie weiterhelfen?<BR>
Wenn alles nichts hilft, werden wir doch wohl eine Access-DB erstellen müssen, in der alle Tabellen der DB verknüpft sind. <BR>
Danke und <BR>
MFG,cu,LLAP Ralph Erd

[Andreas Kosch]

Hallo,

&gt;...ADO ist auf Access einfach zu lahm...

Dieser Satz ist nur dann richtig, wenn ADO die CursorLocation clUseClient nutzt. Bei CursorLocation = clUseServer und CommandType = cmdTableDirec sollten derartige Probleme verschwinden, wenn eine passende Kombination der Versionsnummer der JET Engine und der MDB-Datenbank verwendet wird