>:(
Ich stehe irgendwie neben mir......
Ich habe eine Abfrage, die den Datenbestand auf eine Gruppe Personen beschränkt, die mehr als 30 Tage Bereitschaft hatten.
Wenn ich diese Gruppe mit einer zweiten Abfrage auf die Personen beschränken möchte, die als Laufbahn "h.D." als Feldwert in der Laufbahn haben, kommt eine Meldung, das Abfragekriterium wäre zu komplex.
Bei allen anderen Laufbahnen funktioniert das.
Ich habe schon alle anderen Laufbahnen gelöscht und arbeite nur mit den Problemfällen weiter.
Gebe ich an, er soll alle Personen zeigen, die "h.D" (ohne den zweiten Punkt) in der Laufbahn haben, bringt er mir logischerweise eine leeres Ergebnis.
Was ist an der Zeichenkombination "h.D." denn so schwierig ???
Hat einer eine Idee ???
Hallo,
zeige mal die SQL-Strings der Abfragen.... (Copy&Paste aus der Abfrageentwurf/SQL-Ansicht)
Hier die Ausgangsabfrage:
SELECT Bedienstete.PersonenID, Bedienstete.Geschlecht, Bedienstete.Beamter, Bedienstete.Laufbahn, IIf([Arbeitstage]<>0,[Arbeitstage],AnzWerktagesoll([Montag_1],[Montag_2],[Dienstag_1],[Dienstag_2],[Mittwoch_1],[Mittwoch_2],[Donnerstag_1],[Donnerstag_2],[Freitag_1],[Freitag_2],[Bereit_ab],Berichte!Bereitschaft!bis,5,False,False,False,True,True,True,True,True,False,False,False)) AS Arbeitstage_berechnet, Arbeitstage.Montag_1, Arbeitstage.Dienstag_1, Arbeitstage.Mittwoch_1, Arbeitstage.Donnerstag_1, Arbeitstage.Freitag_1, Arbeitstage.Montag_2, Arbeitstage.Dienstag_2, Arbeitstage.Mittwoch_2, Arbeitstage.Donnerstag_2, Arbeitstage.Freitag_2
FROM Bedienstete INNER JOIN (Arbeitstage INNER JOIN Bereitschaften ON Arbeitstage.ArbeitstageID = Bereitschaften.ArbeitstageID) ON Bedienstete.PersonenID = Arbeitstage.PersonenID
WHERE (((Bereitschaften.Bereit_ab)>=[Berichte]![Bereitschaft]![Vom] And (Bereitschaften.Bereit_ab)<=[Berichte]![Bereitschaften]![bis]))
GROUP BY Bedienstete.PersonenID, Bedienstete.Geschlecht, Bedienstete.Beamter, Bedienstete.Laufbahn, IIf([Arbeitstage]<>0,[Arbeitstage],AnzWerktagesoll([Montag_1],[Montag_2],[Dienstag_1],[Dienstag_2],[Mittwoch_1],[Mittwoch_2],[Donnerstag_1],[Donnerstag_2],[Freitag_1],[Freitag_2],[Bereit_ab],Berichte!Bereitschaften!bis,5,False,False,False,True,True,True,True,True,False,False,False)), Arbeitstage.Montag_1, Arbeitstage.Dienstag_1, Arbeitstage.Mittwoch_1, Arbeitstage.Donnerstag_1, Arbeitstage.Freitag_1, Arbeitstage.Montag_2, Arbeitstage.Dienstag_2, Arbeitstage.Mittwoch_2, Arbeitstage.Donnerstag_2, Arbeitstage.Freitag_2
HAVING (((IIf([Arbeitstage]<>0,[Arbeitstage],AnzWerktagesoll([Montag_1],[Montag_2],[Dienstag_1],[Dienstag_2],[Mittwoch_1],[Mittwoch_2],[Donnerstag_1],[Donnerstag_2],[Freitag_1],[Freitag_2],[Bereit_ab],[Berichte]![Bereitschaft]![bis],5,False,False,False,True,True,True,True,True,False,False,False)))>30));
Und hier die aufgesetzte Abfrage:
SELECT Anz_Pers_31_Tage_ber.PersonenID, Anz_Pers_31_Tage_ber.Beamter, Anz_Pers_31_Tage_ber.Laufbahn, Anz_Pers_31_Tage_ber.Geschlecht
FROM Anz_Pers_31_Tage_ber
GROUP BY Anz_Pers_31_Tage_ber.PersonenID, Anz_Pers_31_Tage_ber.Beamter, Anz_Pers_31_Tage_ber.Laufbahn, Anz_Pers_31_Tage_ber.Geschlecht
HAVING (((Anz_Pers_31_Tage_ber.Laufbahn) Like "h.D."));
Hallo,
heiße Kiste....
Welchen Datentyp hat "Bedienstete.Laufbahn" ?
Neben dem schwer zu ertragenden Aufbau der ersten Abfrage (wenn sie denn für sich funktioniert , ist es ja gut.. ) wäre es eh besser, in der Having-Condition der zweiten Abfrage auf Like zu verzichten und "=" zu benutzen:
HAVING (((Anz_Pers_31_Tage_ber.Laufbahn) = "h.D."));
Stimmt, das Ding wuchert unglaublich........
Das mit dem = hatte ich zwar nicht in SQL verwendet, aber im Abfragegenerator habe ich schon beide Varianten verwendet. Habe auch schon die Punkte entfernt, was aber aufgrund der Deklaration als Textfeld kein Problem hätte darstellen sollen. Und ohne Punkte lief es auch nicht.
Interessant ist, ich habe im Bericht die Daten per Domänenaggregatfunktion ermittelt und die läuft auch auf Fehler.......(Nur bei der Kombination "h.D." )
Ich sehe mich, das ganze Abfragemodell neu zu gestalten, durch das arbeiten mit Access und Eure Hilfe habe ich da schon zu komplizierte Methoden entdeckt.......
Ich werde das like durch = in SQL austauschen und gleich berichten.......
Hallo,
mich verwundert auch, dass in der ersten Abfrage ein Verweis auf ein Berichts(!)-Textfeld als Kriterium steht... Was soll das bedeuten?
Und WO wird diese Abfrage verwendet?
Der Verweis auf das Berichtstextfeld liegt darin begründet, dass ich die Werte an und für sich mit der Domänenaggregatfunktion ermittle.
Es werden Berichtsoptionen abgefragt, wer der Berichterstatter ist, von welchem Datum an der Bericht generiert wird und bis zu welchem Datum der Bericht generiert wird. Die Werte werden an den Bericht übergeben und eben in diese Textfelder geschrieben. Danach verwende ich die Werte dann für die Funktionen.
Das funktioniert bei ....moment, ich zähle...... 165 Aggregatfunktionen einwandfrei..... und einige davon sind noch um einiges komplexer als die Abfrage der Laufbahn....... ich werte auch Altersgruppen aus, da ist der SQL-String auf einem 19 Zöller nicht mehr zu lesen, deswegen habe ich hier auch zwei nebeneinander.......
Ist vielleicht nicht die schönste lösung, hatte ich aber wegen des Erfolges bei den o.g. Funktionen nicht weiter in Frage gestellt.......
........
Das = bringt keine Wirkung......... :-[
Frei nach Bundeswehrmanier werde ich wohl erst mal eine Nacht drüber schlafen und Access morgen wieder bedienen. Ich befürchte temporäre Betriebsblindheit....
Hallo,
Du benutzt also diese Abfrage in einer Domänenfunktion im selben Bericht mit einem Abfragekriterium als Verweis auf ein Textfeld im selbigen Bericht ?
Und das 165 mal? Zumal sowohl in der Select-Liste als auch im Group by -Teil eine IIF() -Konstruktion und eine Funktion verwendet werden..
Ich denke mal, da wäre es angebracht, sich über den Tabellenaufbau (nochmal) Gedanken zu machen
Erstaunlich, dass sowas überhaupt (bislang) funktioniert. Eigentlich sollte eine Berichtsabfrage so einfach wie möglich gehalten werden (Nur Tabellen-Verknüpfungen und "statische" Kriterien, ohne Sortierungen und Gruppierungen). Besondere Berechnungen , besonders in Abhängigkeit vom aktuellen Datensatz und Sortierung/Gruppierung werden im Bericht selber veranstaltet (aber nicht mit 165 Dom-Funktionen ) ;-)
"Komplex" kann auch darauf hindeuten, dass insgesamt der Abfrage-SQL-String zu viele Zeichen aufweist..., vermutlich weiß aber Access nicht, was es eigentlich machen soll..
;D
Rein amerikanische Herangehensweise........schnelle Maschine, viel Speicher, 2 Monitore......
Was kostet die Welt......
Und dann merkt man, dass es so gar nicht geht.......
:o
Ich gebe Dir vollkommen recht, ich muss glaube ich viel früher mit meinen Änderungen ansetzten.........
Die ersten 2-3 Tausend Datensätze lang hat es gewirkt...... und jetzt vermute ich eine nicht bedachte Kombination von Eingabenotwendigkeiten, die mir Löcher reisst.......
Zitat165 Aggregatfunktionen ... und einige davon sind noch um einiges komplexer als die Abfrage der Laufbahn
Eine Domänenaggregatfunktion ermittelt genau einen Wert und ist daher bestenfalls für einen Einzelnutzung vorgesehen. Und eine Domänenaggregatfunktion arbeitet in der Regel uneffektiv (was bei einer Einzelabfrage nicht auffällt), da jedesmal ein Tabellenzugriff erfolgt und eine schlechte Indexnutzung vorliegt.
Effektiver wäre es, aus 165 Einzelabfragen + X eine Abfrage zu erstellen.
MfGA
ebs
Genau das war eben mein Gedanke,
ich berechne mir alle Werte in Einzelabfragen und übernehme sie dann in den Bericht.......
Aber es ist ja nicht so, dass die Funktionen auf Tabellen aufsetzen, die holen sich die Daten ja schon von Zwischenabfragen......
Der gerade umgekippte Ansatz war aber, nicht ganz soviele Zwischenabfragen verwalten zu müssen, sondern in einem Bericht ggfls. verschiedene Aggregatfunktionen anpassen zu müssen......
Wenn Der Bericht sich verändert.....er ist nämlich nicht von mir gesteuert, muss ich derzeit nur in das jeweilige Berichtsfeld und die Kriterien ändern. Künftig muss ich mir die zum Feld gehörende Abfrage(-n) suchen und diese anpassen......
Vielleicht sollte ich zu meiner Entlastung noch erwähnen, dass der Bericht 1 mal im Jahr gezogen wird, da durfte er ruhig 2 Minuten Zeit haben, um sich zu berechnen.......
Bei einer häufigeren Berichtserstellung hätte mich die Performance durchaus mehr interessiert....
???
Mannomannomann.
Jetzt versuche ich, die Sollarbeitstage zu berechnen. Es gibt 4 Abfragen, die verschieden Konstellationen berechnen.
1. Wenn jemand z.B nur 4 Arbeitstage die Woche hatte, im Zeitraum vor dem Berichtszeitraum, bis inmitten des Berichtszeitraumes, werden hier die Sollarbeitstage von Beginn des Berichtszeitraumes, bis Ende des damaligen Arbeitszeitmodells berechnet.
2. Wenn jemand von vor dem Berichtszeitraum bis nach Berichtszeitraum ein Arbeitszeitmodell hatte, wird mir berechnet, wieviel Arbeitstage er im Berichtszeitraum hatte.
3. Wenn jemand von inmitten des Berichtszeitraumes bis über das Ende des Berichtszeitraumes hinaus ein besonderes Arbeitszeitmodell hatte, werden mir die Sollarbeitstage von Beginn des Arbeitszeitmodells bis Ende Berichtszeitraum berechnet.
4. wenn jemand von inmitten des Berichtszeitraumes bis inmitten des Berichtszeitraumes ein besonderes Arbeitszeitmodell hatte, werden mir dafür die Sollarbeitstage berechnet.
Eine fünfte Abfrage soll das alles addieren und mir die gesamten Sollarbeitstage aller Personen anzeigen.
An und für sich alles klar.
ABER
es gibt eine Variante, die bei keinem zutrifft. also bleibt das Feld in der Abfrage leer. Wie sage ich ihm jetzt, dass er das leere Ergebnis durch eine Null ersetzen soll ? Denn die Addition funktioniert nicht, wenn ein Feld leer ist.
das hier klappt nicht:(Ist zusätzlich noch nach Geschlecht gruppiert)
SELECT NZ(Sum(AnzWerktagesoll([Montag_1],[Montag_2],[Dienstag_1],[Dienstag_2],[Mittwoch_1],[Mittwoch_2],[Donnerstag_1],[Donnerstag_2],[Freitag_1],[Freitag_2],[ATvon],[ATbis],5,False,False,False,True,True,True,True,True,False,False,False)),Int(0)) AS Soll2, Bedienstete.Geschlecht
FROM Bedienstete INNER JOIN Arbeitstage ON Bedienstete.PersonenID = Arbeitstage.PersonenID
WHERE (((Arbeitstage.ATvon)>=[Formulare]![Berichtsoptionen]![Vom]) AND ((Arbeitstage.ATbis)<=[Formulare]![Berichtsoptionen]![bis]))
GROUP BY Bedienstete.Geschlecht;
Hallo,
offensichtlich musst Du leere Felder schon bei der Berechnung in der Funktion "AnzWerktagesoll" berücksichtigen.
;D
Oder ich addiere in der 5. Abfrage so:
Ausdr1: NZ([Soll1];Int(0)) + NZ([Soll2];Int(0)) .......
Hat lange gedauert, ist aber doch noch aufgefallen......
Mann, wird man blind.......
Aber da tut sich mir eine neue Frage auf,
mir wurde mal beigebracht, dass Abfragen nur Felder berücksichtigen, die im Abfragegenerator aus der Ursprungstabelle in die Abfragetabelle gezogen wurden.
Ich beobachte aber gerade, dass Felder vollkomen richtig berechnet werden, obwohl die zugrundeliegenden Felder nicht in die Abfrage als Feld eingefügt wurden. Sie werden zwar oben in den Tabellen angezeigt, die der Abfrage zugrunde liegen, ich habe sie aber nicht in die Abfragetabelle hinuntergezogen....ist das normal ?
Hallo,
ja, das ist normal, die Spalten in der Abfrage sorgen ja nur für die Anzeige der felder, sofern "Anzeigen" angehakt ist. Nichtsdestotrotz kann auf die Tabellenfelder Bezug (im SQL-Statement) genommen werden, ohne dass sie in der Select-Liste auftauchen müssen.
"Oder ich addiere in der 5. Abfrage so"
klar geht das auch, aber damit umgehst Du den Vorteil einer Funktion, in der Du das Ganze nur EINMAL machen mußt und nicht an all den Stellen, an denen die Funktion aufgerufen wird.
Was soll
Ausdr1: NZ([Soll1];Int(0)) + NZ([Soll2];Int(0))
für einen Sinn haben?
Eine 0 hat schon in VBA den Datentyp Integer( bzw. Long) und braucht nicht nochmal explizit in denselben Datentyp konvertiert werden.
Ok, werde mir die Funktion ansehen.... weiss noch nicht genau, wo ich das unterbringe, aber ich werde sehen.
Int(0) hat sich eingeschlichen. Bei den ersten Versuchen bekam ich ein Ergebnis jenseits der Billionengrenze und da wollte ich sichergehen, dass die "0" auch als 0 gehandelt wird. Seitdem schreibe ich es so fort..........
Ups,
habe mir die Funktion angesehen, aber ........
Die Funktion wird aufgerufen (aus der Abfrage), wenn ein Datensatz kommt, der die anderen Kriterien erfüllt und rechnet dann die Werktage aus.
Aber in dem vorliegenden Fall habe ich ja keinen Datensatz, da die anderen Kriterien nicht erfüllt werden. Also wird sie ja gar nich aufgerufen.....
Ausser für den Bericht brauche ich die Solltage nicht, daher werden die auch nicht in irgendeine Tabelle gespeichert, sondern nur für den abgefragten Zeitraum berechnet........
Hallo,
???
"Aber in dem vorliegenden Fall habe ich ja keinen Datensatz, da die anderen Kriterien nicht erfüllt werden. Also wird sie ja gar nich aufgerufen...."
Wenn die Funktion nicht aufgerufen wird, wieso soll es dann ein leeres Feld geben?
Haha,
da hast Du mich voll erwischt.......
Ist natürlich kein leeres Feld......
sondern, da die Abfrage ja nach Geschlecht sortiert, ein Abfrageergebnis, mit nur einer Ergebniszeile und nicht mit zwei, wie bei den anderen.......
Das Feld ist nicht leer, es fehlt einfach.....
Sry für die ungenaue Ausdrucksweise 8)
Obwohl..... ich hatte das auch schon als Einzelabfrage, die nur ein Feld als Ergebnis liefern sollte. Und da war dann tatsächlich ein leeres Feld....auch wenn kein Datensatz die Kriterien erfüllte.
Hallo,
ich wiederhole:
Zitat
Ich denke mal, da wäre es angebracht, sich über den Tabellenaufbau (nochmal) Gedanken zu machen
Vermutlich ist da zuviel verkorkst....
Wenn ein Feld "fehlt" (bzw. fehlen kann) , ist das an sich nicht in Ordnung und ist eine Vergewaltigung der Struktur. Sorg dafür, dass immer ALLE Felder existieren, auch wenn sie "NULL enthalten" (z. B. durch Verwendung von Alias-Namen) , dann fiele wenigstens dieser Stolperstein weg.
Hm,
da verstehe ich das Problem nicht.
Es gibt kein Tabellenfeld, dass "fehlt". Es gab nur ein Abfragefeld, das kein Ergebnis hatte. Dadurch wurde in einem gruppierten Abfrageergebnis die Zeilenanzahl von 2 auf 1 reduziert.
Es ist doch gerade Aufgabe einer Abfrage, auch nach Datensätzen zu suchen, die keine Kriterien erfüllen. Die könnte man sich postitiv anzeigen lassen. Aber sie negativ einfach wegzulassen und dann kein Abfrageergebnis zu bekommen, ist doch wohl gleichwertig.
Oder sehe ich das falsch ?
Hallo,
eine Abfrage (SQL-Statement) ist doch nicht prozedural, sondern deklarativ.. D. H. es wird eine Aufgabe (für die Datenauslesung) nur BESCHRIEBEN , der eigentliche Ausführungsvorgang ist uninteressant und geschieht im Hintergrund. Insofern liefert eine Abfrage genau die Datensätze, die dem angegebenen Kriterium entsprechen..... und nicht (auch) die, die gar nicht gewünscht sind.
ZitatDadurch wurde in einem gruppierten Abfrageergebnis die Zeilenanzahl von 2 auf 1 reduziert.
Eine gruppierende Abfrage liefert eben eine Zusammenfassung der Datensätze. die den Gruppierungsbedingungen entsprechen, in Form EINES Datensatzes... Dann ist ein Zugriff auf die Einzeldatensätze einer Gruppe in derselben Abfrage nicht mehr möglich. Dazu ist dann eine weitere normale Abfrage nötig, die die Gruppenabfrage als Kriterium(swerte-Lieferant) verwendet.
Es ist doch gerade Aufgabe einer Abfrage, auch nach Datensätzen zu suchen, die keine Kriterien erfüllen.
Für Dich wäre die Welt in Ordnung, wenn man zwar bspw. einen Ortsfilter auf Berlin setzt, aber trotzdem die ganze Welt gezeigt wird?
Wenn das so wäre, ginge die Welt für viele andere unter.
Eine Abfrage/SQL-Anweisung macht genau das, was ihre Definition (die SQL-Anweisung) beinhaltet. Lege also Deine Wünsche so in die Anweisung, dass die Jet-Engine Dich versteht, und dann wird sie im Rahmen ihrer Möglichkeiten und der vorhandenen Daten Dir gnadenlos zu Dienste sein.
MfGA
ebs
So meine ich das doch gar nicht. :-\
Ich lasse mir eben nicht die ganze Welt anzeigen.
Aber neben der Fragestellung, ich bleibe mal bei Orten, wer alles in Berlin sitzt, kann ich doch auch gruppiert fragen(!), wer alles in Frankfurt sitzt (Ausgabe nur die Anzahl der PersonenID's). Wenn dann für Frankfurt das Ergebnis "leer" ist, weiss ich doch, dass es niemanden in Frankfurt gibt.
Natürlich frage ich positiv, wieviele Männer und Frauen (Gruppierung) haben unterjährig ihr Arbeitszeitmodell gewechselt.
Da es aber keinen Mann gibt, der dieses Kriterium erfüllte, lieferte die Abfrage nur eine Gruppenzeile, nämlich für Frauen. Und das "fehlende" Abfragefeld für die Anzahl der Männer konnte ich nicht in eine Addition fassen.
Ich suche nicht explizit nach nicht kriterienerfüllenden Datensätzen. Aber die logische Umkehrfolge des Nichterfüllens der Abfragekriterien liefert mir die Gewissheit, da gibt es keinen. Und das will ich eben auch wissen.
Und eine gruppierte Abfrage liefert nicht nur EINEN Datensatz, sondern mehrere, wenn es mehrere Gruppen gibt.
Würde ich männlich, weiblich,zwitter,asexuell als Gruppierung einrichten, hätte ich vier Datensätze im Ergebnis, wenn es zu jedem einen Eintrag in der DB gäbe.....
Hallo,
ZitatUnd eine gruppierte Abfrage liefert nicht nur EINEN Datensatz, sondern mehrere, wenn es mehrere Gruppen gibt.
Würde ich männlich, weiblich,zwitter,asexuell als Gruppierung einrichten, hätte ich vier Datensätze im Ergebnis, wenn es zu jedem einen Eintrag in der DB gäbe.....
Das stimmt und Du hast mich missverstanden.. :) Ich meinte genau dies:
Wenn es 50 DS mit "männlich" und 25 mit "weiblich" gibt, erzeugt die Gruppenabfrage genau einen DS für jede Gruppe...
ZitatAber die logische Umkehrfolge des Nichterfüllens der Abfragekriterien liefert mir die Gewissheit, da gibt es keinen. Und das will ich eben auch wissen.
Naja, da kannst Du doch auch abfragen, welche DS den Abfragekriterien nicht entsprechen.
z. B. select ...... where xyz not in (Select xyz ..... where abc='irgendwas')
oder alternativ auch mit Exists
oder mittels left Join und Kriterium "is Null" bei einem "nicht existierenden" Feld.
http://www.donkarl.com/?FAQ3.16
Da könnte man ja glatt Plausibilitätsprüfungen draus machen......
Da könnte man doch prüfen, ob die Anzahl der erfüllenden und der nichterfüllenden Datensätze jedes Kriteriums die Gesamtzahl der Datensätze wiedergibt......
Vielleicht sollte ich mir das doch überlegen, auch die DS abzufragen, die nicht die Kriterien erfüllen....... ::)
Hallo,
ZitatDa könnte man doch prüfen, ob die Anzahl der erfüllenden und der nichterfüllenden Datensätze jedes Kriteriums die Gesamtzahl der Datensätze wiedergibt......
und was würde Dir das für Erkenntnisse bringen ?
Da kannst Du genauso prüfen, ob die Addition der Höhe des Wasserstandes in Deiner Regentonne mit der Höhe der darüber liegenden Luftsäule tatsächlich auch die Höhe der Regentonne ergibt... ::)
ZitatDa es aber keinen Mann gibt, der dieses Kriterium erfüllte, lieferte die Abfrage nur eine Gruppenzeile, nämlich für Frauen.
Wenn das Ergebnis aber auch die Männer anzeigen soll, obwohl es da keine Datensätze gemäß Verknüpfung und Filterung zum Gruppieren gibt, dann hast Du Deine Abfrage falsch formuliert.
Dann musst Du also erst eine vollständige Menge im Sinne der späteren Auswertung erzeugen, und dann erst kannst Du Gruppieren/Aggregieren oder irgendwie anders auswerten.
MfGA
ebs
Das würde mir zumindest für die Zeit der Erstellung aller Abfragen des Berichtes (ich erinnere, ich hatte mehr als 165 DomFunktionen) die Sicherheit geben, dass ich in den nach Alter, Geschlecht, Laufbahn und Dauer untergliederten Berichtsergebnissen auch alle erfasst habe und nicht irgendwo ein Fehler in einem Kriterium Steckt, das mir falsche Werte liefert.
Dummerweise kann man den Bericht selber nämlich nicht vollständig auf Plausibilität prüfen. Und der ist.... nicht von mir.
Aber jetzt bedanke ich mich, denn die Ausgangsfrage ist ja geklärt.
Werde den Thread auf gelöst setzen.