Office: (Office 2007) Fortlaufende Nummer in Abfrage funktioniert nicht korrekt

Hallo @All,

heute wende ich mich an die SQL-Spezialisten, da ich gerade ziemlich auf dem Schlauch stehe !

Mit der folgenden Abfrage möchte ich eine fortlaufende Nummer erstellen, funktioniert aber nicht ganz korrekt:

Code:

 

Du hast doch laufende Nummern ab 1 beginnend.
Man darf nur eben für möglich halten, dass Berechnung und Ansichtsdarstellung unterschiedliche Dinge sind. Die verwendete Sortierung wird u.a. auch durch die Gruppierung beeinflusst.
Daneben sollte man die bestehenden NULL-Inhalte des einen Feldes mit besonderer Aufmerksamkeit beachten.

Die Gruppierung selber irritiert mich sehr. Wenn man über alle Felder gruppieren muss, hat man regelmäßig vorher etwas nicht richtig gemacht. Das ist aber ein anderer Kriegsschauplatz.

 

Hi ebs17,

leider benötige ich die Zahl 1 für den obersten Datensatz ;-)

Was für eine Sortierung ?
Sehe da kein Order by ;-)

Die Gruppierung aller Felder ist so gewollt, da ich eine Eindeutigkeit benötige !

 

Ich auch nicht. Da muss man sich aber auch nicht wundern, wenn sich eine Reihenfolge irgendwie ergibt und nicht so wie gewünscht.

Der spielt in einer Abfrage auch keine Rolle, erst in einem Recordset, wo eine Reihenfolge fixiert ist und man datensatzweise hüpfen kann.

 

Nun, die Sortierfolge wird durch die Gruppierung erzeugt ;-)

Genau für ein Recordset benötige ich diese Abfrage.
Und daher sollte die Zeile 1 mit der fortlaufenden Nummerierung 1 beginnen.

 

Wie wäre es denn, wenn man eines sehen und sogar verwenden würde? (Ich komme mir veräppelt vor.)
Code:

Daneben würde ich behaupten wollen, dass das Gruppieren sowieso unnötig ist. Bei Notwendigkeit müsste man das Gleiche auch in der Unterabfrage verwenden, anderenfalls dürfte man ganz andere Ergebnisse erwarten. Es wäre aber schade, wenn man auf Performancebremse und Problemquelle verzichten müsste ...

 

Ich habe hier keine Äpfel ;-)

Ich will ja nicht sortieren, gruppieren ist ja gleich ein Sort !!

Das ist doch jetzt mal ein Rat.

Wie soll diese Unterabfrage denn aussehen ?

 

Um eine fortlaufende Summe zu erzeugen benötigt man einen Index !
Wenn ich nun eine Artikeltabelle als Beispiel hernehme, so ist dort die Artikelnummer ja einzigartig.

In meiner Tabelle besteht der Index aber aus mehreren Feldern !
So muss natürlich nach diesen Feldern gruppiert werden ;-)

Mit meiner anderen Abfrage, die nicht nach der externen Lieferantennummer gruppiert ist, funktioniert es ja bestens:

Code:

 

Warum nimmst du nicht den Primär Index?
Der ganze Rest ist unnötig.

 

Hallo markusxy,

da der Primärindex nicht die externe Artikelnummer enthält.
Das Formular soll aber nach dieser externen Nummer aufsteigend sein.

Mit der 2. SQL wird nach dem Primärkey aufsteigend gearbeitet, dort funktioniert es ja auch.

 

Wenn es einem gelingt, eine laufende Nummer in der gewünschten Reihenfolge zu erzeugen, gelingt auch die gleichlautende Erzeugung der laufenden Summe.
Das DCount durch ein DSum auszutauschen ist nun kein gigantischer Akt.

Grundlagen - SQL ist leicht (10) - Nummerierung in Abfragen: Wer versteht, dass systembedingt in Jet diese Geschichte performanceproblematisch ist, wird eher daran denken, diese sparsam einzusetzen, aber sicher nicht, diese in sich zu schachteln und das Problem zu multiplizieren - es sei denn, man möchte bei Abfrageausführung einen Arztbesuch einschieben.

Ansonsten fühle ich mich hier bestens verstanden:
- Abweichende Sortierung durch explizite Sortieranweisung korrigieren => Ignoration
- Gruppierung unnötig => will ich vervielfältigen

Weiter so. Stürze Dich nicht vom Abgrund ...


Wie auch: Wenn man mit NULL nicht zu geeigneten Abläufen und Ergebnissen kommt, könnte man ja auch gleich per Nz/IIf einen Ersatzwert einschalten. Eine Indexnutzung in der Abfrage ist in der gezeigten Variante eh von Beginn an sicher verhindert, da muss man keine Rücksicht mehr nehmen.

 

Danke.

 

hallo

Wenn ich das richtig sehe, gruppiert sie über alle angezeigten Felder. Das muss sie doch auch, sonst meckert das Access ("Sie versuchen...anzuzeigen, die von der Aggregatfunktion nicht erfasst sind" o.s.ä.)?

Grüsse
simon

 

Die Aggregatfunktion findet nur in der Unterabfrage statt, nicht in der angesprochenenen Hauptabfrage.
Wenn man über alle Felder gruppieren muss, hat man im Vorhinein Duplikate vorliegen. Da sollte man eine erste Vorüberlegung investieren, ob das denn auch geschickter geht. Wenn man vorher vielleicht erst vervielfältigt, um dann wieder vereinzeln zu müssen, wäre das im Sinne von Effizienz nicht so geschickt.
Daneben ist Gruppieren als Vergleichsvorgang einfach Arbeit, über viele Felder und somit über hohe Bitbreiten viel Arbeit. Auch hier ließe einen der Gedanke an Effizienz etwas ahnen. Gruppieren kann über verwendbare Indizes positiv beeinflusst werden. Gibt es aber dann auch wirklich einen Index über alle diese Felder in der verwendeten Reihenfolge? Je mehr Felder, um so unwahrscheinlicher.

Sowie auch: Die erfahrung hier im Forum zeigt auch, dass solche Massengruppierungen einfach Ergebnis des probierenden Zusammenklickens im Abfrageeditor sein können und somit nicht mal Ergebnis gezielter Überlegung sein müssen.

Also könnte man doch evtl. dazu kommen, die überflüssige(?) störende Gruppierung an dieser Stelle einfach zu entfernen statt da Behelfe drumherum zu bauen.

Mir wäre es also logisch, einen solchen Hinweis anzuschauen und auszuprobieren.
>> Das Wesen von Genialität besteht darin, schwierige Dinge einfach zu machen.

 

Reden wir über das Gleiche?

Ich habe dieses Zitat auf den GROUP BY-Teil bezogen. Gruppieren muss sie wegen COUNT (*). Wenn sie gruppiert, muss sie über alle Felder gruppieren.
Wenn sie zählen will/muss und COUNT verwendet, kommt sie also um eine Gruppierung über alle Felder nicht herum. Was soll sie denn da anders machen?

Grüsse
simon