Office: (Office 2010) Verzicht auf Hilfstabelle ergibt zu komplexen Ausdruck

hallo

ich habe
* eine Tabelle "tbl_Punkte", die Punktnummern mit xyz-Koordinaten enthält,
* eine Tabelle "tbl_Linien", die aus Punktnummern Polylinien zusammenstellt und mit Liniennummern versieht, sprich "Line Nr. 1 läuft von Punkt A über Punkt B zu Punkt C",
* eine Tabelle "tbl_Planquadrate", die die Koordinaten der Ecken der Planquadrate enthält,
* eine Tabellenerstellungs-Abfrage "TE_PPQ", die Punkte um die Angabe des Planquadrates ergänzt und in tbl_PQR speichert:

Code:

* eine Auswahlabfrage "qry_LAE", die mittels Min/Max zu jeder Linie den Anfangs- und Endpunkt ermittelt. Aufbau in der Entwurfsansicht: tbl_Linien INNER JOIN tbl_Punkte

Schlussendlich wird in einer letzten Abfrage "info" die qry_LAE um die Planquadrate ergänzt. Aufbau in der Entwurfsansicht:
tbl_PPQ INNER JOIN tbl_Linien INNER JOIN qry_LAE INNER JOIN tbl_Linien_1 INNER JOIN tbl_PPQ_1

Das Konstrukt funktioniert.

Ich möchte es gerne zu einer Abfrage zusammenfassen und dabei auf die Hilfstabelle tbl_PQP verzichten.

Den SQL-Code von qry_LAE konnte ich als Subselekt integrieren, das müsste dann so aussehen (Subselekt in Klammern):

tbl_PPQ INNER JOIN tbl_Linien INNER JOIN (tbl_Linien INNER JOIN tbl_Punkte) INNER JOIN tbl_Linien_1 INNER JOIN tbl_PPQ_1

Wenn ich dann die Hilfstabelle tbl_PPQ auch nur an einer Stelle durch die entsprechende Abfrage ersetzte (TE_PPQ ohne INTO) oder deren Code als Subselekt einsetze, erhalte ich aber die Fehlermeldung "Dieser Ausdruck wurde falsch eingegeben, oder er ist zu komplex, um ausgewertet zu werden. Beispielsweise kann ein numerischer Ausdruck zu viele komplizierte Elemente enthalten. Vereinfachen Sie den Ausdruck, indem Sie Teile des Ausdrucks Variablen zuweisen."

Es müsste dann so ausehen:
(FROM tbl_Punkte, tbl_Planquadrate) INNER JOIN tbl_Linien INNER JOIN (tbl_Linien INNER JOIN tbl_Punkte) INNER JOIN tbl_Linien_1 INNER JOIN tbl_PPQ_1

Konnte mir jmd bis hierher folgen und Richtung Lösung schubsen?
Danke.
Simon

:)

 

Deine JOIN's enthalten keine JOIN-Kriterien. So wie das hier dargestellt wird, kann da gar nichts funktionieren.
Code:

Da knallt es garantiert auch.

Die Jet-Engine besteht schon auf richtige Syntax. Mit freiem Fabulieren drehst Du nur Ehrenrunden.

Ich persönlich gehe bei einem Lösungsversuch so vor:
- Ich verschaffe mir Klarheit, was genau als Ergebnis herauskommen soll.
- Dann schaue ich mir das Beziehungsbild an, um benötigte Tabellen und benötigte Felder zu identifizieren. Ggf. muss man hier bereits gegebene Daten berücksichtigen.
- Jetzt baue ich meine Abfrage schrittweise auf, von innen nach außen unter Berücksichtigung von allgemeinen Regeln wie Einfachheit, wenig Aufwand, schnellstmögliche Datenmengenreduzierung, Indexnutzung und so etwas.

Aus Deiner Prosa ist dafür sehr wenig zu entnehmen.

Wenn Du weißt, was Du machst: Grundlagen - SQL ist leicht (6) - Komplexe Abfragen schreiben und lesen

 

Moin,

