Abfragenorganisation

[Xoar]

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

[ebs17]

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.

[Xoar]

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

[ebs17]

Anzahl 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.

also 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.

[Xoar]

Ja so hab ich mir das auch gedacht.
Werd mich mal Sonntag dran setzen.

[crystal]

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

[Lachtaube]

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? 

[crystal]

@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

[Lachtaube]

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.

[Xoar]

@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!

[ebs17]

@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).

[Xoar]

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.

[ebs17]

SQL 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

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 ...

[Xoar]

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

[crystal]

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