Office: (Office 2007) Ãœberlauf?

Und genau die geht unter A2007 in die Hose... echt lustig. Da hilft selbst sowas nicht:

Code:

Erst wenn man Access2007 explizit zwingt (durch den Join oder Group By) zuerst die Fälle mit 0 herauszufiltern geht es:

Code:

Wer jetzt aber der Meinung ist, dass man einfach 2 Querys nehmen kann:

Query: a_LINKE_List (ohne Filter auf Prozente)

Code:

und dann die Filterung in einem 2. Query macht:

Code:

bekommt direkt den Ãœberlauf um die Ohren gehauen...

Wer hat ne Erklärung? :-)

 

Also wenn ich die ursprüngliche Abfrage mit der ">0"-Filterung erweitere, läuft es bei mir unter Acc2007 auch...

Code:

 

Danke für den Hinweis! Also

a) 0 geht nicht -> Ãœberlauf
b) > 0 geht -> OK

Lt. meinem Mathe-Buch ist aber nur die Division durch 0 nicht erklärt, und nicht etwa die Division von irgendwas kleiner oder gleich 0. *grins

 

Ich habe jetzt keine Erklärung für diesen merkwürdigen Fall, aber eine Bemerkung: Die Verwendung von "" und "NOT" in einem Abfragekriterium ist ein Sündenfall. Das geht aus meinem Lehrbuch (Link in Fußnote) hervor, weil solche Gestaltungen eine Indexnutzung verhindern.
In Anwendung von guten Gewohnheiten ist es selbst dann ein Sündenfall, wenn auf dem zu filternden Feld gar kein Index liegt.

 

Da braucht man sich nur den Showplan anzusehen:
Code:

Anm.: /9 damit der Fehler nicht auftritt

=> Code:

JET führt erst die Berechnungen durch, wobei es eben zur Division durch 0 kommt.

Bei der Verwendung von >
Code:

bleibt es bei der Reihenfolge und somit entsteht kein Fehler.

Um eine Erklärung zu finden, müsste man die Interna des JET-Optimierers kennen.

Das was den "Ãœberlauf" provoziert, ist jedenfalls die Div durch 0.

 

Was mich ein wenig irritiert ist das Verhalten von Acc2007.
Seit 2007 ist, soweit mir bekannt, die Jet-Engine durch die ACE-Engine ersetzt worden, welche auch in 2010 Verwendung findet.
Und warum ignoriert die Jet-Engine ein IIf (siehe #17)?
Das läuft auch nicht ohne >.
Und wieso verwendet 2007 nicht die ACE (der es scheinbar egal ist) wie 2010?

 

Acc 2007 ACE 12.0
Acc 2010 ACE 14.0
Link: https://en.wikipedia.org/wiki/Micros...atabase_Engine
Da mag es den einen oder anderen Unterschied geben. *wink.gif*

Das tut sie(die Engine) nicht, es kommt auf den Ausführungsplan an (s.o.).

Wenn die Originalabfrage bei 2010 ohne Fehler durchläuft, ist die JET/ACE intelligenter geworden, bzw. wurde für unbedarfte User optimiert.

 

So wird man das nicht sagen können.

Die ACE ist eine "Aufbohrung" der Jet-Engine, um zusätzliche Features bereitstellen zu können. Solche Features sind z.B. Anlagefelder, mehrwertige Felder, Recordset2 (Acc2007) und DataMacros (Acc2010). Daraus kann man ableiten, dass es verschiedene "Ausbaustufen" der ACE geben muss, wobei aber insgesamt immer die grundlegenden Elemente (TableDefs, QueryDefs, Indexes, Relations, Jet-SQL) in ihrer Funktion gleich bleiben sollten.
Als Entwickler weiß man aber auch, dass man bei Weiterentwicklungen auch neue Fehler (an vorhandenem) einbauen und auch wieder entfernen kann.

Im Beitrag #31 (stendate) sind einige Widersprüche bzw. Irritationen enthalten. Mangels Acc2007 kann ich es aber nicht auflösen.

Aber definitiv gilt allgemein und nicht nur speziell für Jet-SQL oder irgendeine Version:

- Ein JOIN und ein WHERE machen bei der Verknüpfung von Tabellen datenbanktechnisch das Gleiche: Erst wird ein CROSS JOIN angelegt, und dann wird datensatz-paarweise eine Übereinstimmung auf den Schlüssel geprüft. Vorhandene Indizes helfen da ungemein, weil über diese die Werte schneller zu finden und zu vergleichen sind.
Eine Reihenfolge zwischen JOIN und WHERE gibt es da nicht, das entscheidet der SQL-Optimierer für sich je nach Fall. Allerdings wird er einen Vergleich bevorzugt an erster Stelle ausführen, wo die Nutzung eines Index möglich ist.

- Eine Unterabfrage, die als Tabelle für eine weitere Abfrage dient, die also im FROM-Teil einer Abfrage steht, sollte zuerst ausgeführt werden, ehe die WHERE-Klausel der aufbauenden Abfrage in Anwendung kommt.

Abfrageabarbeitung:
1) FROM
2) WHERE
3) GROUP BY
4) HAVING
5) SELECT
6) ORDER BY