Ich habe ein funktionierendes Konstrukt aus 3 Abfragen und 2 Tabellen und 1 Hilfstabelle.
Ich möchte aus drei Abfragen eine machen und dabei auf die Hilfstabelle verzichten.
Wenn ich den SQL-Code der Hilfstabellen-Abfrage als Subselect einsetze, erhalte ich o.g. Fehlermeldung.

Ich vermute, dass sich Access an den Verknüpfungen verschluckt. Da die Entwurfsansicht keine Subselects darstellen kann, habe ich die JOINS und die Joins der Subselects in Klammern angegeben. Ich halte die Angabe Join-Kriterien für diese Fragestellung irrelevant, da das ursprüngliche Konstrukt funktioniert und daher IMHO kein Grund besteht, diese zu verändern.

Ich vermute genauer gesagt, dass sich Access an den nicht vorhandenen Verknüpfungen der Hilfstabellen-Abfrage verschluckt, daher hatte ich SQL-Code der Abfrage angegeben. Da sich die Vorschau an den "

 

Der Begriff "Einbinden" ist immer wieder toll, so ganz ohne Klarsicht, ob links oben oder rechts unten, von einer bestimmten Zielfunktionalität ganz zu schweigen.

Ansonsten: Das Ersetzen einer Tabelle in einer funktional und syntaktisch richtigen Abfrage durch eine (Unter)Abfrage ist weitgehend bloßes Kopieren, wie bereits beschrieben im verlinkten Beitrag.

 

ja doch, und es (das weitgehend bloße Kopieren) führt zu o.g. Fehlermeldung.

Kannst Du mit 70 Zeilen Code so viel mehr anfangen?
Der auskommentierte Code ist der Code, der die Hilfstabelle erzeugt.

Code:

grüsse
simon

 

Auf jeden Fall mehr als bei Erzählungen, da wäre hier ein Feld und da ein Feld, und funktionieren tut das ja sowieso ...

Die Logik erschließt sich mir natürlich nicht mit vertretbarem Aufwand, weil mein Formatter diese Anweisung nicht auflösen kann und man schon mal nicht ohne weiteres sieht, wie es innen im FROM-Teil losgeht. Folgend hat man dann auch keinen Überblick über die Klammerungen.
Die Lesbarkeit leidet auch darunter, dass keine praktikablen Aliase verwendet wurden.

Die Unterabfrage und tbl_Stationen wird mehrfach verwendet. Die Logik dazu müsste man auch erst einmal erkennen können. Bis hierhin natürlich auch nicht möglich.
Die von der Entwurfsansicht übernommene Klammerinflation macht es auch nicht gut leserlich: Ich habe nur zehn Finger zum Zählen.

Code:

Was das soll, müsste auch extra erklärt werden. Bedingungen werden generell auf True geprüft, das ist eine Selbstverständlichkeit.

So etwas kann einem bei einem Gesamtanblick auffallen. Der Sinn des Ganzen ist selbstredend nur schwer entnehmbar, so ohne Kenntnis von Situation (Datenmodell, Ziel in Struktur und Daten basierend auf gegebenen Daten, ggf. ergänzt um eine Beschreibung dazu). Es könnte ja neben dem Funktionieren an sich auch die Frage nach effizienten Funktionieren auftreten.
Aber das Verstehen und solches war ja auch nicht gefragt.

Ausgehend davon würde man die ursprüngliche "funktionierende" Abfrage in SQL-Anweisung benötigen sowie dann die SQL-Anweisung, die die Hilfstabelle ersetzen soll. Das zweite ist gegeben.
Damit würde ich ein eigenständiges Ersetzen vornehmen, was für mich systematisch ein sehr einfacher und relativ zügiger Vorgang ist, einfacher als bei einem fremden Konstrukt die Klammern und sonstwas zu zählen und zuzuordnen.

Dann könntest Du vergleichen sowie testen.

 

