Hallo,
wie handhabt ihr das, wenn man für eine Auswertung ca. 50 Abfragen braucht, diese Ergebnisse müssen in eine Exceltabelle exportiert werden
Es müssen z.B. abgefragt werden:
Wieviel Mitarbeiter
Wieviel männlich
Wieviel weiblich
Wieviele über 40
Davon männlich
Davon weiblich
Wieviele haben Qualifikation X
Davon männlich
Davon weiblich
Usw. Mein erster Ansatz wäre ich erzeuge tatsächlich diese 50 Abfragen und exportiere sie in eine Exeltabelle.
Dann hab ich aber auch 50 Abfragen in meiner Übersicht stehen, was sehr unübersichtlich ist, leider kann man diese ja nicht in einer zusammenklappbaren Gruppe zusammen fassen.
Eine andere Idee wäre eine parameter gesteuerte Abfrage zu erstellen und diese mit einer VBA Schleife durchlaufen lassen und dann in jedem Durchlauf die Parameter anpassen.
Oder noch anders?
Was ist da die korrekte, oder beste Vorgehensweise?
Grüße
Was ich hier lese: Du hast eine Abfrage und etwa 50 Filterungsvarianten. Also wäre es bestenfalls ein Thema, diese Filterungen für eine automatisierte Ausgabe geeignet zu abzulegen.
Wie soll das Ganze in Excel ankommen? Ich kann mir nicht vorstellen, dass sich jemand in einer Excelmappe 50 Tabellen mit eigentlich den gleichen Leuten ansehen will.
Mhh
In Excel gibt es nachher nur wie oben gezeigt diese AbfrageErgebnisse (männlich, weiblich...) mit Zahlen ausgefüllt.
Ich dachte sowas wie eine Grundabfrage wo ich mehrere Parameter optional setzten kann.
So soll später das Endergebnis aussehen:
Anzahl Mitarbeiter gesamt = z.B. 60
Davon männlich = 40
Weiblich = 20
Anzahl Mitarbeiter mit Führerscheim C = 40
.... (also eine Mappe mit 50 Zeilen)
Diese ganzen mini Abfragen müsste ich jetzt erstellen, und das geht bestimmt eleganter als 50 mini Abfragen zu bauen.
Es soll also kein Name etc auftauchen, nur eine Gesamtübersicht mit Summenwerten
PS: Mit mini Abfragen meine ich z.B. Zähle alle Mitarbeiter, oder zähle alle Mitarbeiter mit Führerschein C
ZitatAnzahl Mitarbeiter gesamt = z.B. 60
Davon männlich = 40
Weiblich = 20
Das ließe sich im Stück mit einer Kreuztabellenabfrage ermitteln, mit dann zusätzlichen Filtern auch für entsprechende Qualifikationen usw.
Zitatalso eine Mappe mit 50 Zeilen
Da bei diesen Abfragen auch mehrere Spalten anfallen, wäre mit der genannten Forderung eine Umformatierung der Abfrageergebnisse erforderlich.
Also würde ich resultierend die Excelmappe per Automation erstellen, die Abfrage in einer VBA-Schleife anpassen und auswerten und die Ergebnisse zellenweise übertragen.
Ja so hab ich mir das auch gedacht.
Werd mich mal Sonntag dran setzen.
Hallo Xoar,
statt mehrere Abfragen per VBA abzuarbeiten, könntest du auch eine Abfrage benutzen und diesen Recordset dann DS für DS interpretieren.
Schema (Luftcode):
dim arrqualiS() as string
dim arrqualiC() as integer
<recordset öffnen>
do while not rs.eof
intcount = intcount+1 'Gesamt-Zähler
if rs!Geschlecht = "M" then
intcountM = intcountM+1 'Zähler männlich
else
intcountW = intcountW+1 'Zähler weiblich
endif
'quali auswerten-----------------
strtest = rs!quali
j=ubound(arrqualiS)
bfound=false
for i = 0 to j
if arrqualiS(i)=strtest then
arrqualiC(i)=arrqualiC(i) +1
bfound=true
exit for
endif
next
if not bfound then
redim preserve arrqualiS(j+1)
redim preserve arrqualiC(j+1)
arrqualiS(j+1)=strtest
arrqualiC(j+1)=1
endif
'quali auswerten Ende---------------------
<entspr. für Führerschein>
usw.
rs.movenext
loop
So ungefähr könntest du z.B. für die Qualifikation die verschiedenen Werte einzeln zählen und am Ende zweispaltig in die Excel-Tabelle schreiben (Spalte 1 = Quali-Text, Spalte 2 = Zähler). Entsprechend für andere Access-Felder, in denen versch. Werte vorkommen können (Führerschein).
Auch könntest du z.B. beim Alter zusätzlich 10er-Gruppen bilden (bis 20, 21-30, 31-40 usw.) und andere Berechnungen ausführen, auch verschiedene Merkmale zusammen betrachten (Geschlecht + Führerschein) und am Ende alles in eine Excel-Tabelle ausgeben.
Damit hättest du alles in einer VBA-Routine und nur eine Abfrage, die schlicht alle zu betrachtenden Felder nebeneinander darstellt.
Vielleich gefällt dir diese Idee.
lg
crystal
Tja crystal, man könnte auch über die Ansicht der Daten lang genug meditieren, und diese dann aus der Erinnerung in Excel eintragen, dann bräuchte man weder Abfrage noch VBA Spaghetti-Code - wäre doch auch recht schön, oder? ;D
@Lachtaube
Ich weiß schon, dass "Lach" in deinem Namen nicht von "Lachen", sondern von "Lache, Wasserlache" stammt. Aber gerade zweifle ich etwas...
Statt die gewünschten Summen bzw. Zähler per VBA mit diversen einzelnen Abfragen zu ermitteln, wäre mein Ansatz durchaus überschaubar, flexibel und aus meiner Sicht nachvollziehbar. Gut, das ist Ansichtssache, aber doch nicht lachhaft. Statt mit Kreuztabellen- und DOM-Abfragen zu hantieren (deren Ergebnisse ja auch noch irgendwie interpretiert werden müssen), ist mein Ansatz vielleicht primitiv, aber straight forward, ergebnisorientiert und vermutlich einfacher zu pflegen.
Letztlich ist dein Kommentar überflüssig - und meiner deshalb auch.
Grüße
crystal
Gut, wer das Meditieren nicht mag, könnte die Kriterien (ggf. nebst Beschriftung für die Excel-Ausgabe) ja auch in einer Tabelle vorhalten - Teigwaren :) , wie Spaghetti (speziell als Code) mag ich jedoch nicht.
@crystal
Im Hinterkopf hatte ich auch schonmal die Idee mit nem Array, aber damit habe ich noch nie gearbeitet.
Ich schau mir das ganze mal an und schau dann was für mich besser geeignet ist.
Danke für die Tipps!
@Xoar: Ist es vorstellbar, dass man effiziente Lösungen auf eine bekannte Ausgangssituation, also auf eine bekannte Tabelle/Abfrage aufbaut?
Wenn es möglich ist, in einem einfachen Durchlauf über alles alles Gewollte zu zählen, dürfte auch eine einfache Gruppierung + Aggregierung über alles genügen. Das wäre dann auch eine Abfrage. VBA wäre dann nur für den Übertrag nach Excel und die Umformatierung Spalten in Zeilen nötig (wobei es in Excel auch Transpose-Funktionalitäten gibt).
Ne das klappt wohl nicht, da ich z.B. Qualifikationen in einer n:m Tabelle habe.
Ich probiere es Sonntag mal aus, wie ichvdie Abfrage zusammen stellen kann, obs in einer einzelnen zusammenfügbar ist, oder nicht.
SQL bin ich nur anfängerbegabt.
ZitatSQL bin ich nur anfängerbegabt.
Wenn man in Datenbanken
vernünftig programmieren will, sollte man sich mit der dortigen nativen Sprache auseinandersetzen:
Grundlagen - SQL ist leicht (0) - Vorspiel (http://www.ms-office-forum.net/forum/showthread.php?t=317692)
Was nutzt es dem Autofahrer, wenn er gut rennen kann, er aber keine Ahnung vom Gasgeben und Schalten hat? Nun, ans Ziel könnte er auch kommen ...
Ich sags mal so, ich fahre den Polo und nicht den Ferrari. Aber ja, über kurz oder lang werd ich nicht drum herum kommen, die ganzen Sum, Count Befehle etc mir genauer anzusehen
Hallo,
offensichtlich gibt es in Xoar's Datenbestand Felder, die verschiedene diskrete Werte annehmen können (z.B. Quali, Führerschein). Für jedes diese Felder nun eine KT-Abfrage zu erstellen, ist doch recht aufwändig. Deshalb meine Idee, diese Felder selbst in Arrays zu unterscheiden und zu zählen.
Ich halte diese Idee weder für lachhaft noch für illegitim, sondern für geradlinig zum Ziel führend. Insofern betrachte ich gewisse Kommentare als überflüssig, herablassend und polemisch.
Am Ende zählt das Ergebnis. Lassen wir Xoar ein paar Tage Zeit, sich mit den Lösungsvorschlägen auseinander zu setzen. Mein Vorschlag ist jedenfalls der konkreteste und direkt umsetzbar - vielleicht abgesehen von Syntaxfehlern. Andere Vorschläge hingegen sind eher nach dem Motto gestrickt "Meine Majestät wissen da auch noch was" und leider nicht konkret.
Es ist eben nicht möglich, einfache Count-Funktionen für die verschiedenen Felder zu nutzen, sondern zumeist muss man "wieviel von was" zählen. Deshalb "passt" mein pragmatischer Ansatz, zumal man den Block aus meinem Beispiel nur kopieren und kleine Anpassungen machen muss. Man könnte das auch auslagern, aber das führt jetzt etwas zu weit (zwei-dimensionale Arrays).
SQL ist nicht alles und hat erhebliche Mängel, die es von einer Programmiersprache unterscheidet. Und wäre SQL so vernünftig, wie angedeutet wurde, brächte man nicht zusätzlich eine andere Programmiersprache, um die SQL-Ausgaben zu interpretieren. Dem Autofahrer nutzt es auch nichts, Gas geben und schalten zu können - er muss auch lenken können, auf die Straße achten und wissen, ob er einen Kleinwagen, Bus oder LKW fährt. (Mal abgesehen davon, dass dieses Autofahrer-Beispiel - wie so häufig - absolut nichts zur Sache beiträgt.)
Ich könnte auch schreiben: Wenn man mit Access vernünftig arbeiten möchte, muss man sich zunächst einige Bücher kaufen und durcharbeiten und mindestens einen Kurs bei xyz belegen. Aber das bringt nichts und ist eher destruktiv und hochnäsig.
Freundliche Grüße an alle
crystal
Hallo crystal,
ZitatWenn man mit Access vernünftig arbeiten möchte, muss man sich zunächst einige Bücher kaufen und durcharbeiten
Besser isses aber, und später deutlich einfacher.
Ich habe, als mit A2K angefangen habe, einen 1.200 Seiten Wälzer durch!gelesen,
zwar damals nur die Hälfte verstanden, aber hinterher gewusst wonach ich bei
Problemen suchen bzw. fragen musste, und da ging das Lernen erst richtig los; -
und hört nicht auf.
gruss ekkehard
Ist ja auch alles richtig, wenn man weiß wie es gehts, ist es einfach.
Das schöne an diesem Forum ist ja, dass einem oftmals viele Wege nach Rom gezeigt werden, mit ihren Vor-/Nachteilen
Ich habe natürlich auch son DataBecker Access 2007 Buch, steht auch viel drin, schlage ich auch nach, das komplettiert sich dann mit dem enormen Fachwissen aus diesem Forum.
Lieber Ekkehard,
also ich habe mit Access 2 angefangen und natürlich auch einige Bücher gelesen, so dass ich weiß, wo was steht. Natürlich auch Bücher, die sich z.B. nur mit SQL beschäftigt haben.
Bücher und andere Wissensquellen sind absolut wichtig, denn wir wollen ja lernen, wenn wir uns in das Wagnis stürzen, z. B. eine Access-Anwendung zu entwickeln.
Insofern ist mein Lösungs-Ansatz in diesem Thread als EINE Möglichkeit anzusehen, die gewünschten Informationen pragmatisch, schnell, nachvollziehbar zu erhalten und ich habe auch etwas Code entworfen, der zu einer solchen Lösung führen könnte. Andere Menschen, die sich scheinbar gewissen Paradigmen unterworfen haben, offerieren hier keine konkreten Lösungsansätze, sondern nur allgemeine Lehrbuch-Meinungen.
Ob meine Lösung nun die beste wäre, sei dahingestellt. Jedenfalls ist sie auf Basis von jahre- oder sogar jahrzehntelangen Lesens von Büchern, Artikeln in Fachzeitschriften und praktischer Erfahrung entstanden.
Und natürlich ist das Wissen, das ich mir so angeeignet habe, sehr wichtig und natürlich empfehle ich jedem Access-Neuling, zunächst selbst zu versuchen, sich Wissen mit Büchern, Hilfetexten usw. anzueignen. In zwei Jahren wird Xoar vielleicht eine eigene Lösung für seine Fragestellung kennen. Hier geht es zunächst jedoch darum, ihm eine einfache Lösung vorzuschlagen, die er Schritt für Schritt nachvollziehen kann, um seine eigenen Erkenntnisse zu gewinnen. Und ich fürchte, dass es kaum ein Buch gibt, dass die Fragestellung umfassend beantworten könnte, obwohl ich davon ausgehe, dass er durchaus einige Bücher besitzt und einiges im Internet gelesen hat.
lg
crystal
Lieber Xoar,
wie wäre es mit einem kleinen Wettbewerb?
Stelle eine anonymisierte, vereinfachte DB zur Verfügung (ca. 200 Datensätze in der Haupttabelle), dazu eine Liste aller zusammenfassenden Daten, die du haben möchtest.
Dann könnten wir Lösungen bauen, die eine Fraktion mit Abfragen, ich mit meinem "Spaghetti-Code" und am kommenden Mittwoch 12 Uhr (Deadline) gegenüberstellen.
Nur so eine Idee.
lg
crystal
Ich werd gucken was ich Sonntag vorbereiten kann.
Ja Xoar, da könntest Du erleben, wie man eine (1) Abfrage aus Daten macht, wo Du glaubst, 50 Abfragen zu brauchen.
crystal hat da als einziger einen konkreten Vorschlag, er braucht da nicht mal vorhandene Strukturen kennen. Selbstlob kann vieles ersetzen.
Andere sind halt so hochnäsig und dumm und haben erst Lösungen, wenn sie auch die Ausgangssituation kennen.
Hallo Xoar,
das wäre eine tolle Sache!
Die Strukturen scheint ebs17 ja bereits zu kennen, wenn ich mir seine bisherigen Antworten anschaue...obwohl er sich dann widerspricht.
Und speziell @ebs17:
Du hast mich auf deine Ignorierliste gesetzt, so dass ich dir keine persönliche Mitteilung schicken kann. Du hast zuvor mitgeteilt, dass du auf meine Aussagen nicht mehr eingehen wirst. Also halte dich bitte daran. Von mir zum Schluss an dich eine Frage: Was ist ein Despot? Einer, der alle anderen für dumm hält, insbesondere diejenigen, die seine Größe nicht erkennen.
Hallo,
ich schaetze ja alle Antworten in diesem Forum, aber ein Wettbewerb wo man mal zwei Wochen sich nicht attackiert wird wohl momentan am besten sein.
Ich bin auch fuer klar eine Loesung, aber das tut nichts zur Sache und ich denke es geht in diesem Forum nicht darum Wettbewerbe zu veranstalten.
Sorry da meine "5 cents" dazu zugeben, aber ich sehe das schon laenger so.
Gruss
ZitatJedenfalls ist sie auf Basis von jahre- oder sogar jahrzehntelangen Lesens von Büchern, Artikeln in Fachzeitschriften
Womit du allerdings deiner, von mit kommentierten, Äusserung widersprichst.
Chrystal,
ach ja und zu deinem
ZitatJedenfalls ist sie auf Basis von jahre- oder sogar jahrzehntelangen Lesens von Büchern, Artikeln in Fachzeitschriften und praktischer Erfahrung entstanden.
von heute steht dein
Zitatich bin neu hier und leider habe ich wenig Erfahrund mit Access.
vom 05.03.2016 etwas Im Gegensatz.
Wie auch immer deine Ideen und Ansaetze sind sehr interessant und bestimmt nicht immer vom Tisch zu wischen. Im generellen sollte man aber in der Programmierung, wo auch Access Datenbanken fuer mich reinfallen, die grundsaetzlichen Regeln beachten.
Ich behersche das auch nicht mehr fehlerfrei, aber ich achte in meinem Team klar auf Einhaltung dieser regeln, weil wir kommerziele Anwendung betreiben.
Gruss
Hallo HB9876,
ich sehe das eigentlich genauso. Aber ich wurde ja durchaus etwas provoziert (Kommentar von Lachtaube), so dass ich mich gezwungen sah, meine Meinung kund zu tun. So ist es dann etwas eskaliert.
Ich habe schon öfter mitgeteilt, dass es in diesem Forum darum geht
1. Fragestellern konkret weiter zu helfen (oder es zumindest nach Wissen und Gewissen zu versuchen) und
2. sachlich und fachlich fundiert zu diskutieren sowie
3. meine persönliche Auffassung von Access und VBA-Programmierung dargestellt, die manchmal vom "Mainstream" abweicht.
Ich behaupte nicht, die Wahrheit gepachtet zu haben und ich mache Vorschläge anderer nicht lächerlich. Ich stehe dazu, oft andere Lösungen zu sehen. Wenn meine Ideen dann zu einem sachlichen Dialog führen, ist das gut und bewirkt auch etwas Nachdenken beim Fragesteller und Mitlesern. Oft erfolgt aber keine sachliche Diskussion, keine Auseinandersetzung mit meiner Idee, sondern nur Polemik oder Zynismus aus einer Position des selbsternannten Wissens-Gurus. Klar, dass ich mich dagegen wehre.
Deshalb auch die Idee mit dem "Wettbewerb": sollen doch bitte alle, die sich berufen fühlen, ihre Lösung präsentieren - dann kann man diese Lösungen gegenüberstellen, analysieren, darüber diskutieren. Am konkreten Beispiel und nicht an irgendwelchen Allgemein-Aussagen, mit denen der Fragesteller oft nichts anzufangen weiß.
Soll dieses Forum nicht konkrete, nachvollziehbare Lösungen bieten? Sollen nicht konkrete, zielgerichtete Antworten gegeben oder alternative Lösungswege aufgezeigt werden, auch wenn sie nicht immer dem Mainstream entsprechen?
Mich stört etwas, dass hier oft Antworten bzw. Kommentare abgegeben werden, die zur Lösung der Frage substanziell nichts oder nur wenig beitragen. Wenn z.B. in diesem Thread gesagt wird, dass eine Lösung mit per VBA modifizierten Abfragen möglich wäre, fehlt mir der konkrete Beweis und das Beispiel.
Und deshalb: warum nicht Lösungen nach persönlichen Vorlieben und Vorstellungen erarbeiten und sie parallel zur Diskussion stellen?
lg
crystal
PS: mein Statement vom März 2016 war deshalb so geschrieben, weil ich als Forums-Neuling eine möglichst "nachsichtige" Antwort bekommen und auch erfahren wollte, wie andere Forums-Teilnehmer auf meine Frage eingehen würden.
Zitatmein Statement vom März 2016 war deshalb so geschrieben, weil ich als Forums-Neuling eine möglichst "nachsichtige" Antwort bekommen und auch erfahren wollte, wie andere Forums-Teilnehmer auf meine Frage eingehen würden.
Beim Poker nennt man das Slow-Play mit 'nem Pocket-Pair Könige. ;)
Hallo,
OT:
ZitatIch habe schon öfter mitgeteilt, dass es in diesem Forum darum geht
1. Fragestellern konkret weiter zu helfen (oder es zumindest nach Wissen und Gewissen zu versuchen) und
2. sachlich und fachlich fundiert zu diskutieren sowie
3. meine persönliche Auffassung von Access und VBA-Programmierung dargestellt, die manchmal vom "Mainstream" abweicht.
Und ich teile mit 8) , dass es diesem Forum darum geht:
Fragestellern konkret sachlich und fachlich fundiert weiter zu helfen und dabei gewisse Eigeninitiative und Grundkenntnisse beim Fragesteller vorauszusetzen.
"konkret" heißt, kurz und bündig wie möglich die Lösung zu nennen, und keine Diskussionen um des Kaisers Bart anzuzetteln.
"fachlich" heißt: Lösungen entspr. der allgemein anerkannten Grundsätze/Grundlagen bezüglich des Themas (hier Access-Datenbanken) anzubieten.
"sachlich" heißt: das Frage-Thema behandeln und persönliche Wertung anderer zu unterlassen.
Es geht NICHT darum, persönliche Meinungen über das Für und Wider zu den o. g. allgemein anerkannten Grundsätzen zur Diskussion zu stellen. Wir haben hier kein "Windows-Linux-Glaubenskonflikt-Forum". :) ;D
und nicht zuletzt: Die Diskussion in einem Thread sollte mit dem Threatstarter stattfinden und sich nicht unter den Antwortgebern selber abwickeln.
Lieber Franz,
(leider hast du den Titel der Anfrage auf OT geändert).
Wir meine eigentlich beide das Gleiche, drücken es nur anders aus.
Ich versuche normalerweise immer, auf die Fragen des Thread-Starters einzugehen. Manchmal finde ich jedoch Reaktionen, die nicht unbedingt geeignet sind, zu einer sachlichen Diskussion beizutragen, so dass ich mich genötigt sehe, darauf zu reagieren.
Mich stört besonders, wenn arrogant getönte Antworten ohne konkreten Bezug gegeben werden (und auch noch mit "Beispielen" aus dem täglichen Leben, bei denen man sich nur fragt: "Was will uns der Autor damit sagen?". Und Eberhard ist scheinbar Spezialist dafür.
Und ja - ich verstehe mich durchaus auch als "advocatus diavoli", so was zu kritisieren und dazu beizutragen, dass sich Fragesteller nicht entrüstet und frustriert zurückziehen.
Übrigens setze ich keine "gewisse Grundkenntnisse" beim Fragesteller voraus. Ich versuche, so zu antworten, dass auch ein Neuling zurecht kommt. Ich selbst betrachte mich übrigens auch als Neuling, obwohl ich Access schon seit sehr vielen Jahren kenne: Neu sind die täglichen Herausforderungen an Access, alt sind manchmal die Probleme der Fragesteller, die oft auch auf Logik-Mängel in Access zurück zu führen sind. Bei jeder Frage, die gestellt wird und zu der ich eine Antwort gebe, interessiert mich nicht primär der Wissensstand des Fragenden, sondern, einen möglichen Lösungsweg aufzuzeigen.
Solches dann z.B. als "Spaghetticode" abzutun, ist sicher nicht besonders förderlich - eine andere Formulierung wäre (in diesem Fall) doch wohl besser geeignet gewesen, einer Lösung der Frage näher zu kommen.
Ich persönlich habe die "Wahrheit" nicht gepachtet und wenn ich Vorschläge mache, wäre ich froh, wenn diese von den "wirklichen Profis" sachlich, fachlich als falsch oder fehlerhaft kommentiert würden. Und nicht mit Polemik.
Soll dieses Forum leben - auch durch alternative Ansätze, oder soll es zu einem Experten-Forum verkümmern, wie in diesem Szenario:
Zwei Leute sitzen an der Bar und nennen sich gegenseitig immer wieder Zahlen, worauf das Gegenüber kräftig lacht.
Ein Dritter fragt den Barkeeper: "Was sind das für Leute, die sich kaputt lachen, weil einer 376 gesagt hat?" "Das sind Leute, die ein Witzebuch schreiben. Sie haben die Witze durchnummeriert."
lg
crystal
Hallo, sorry das ich mich erst jetzt melde.
Musste noch in einer anderen Datenbank was wichtiges erledigen.
Anbei ist LEIDER nur eine kleine Test Datenbank im 2003er Format, als ZIP, da ich die originale aufgrund von Personendaten nicht nehmen kann.
Diese ist natürlich sehr einfach und klein gehalten, aber vom Grundprinzip her ist die Vorgehensweise ja gleich.
Es soll gezählt werden:
1. Wieviele Mitarbeiter gibt es insgesamt
wieviele davon männlich
wieviele davon weiblich
2. Wieviele Mitarbeiter haben Qualifikation 1
wieviele sind davon männlich
wieviele sind davon weiblich
3. Wieviele Mitarbeiter haben Qualifikation 3 aber nicht 5
wieviele sind davon männlich
wieviele sind davon weiblich
4. Wieviele Mitarbeiter sind unter 25
wieviele davon männlich
wieviele davon weiblich
das reicht ansich, die weiteren Fälle funktionieren ja nach dem gleichen Prinzip.
leider konnte ich selbst noch nicht aktiv werden, ich werde aber gleich noch selbst anfangen.
beste Grüße
Abfrage 2, unter Weglassung des Kriteriums und Änderung des konstanten Textes im SELECT-Teil wird auch Abfrage 1 erledigt:
SELECT
"unter 25" AS Kriterium,
COUNT(*) AS g,
SUM(M.geschlecht = 1) * - 1 AS m,
SUM(M.geschlecht = 2) * - 1 AS w
FROM
tblMitarbeiter AS M
WHERE
M.Geburtsdatum < DateAdd("yyyy", - 25, Date())
Abfrage 4, mit Reduzierung Abfrage 3:
SELECT
"Quali 3, nicht 5" AS Kriterium,
COUNT(*) AS g,
SUM(M.geschlecht = 1) * - 1 AS m,
SUM(M.geschlecht = 2) * - 1 AS w
FROM
tblMitarbeiter AS M
WHERE
EXISTS
(
SELECT
NULL
FROM
tblQualiMitarbeiter AS QM
WHERE
QM.MitarbeiterID_F = M.MitarbeiterID
AND
QM.QualifikationsID_F = 3
)
AND
NOT EXISTS
(
SELECT
NULL
FROM
tblQualiMitarbeiter AS QM
WHERE
QM.MitarbeiterID_F = M.MitarbeiterID
AND
QM.QualifikationsID_F = 5
)
Erkennbar: Die Abfrage auf eine Tabelle (Mitarbeiter) ist immer die gleiche. Variiert wird nur die erste Spalte (Bezeichnung der Filterung) sowie dann das Kriterium. Somit ließen sich die Abfragen in einer VBA-Schleife aus konstantem Anteil und variablen Anteil zusammensetzen, vorbehaltlich einer geeigneten Speicherung der variablen Teile.
Dass man hier zwei Abfragen beispielhaft für weitere zeigen kann, dokumentiert dann Variabilität, Erweiterbarkeit und Pflegbarkeit des Ganzen.
Wie das alles dann genau nach Excel zu übergeben wäre, hängt auch davon ab, wie die Darstellung genau aussehen soll. Damit dann auch, ob man die Abfragen per UNION zusammenhängt oder gleich einzeln per CopyFromRecordset überträgt, ist dann auch nur ein Nebenkriegsschauplatz.
Wow,
so schnell hat Eberhard eine Antwort gefunden! Bravo.
Naja - es fehlt noch etwas die Übertragung nach Excel bzw. zuvor die Auswertung der Ergebnisse in VBA und zuvor der Aufruf der Abfragen in einer Routine. Es ist eben nicht damit getan, Abfragen für die verschiedenen Fragestellungen isoliert zu formulieren, das kann (fast) jeder. Die Ergebnisse dieser Abfragen sollen ja auch zusammen dargestellt werden. Oder soll Xoar das anschließend manuell machen?
Morgen mehr.
lg
crystal
ZitatOder soll Xoar das anschließend manuell machen?
So wie er sich bisher dargestellt hat, kann er die Informationen selbst in einem zusammenfassenden Code verarbeiten. Immerhin fragte er eingangs gezielt nach einer Strategie für die Abfragen. Zum Übertrag nach Excel scheint er Vorstellungen bzw. Lösungen zu haben.
Und da er sein Projekt besser kennt und hier nur einen Auszug gezeigt hat, kann er das an der Stelle besser wie jeder andere.
Zitat von: Josef SchmidtWer hilft, wo fördern reicht, schädigt.
Wie lautet doch gleich der Thementitel:
AbfragenorganisationZitat von: crystalAbfragen für die verschiedenen Fragestellungen isoliert zu formulieren, das kann (fast) jeder.
Ein starkes Wort.
An dieser Feststellung und der tatsächlichen Umsetzung darf der Zitierte sich messen lassen.
Ui danke,
da sieht man mal wirklich das ich von SQL sehr wenig Ahnung habe. Sowas hätte ich nie geschafft.
Nach Excel exportieren würd ich das ganze über nen Recordset mit ner Schleife. Das bekomm ich hin, hab ich anderweitig schon gemacht.
Bin hier heute leider total eingebunden, werde das ganze morgen Abend ausführlich testen und versuchen den genauen Syntax zu verstehen.
Besten Dank schonmal
ZitatNach Excel exportieren würd ich das ganze über nen Recordset mit ner Schleife.
Das könnte bspw. so aussehen:
Sub Statistikausgabe(objExcelsheet As Object, Startzeile As Long)
Dim db As DAO.Database
Dim rsAusgabe As DAO.Recordset
Dim rsFilter As DAO.Recordset
Dim sSQL As String
Dim i As Long
Set db = CurrentDb
Set rsFilter = db.OpenRecordset( _
"SELECT Filtername, Filterstring FROM tblFilterspeicher", _
dbOpenForwardOnly)
With rsFilter
Do While Not .EOF
sSQL = "SELECT '" & .Fields("Filtername") & "' AS Kriterium," & _
" COUNT(*) AS g," & _
" SUM(M.geschlecht = 1) * - 1 AS m" & _
" SUM(M.geschlecht = 2) * - 1 AS w" & _
" FROM tblMitarbeiter AS M" & _
" WHERE " & .Fields("Filterstring")
Set rsAusgabe = db.OpenRecordset(sSQL, dbOpenSnapshot)
objExcelsheet.Cells(Startzeile + i, 1).CopyFromRecordset rsAusgabe
rsAusgabe.Close
i = i + 1
.MoveNext
Loop
.Close
End With
Set rsFilter = Nothing
Set rsAusgabe = Nothing
Set db = Nothing
End SubHier wird eine Referenz auf ein Excel-Arbeitsblatt verwendet. Somit kannst Du im Vorfeld selber entscheiden, ob Du eine neue oder eine vorhandene Mappe verwenden willst und in welches Blatt der Übertrag erfolgen soll.
Es wird weiterhin eine Tabelle tblFilterspeicher verwendet, in der die Namen und Inhalte der verschiedenen Filter abgespeichert sind. Tabelle daher, weil sich hier Inhalte besser pflegen lassen als in einem Code, mit einer zusätzlichen Bedienoberfläche durchaus auch für einen normalen User.
Über ein zusätzliches Feld in der Tabelle könnte man darüber hinaus Auswahlkriterien anbieten, wenn z.B. in manchen Durchläufen nur bestimmte ausgewählte Auswertungen berücksichtigt werden sollen.
Hinweis: Für den allerersten Filter (alle Mitarbeiter) der eigentlich leer ist, True als Feldinhalt verwenden.
Hallo
und nebenbei bemerkt,
wirklich schönen Code hat Eberhard hier beigesteuert! Das ist doch VIEL besser, als allgemeine Floskeln, die nicht immer zu verstehen sind.
Bravo und bitte weiter so.
lg
crystal
@crystal:
Ich bin im Gegenzug gespannt auf den Alternativ-Wettbewerbsbeitrag, besonders auf Aspekte wie
- Codeverständlichkeit
- Pfleg- und Erweiterbarkeit (wer 50 Auswertungen braucht, braucht auch 75)
- Performance, wenn es mengenmäßig um die Mitarbeiter von VW und nicht nur die der benachbarten Schmiede geht
... und ganz besonders, wie man die vielen und zum Teil gegensätzlichen Bedingungen
in einer Abfrage unterbringt. Da würde ich dann wirklich sehr gerne lernen.
Zitatallgemeine Floskeln, die nicht immer zu verstehen sind
Nun, das Unverständnis gilt wohl eher individuell. Bei dem TE konnte ich das nicht feststellen.
Der Code ist nichts anderes, als was ich im Vorfeld skizzierte, mit der Abweichung, dass ich statt Kreuztabellenabfrage eine einfache Auswahlabfrage verwende. Da Codes konkret sind, sind sie erst sinnvoll, wenn die Ausgangssituation beim TE klar ist. Darauf habe ich aber regelmäßig verwiesen.
Hallo :)
heißt, die Tabelle bekommt folgende Felder:
FilterID: Autowert
Filtername: Wie ich den Filter benannt haben will
Filterstring: M.Geburtsdatum < DateAdd("yyyy", - 25, Date()) muss der dann so eingetragen werden?
und dann halt für jeden Filter.
Hier mal mein Verständnis der Syntax.
sSQL = "SELECT '" & .Fields("Filtername") & "' AS Kriterium," & _ Feld: Filtername als "Kriterium" bezeichnet anzeigen lassen
" COUNT(*) AS g," & _ Zähle alle DS
" SUM(M.geschlecht = 1) * - 1 AS m" & _ summiere wo Geschlecht = 1 ist, wieso -1?
" SUM(M.geschlecht = 2) * - 1 AS w" & _ summiere wo Geschlecht = 2 ist
" FROM tblMitarbeiter AS M" & _ von tblMitarbeiter, verkürzt als M bezeichnet
" WHERE " & .Fields("Filterstring") Bedingung, je nach Schleifendurchlauf der Inhalt des Filterstrings aus der Tabelle (im Rst geladen)
Sehr gute Variante, hab ich viel durch gelernt. Danke *Daumen hoch*
PS: was genau macht das "true" als Filterstring? Sagt er der where Bedingung, sozusagen das keine Bedingung vorherrscht?
@Xoar:
ZitatFilterstring: M.Geburtsdatum < DateAdd("yyyy", - 25, Date()) muss der dann so eingetragen werden?
Genau. Alles, was hinter dem Schlüsselwort WHERE der Hauptabfrage kommt.
Ich habe die Struktur der Abfrage bewusst so gewählt, weil man in der gleichen Weise auch andere Tabellen einbinden könnte, also statt Qualifikationen auch Urlaubstage, Dienstreisen oder andere Sachverhalte einbeziehen wollte.
Zitatwas genau macht das "true" als Filterstring?
Im WHERE-Teil wird ja geprüft, ob eine Bedingung erfüllt wird. Diese Prüfung ergibt dann True oder False. Bei mehreren Bedingungen müssten dann alle True sein.
Die Schreibweise "WHERE True" erspart ein Abschneiden des WHERE und ermöglicht eine einfache Schleife wie gezeigt.
SUM(M.geschlecht = 1) * - 1 AS mM.geschlecht = 1 ... ist eine logische Prüfung und ergibt True (-1) oder False (0). Die Summierung ergibt die benötigte Anzahl, die Multiplikation mit -1 entfernt das Vorzeichen (ersatzweise könnte man auch Abs() ) verwenden.
FROM tblMitarbeiter AS MDas M ist ein Tabellenalias, siehe Grundlagen - SQL ist leicht (2) - Alias (http://www.ms-office-forum.net/forum/showthread.php?t=298432)
//Edit:
ZitatFilterstring: M.Geburtsdatum < DateAdd("yyyy", - 25, Date())
Wer sich das genau angeschaut hat, wird bemerkt haben, dass der Operator falsch ist, wenn man die unter 25-jährigen haben will: '<' => '>'
Hallo,
ich bin noch dabei, zu programmieren, dauert bei mir halt etwas...
@Eberhard: wirklich schön zu sehen, wie gut du auf Xoars Fragen eingehst und erklärst! Du bist damit deutlich in meiner Achtung gestiegen. Die Art und Weise, wie du jetzt reagierst und antwortest, ist prima und ich freue mich, wenn es so bleibt. Ich sagte ja schon öfter, dass ich dein Expertenwissen sehr schätze, jetzt hast du wohl auch einen Weg gefunden, es mitzuteilen und zu vermitteln. Kleinere Seitenhiebe sind dann verschmerzlich...
lg
crystal
So,
nun bin ich mit einer ersten Version fertig.
Bitte folgendes zu beachten:
1. In Modul1 habe ich Arrays definiert; wenn die Zahl der Ausgabespalten oder -zeilen größer werden sollte, müssen die Konstanten in Modul1 angepasst werden. (Hintergrund: mit Redim kann man nur die letzte Dimension eines Arrays vergrößern, nicht aber die erste bei mehrdimensionalen Arrays).
2. Eine Excel-Ausgabe habe ich nicht implementiert. Ich schreibe aber ins Debug-Fenster eine "CSV": Text im Debug-Fenster komplett selektieren, ausschneiden, in eine Text-Datei einfügen und diese dann in ein Excel-Arbeitsblatt importieren (Trennzeichen Semikolon).
In der DB einfach nur das Formular1 aufrufen und den Button klicken. der Debugger bleibt dann bei der Dummy-Zeile i=0 stehen und man kann den Text im Direktfenster kopieren (s.o.).
Ob meine Lösung nun gut oder schlecht ist, sei dahingestellt. Ich fürchte mich auch nicht vor Kritik. Immerhin denke ich, dass sie durchaus performant ist, auch bei größeren Datenbeständen...
Ich freue mich auf eure Lacher.
lg
crystal
Hallo,
noch keine Reaktion?
Ist meine Lösung sooo schlecht, dass niemand eine Antwort schreibt?
Verbesserungs-Möglichkeiten:
1. Man könnte die möglichen Werte z.B. aus der Quali-Tabelle laden und mit Anzahl=0 im Array initialisieren. -Das könnte die Übersichtlichkeit verbessern, wenn man dies z.B. für die Spalten "alle", "m", "w" und "n.a." parallel macht, so dass in all diesen Spalten jeweils alle Qualis gelistet sind und eben nur da eine Anzahl > 0 steht, wo sie auch gezählt wurde (zusätzlicher Modus 2).
1a. Den Modus sollte man als letzte Übergabe und mit optional=1 definieren.
2. Der Code ist straight forward entspr. der gegebenen Anforderung ("Spaghetti-Code", wie Lachtaube es nannte). Die zugrundeliegende Abfrage liefert deshalb auch nur die Qualis. Wenn andere Felder hinzukommen (z.B. "besuchte Seminare"), würden Datenzeilen entspr. hinzukommen und eine Quali eines MA würde mehrfach auftauchen, was beim Zählen entspr. berücksichtigt werden muss (hier: überspringen aller Qualis eines Ma, die schon gezählt wurden).
3. Arrays: die Dimensionierung der Arrays dynamisch zu gestalten (mit Redim), ist nicht erforderlich, wenn man sich überlegt, wie viele z.B. Qualis (etc.) es überhaupt gibt (s. a. Punkte 1 und 2). Die Zahl der Spalten ergibt sich ohnehin aus der Programmierung.
4. Eine direkte Übergabe der Ergebnisse an Excel ist zweifelsfrei möglich, es mangelt mir nur an Erfahrung damit.
Es wäre schon schön, eine Rückmeldung zu meiner ersten Version zu erhalten, selbst wenn sie sehr negativ ausfällt.
lg
crystal
Hi,
ich habe leider noch keine Zeit gehabt drüber zu schauen.
Hab momentan sehr viel um die Ohren.
Werde noch ein Feedback geben!
Hallo,
Ich habe meine Lösung noch mal geringfügig geändert (siehe vorvorige Nachricht Punkte 1 bis 3).
Im angefügten Zip habe ich eine Excel-Datei mit der Ausgabe beigefügt.
lg
crystal