Marsu hat dankenswerterweise auf den Ablaufplan verwiesen. Leider spiegelt der Jet-Showplan nur Abläufe einfacher Abfragen wieder. Hat man verschachtelte und komplexere Abfragen und also Fälle, wo es erst wirklich interessant wird, ist es dann vorbei mit der Hilfestellung.

 

Danke für die Erklärungen.
Zusammendfassend bedeutet das aber für mich als Entwickler, um Rückwärts kompatibel zu bleiben bleibe ich bei Acc2003 als Entwicklungsplattform.
Denn wenn die Jet-Engine konsequenterweise logische Fehler (unter Berücksichtigung des Jet-Showplans) entsprechend erkennt, ist mir das lieber als alle daraus resultierende Fehler, welche dann kein Mensch mehr findet.

Diese "Optimierungen" werden m.E. ein immer größer werdender Klotz am Bein der Entwickler.

 

\@Blackpit: Diese Deine Schlussfolgerung ist auch nicht die ultimative, unabhängig davon, dass man mit seiner Entwicklungsplattform auch mit den Kunden mitgehen muss - wenn die dann Win 9 einsetzen (müssen) und dieses kein Office 2003 mehr unterstützt, hat irgendjemand Handlungsbedarf.

Es gab in der Vergangenheit durchaus auch einige Fälle, wo mit einer neuen Version oder schon einem notwendigen Hotfix eine vorhandene Fehlertoleranz abgebaut wurde und es dadurch "plötzlich und überraschend" zu Fehlern kam, wo doch immer alles prima lief, wobei es dann vorwiegend unsaubere und verkürte Codes und unvollständige Referenzierungen betraf.

Offensichtlich als Ursache der eingangs geschilderten Problematik ist die Division durch 0. Das ist also auch ein Datenproblem und nicht nur ein Problem eines Codes oder einer Datenbankmaschine. Das Datenproblem sollte man auch frühzeitig erkennen können, insbesondere dadurch, dass man eine Anweisung mit verschiedenen übersichtlichen Eingangsdaten testet, die aber auch und besonders Grenzfälle abdecken.
Hier haben einige (ich eingeschlossen) der Behauptung, ohne Kriterium läuft die Abfrage, geglaubt statt zu prüfen und zu sehen, dass im SELECT-Ausdruck der Berechnung auch schon Fehler sichtbar waren.

 

Entwicklungs- und Produktivversion sind zwei "paar Stiefel".
Ich kann ja DB hochkonvertieren bevor ich Sie ausliefere.

Ich habe sie geprüft
Code:

funktioniert (bringt ein Ergebnis) wie von RWg mitgeteilt. Vom Fehler bei den DS mit [gültigen stimmen] = 0 mal abgesehen. Das der Fehler dann allerdings erst bei einer Werteeinschränkung auftritt ist dann auch klar (warum allerdings mit Überlauf??). Jet macht ja, wie bereits festgestellt, alles richtig.

 

funktioniert ... heißt, in den betreffenden Datensätzen steht im Feld Prozent nicht "#Zahl" bzw. "'Fehler", sondern ein plausibles Ergebnis?

 

Funktioniert bedeutet für mich, die Abfrage liefert grundsätzlich mal Werte ob plausibel oder mit Fehlern ist egal, der Showplan wird erstellt und abgearbeitet.