*verwundert* ich lese Deine Prosa, aber ich verstehe sie nicht.
Im ersten Beitag steht doch klar, dass ich wissen will, in welchem Planquadrat Polylinien beginnen und in welchem sie enden. Dazu muss ich zuerst den Anfangs- und Endpunkt jeder Polylinie ermitteln (in der Mitte, blau). Auf der einen Seite muss ich dann den Anfanfgspunkt seine Koordinaten heraussuchen und dann ermitteln, in welchem Planquadrat er liegt. Auf der anderen Seite das Gleiche für den Endpunkt. Das grüne ist die Datenherkunft Hilfstabelle, die sich nicht durch den zur ihrer Erstellung verwendeten SQL-Code ersetzten lässt.

(FROM tbl_Punkte, tbl_Planquadrate) INNER JOIN tbl_Linien INNER JOIN (tbl_Linien INNER JOIN tbl_Punkte) INNER JOIN tbl_Linien_1 INNER JOIN (FROM tbl_Punkte, tbl_Planquadrate)

Im letzten Post habe ich den vollständigen, funktionierenden und mit dem allseits bekannten SQLinform formatierten Code der Abfrage gepostet und angegeben, dass das Problem auftritt, wenn man die auskommentierten Zeilen "unkommentiert".


---
WHERE (xyz.Rechtswert_lu < P.Rechtswert And P.Rechtswert < xyz.Rechtswert_ro)=-1

Habe ich mittlerweile ersetzt durch

WHERE (P.Rechtswert between xyz.Rechtswert_lu And xyz.Rechtswert_ro)

Damit wird die x-Koordinate (Rechtswert) des Punktes mit den x-Koordinaten der oberen und unteren Ecken der Planquadrate verglichen. Anlog für die y-Koordinate (Hochwert).
---

Wenigstens hat sich hier gerade ein Beispiel egeben, sodass ich weiß, dass das hier
Code:

prinzipiell funktioniert ist.

grüsse
simon

 

Moin,
bisher lasse ich für jede Line Anfangs- und End-Punkt ermitteln und lasse dann für diese beiden Punkte jeweils das Planquadrat ermitteln. Versuchsweise habe ich den Weg umgekehrt: Ich lasse für jeden Punkt das Planquadrat ermittlen und siebe dann die Anfangs- und Endpunkte von Linien aus. Das funktioniert wenigstens halbwegs, ist aber aus verschiedenen Gründen ein Irrweg (erwartungsgemäß spürbare Rechenzeit, ich kann die Gruppierung nicht mehr auf ein kleines Subselekt beschränken).
grüsse
simon

grüsse
simon

 

Witzig...

Das Problem ist in #5 sichtbar: Im Select-Teil werden Felder aufgerufen (u.a. tbl_Hilf_PunktBlattschnitt.Rechtswert, die in den grünen Subselects nicht ausgewählt werden *stupid

(aussagekräftige Fehelrmeldungen...*rolleyes.gif* )

grüsse
simon

 

Code:

Eine doppelte Aliasierung wird wahrscheinlich nicht von der Jet-Engine verstanden.

 

sie würde meckern.

sqlinform verwendet -- als Zeichen für Kommentare. Wenn man den grünen Teil unkommentiert, muss "tbl_Hilf_PunktBlattschnitt AS " auskommentiert werden, dann läuft es.

 

Die Frage sei gestattet: Worüber sollte man nachdenken, wenn nicht über das Gezeigte ...?
(Ich bin erstaunt, in welcher Welt manche leben. Realität?)

 

ich zitiere aus #3
"
Ich habe ein funktionierendes Konstrukt aus 3 Abfragen und 2 Tabellen und 1 Hilfstabelle.
Ich möchte aus [diesen] drei Abfragen eine machen und dabei auf die Hilfstabelle verzichten.
Wenn ich den SQL-Code der Hilfstabellen-Abfrage als Subselect einsetze, erhalte ich o.g. Fehlermeldung.
Ich vermute, dass sich Access an den Verknüpfungen verschluckt."

Grüsse
simon

 

Ich hatte Hinweise erwartet, z.B. dass es nicht an den Verknüpfungen liegen wird, weil weder die zulässige Anzahl erreicht wird noch die übermäßig komplex verschachtelt wird.