Office: (Office 2013) Variablen für SQL bauen

Hallo liebe Access-Profis,
ich habe mir über Jahre als Access-Laie ein CRM-Tool aufgebaut, was 1/4-jährliche Händler-Umsatzbetrachtungen im
aktuellen Jahr mit Vergleich zum Vorjahreszeitraum erlauben soll. Bisher habe ich mit Berichten gearbeitet, deren Datenherkunft eine SQL-Abfrage enthält. Darin benutzte ich immer feste Dateinamen für Jahresumsatztabellen, z.B: U_2015. Eine Kopplung zum Kundenstamm geschieht über die Kundennummer mit INNER JOIN.
Möchte ich z.B. die März-Umsätze sehen, heißt die Spalte U15N3. Der Zugriff passiert dann in SQL auf U_2015.U15N3.
Mein Problem ist nun folgendes: Ich möchte nicht jedes 1/4 Jahr, nach Aktualisierung der Händlerumsatzlisten, in 3 verschiedenen
Berichtsarten die SQL-Anweisung neu schreiben und innerhalb des Berichtes die Feldnamen anpassen müssen.
Mein Lösungsansatz war bisher folgender:
Über ein Formular frage ich über Kombinationsfelder, welches Jahr und welches Quartal (ggf. auch welcher Kollege oder auch welche Tour) gezeigt werden soll. Für den Vertriebler: Wie entwickeln sich besuchte Kunden?
Im VBA-Code lasse ich nun verschiedene Dateinamen und Spaltenbezeichnungen in Variablennamen füllen, die in der vorhandenen SQL-Abfrage abgearbeitet werden sollen.
Nur scheint mir, dass SQL kein Allesfresser ist, d.h. ich muss vermutlich einige Regeln beachten? Die SQL-Syntax wird von VBA ohne Murren abgearbeitet, der Bericht wird gezeigt, bleibt aber leider leer.
Ohne Grundwissen ist es natürlich, wie so oft im Leben, alles sehr undurchsichtig.

Meine 1. Frage:
bin ich eigentlich damit auf dem richtigen Weg, solche dynamischen Abfragen zu lösen?

2. Frage
Können innerhalb eines INNER JOIN Variablen eingesetzt werden? Statt U_2015 eine Variable Namens U_Vj benutzen, die im Formular festgelegt den Zugriff auf die Tabelle U_2015 herstellen soll?

3. Frage: ON Kdstamm2.KdNr=U_2014.KdNr, statt U_2014.KdNr eine Variable Namens U_VJ_Kd, die im Formular das Jahr bekommen hat und mit ".KdNr" verknüpft wird?

4. Frage: Was ist beim Zusammenbau von solchen Variablen zu beachten?

5. Frage:
"Hört" mein bisheriger Bericht auf die neuen Variablen, wenn im Bericht diese neuen Spalten aufgeführt sind?



Sorry, Fragen über Fragen ;-(


Ich bin sehr gespannt auf Eure Antworten !


...der Laie

Joe-OH

:)

 

Jahrestabellen sind Mist.

Gleiche Daten gehören in EINE Tabelle. Abfragen können mit sehr großen Datenmengen umgehen. In welcher Größenordnung bewegen sich Deine Datensatzanzahlen?

Mit einer Tabelle verflüchtigen sich Deine Dynamik- und sonstigen genannten Probleme, weswegen ich auch nicht näher darauf eingehe.

 

Hallo Joe,

im komme gleich mit einer Gegenfrage.*grins

Warum sind denn gleichartige Daten auf viele Tabellen verteilt? Stünden die Quartalszahlen alle in einer Tabelle, wäre nur das setzen von Parametern (Jahr und Quartal, ggf. noch Kunde) notwendig, um die richtigen Daten für den Bericht auszusieben.

 

Hallo Nouba, hallo EBS17,

das ist immer das Schöne: Wenn man Profis was fragt, bekommt man oft verblüffend gute Antworten ;-). Meine verschiedenen Umsatztabellen entstammen meiner alten Arbeitsweise unter Excel. Das heißt aber nicht, dass ich daran festhalten muss. Eine Umsatztabelle hat bei mir ungefähr 500 Datensätze, über 10 Jahre hätte sie ca. 40 Spalten statt ggf. 5 (KdNr + 4x Quartal), ich sehe schon, wohin die Reise gehen soll. Meine Spaltennamen stimmen ja schon ;-). Ich baue mir EINE Umsatzdatei, wenn ich Euch recht verstehe.
So habt Ihr mir schon mal die Antwort zu meiner 1. Frage geliefert, Besten Dank an Euch.
Ich wusste schon, dass ich ggf. den Wald vor Bäumen nicht sehe. Wenn Ihr dann für Frage 2 - 5 wenigstens mit dem Zaunpfahl winken könnt? So weiß ich dann, wie ich unter VBA die SQL-Abfrage angehen darf...

Ich danke Euch und wünsche Euch schon mal schöne Weihnachten von der Ostseeküste.


Euer Joe-OH

 

Hallo,

auch das wäre falsch, keine 4 Felder für die Quartale, sondern nur eins, aber dann 4 Datensätze.
Du denkst immer noch in Excel.

 

Hallo Joe,

zu 2) nein. SQL kennt keine Variablen.

Aber: Access bindet seinen Ausdrucksdienst (mit Evaluate in Excel vergleichbar) in die Jet- bzw. Access-Engine mit ein, so dass VBA-Funktionen in allgemeinen Modulen in SQL verwendbar sind. Ob so eine Funktion nun eine Berechnung ausführt oder den Wert einer globalen Variablen zurückgibt, ist dabei egal. Diese Funktionen sind nur innerhalb von Access nutzbar. SQL ist Text wie VBA Code auch. Dieser kann natürlich so zusammenpfriemelt werden, wie man ihn benötigt, solange keine Syntaxregeln verletzt werden.

zu 3) auch hier wäre nur das Verketten von SQL-Fragmenten möglich. Parameter gelten nur für Feldwerte.

zu 4) die Syntaxregeln der Jet- bzw. Access-Engine.

zu 5) nein. Du könntest aber mit Alias-Namen in der Abfrage immer gleiche Feldnamen übergeben.

BTW: wenn Du ernsthaft mit Access und diesen Daten arbeiten willst, sollten die Daten zumindest halbwegs normalisiert in Access vorliegen. Sonst muss das suboptimale Datengeflecht immer wieder mit VBA aufbereitet werden, was Rechenzeit kostet und vermutlich auch hinderlich ist für eine gute Index-Nutzung.

 

Mit Verlaub: selbstverständlich kennt SQL Variablen.
Jedenfalls T-SQL Code:

Jet-SQL kennt das nicht.
Allerdings könnte man sich hier mit temporären Tabellen (mit je einem Datensatz) helfen.
Oder mit Parametern.
Aliasse helfen manchmal auch weiter, wenn das Konstrukt aus Tabellen- und Feldname zu unhandlich wird.

 

\@Hans-Christian,

entschuldige, mir war nicht bewusst, das in einem Access-Forum explizit der SQL-Dialekt erwähnt werden muss. *entsetzt

BTW: die Jet- und die Access-Engine kennt keine temporären Tabellen.

 

Wenn unter "Umsatzdatei" eine Tabelle zu verstehen ist, die pro Umsatz einen Datensatz mit einem Umsatzdatum und einem Umsatzwert und ggf. noch einigen weiteren Informationen enthält - dann sehen wir das Gleiche.
Und dann kann man mit einfachsten Mitteln Abfragen erstellen, ohne Hochdynamik und ohne Variablen, aber nativ hoch funktionierend und über Parameter auch sehr variabel für verschiedene Erfordernisse.

 

Hallo meine Lieben,
das hört sich ja schon alles sehr verheißungsvoll an!
Die Excel-Denke abgewöhnen: könnte mir gefallen ;-)
Nun mal im Ernst: Ich baue eine Umsatztabelle auf, die in den Spaltenaufschriften die Kundennummern enthält, darunter z.B. die Zeilen für die Quartalsumsätze der beiden vergangenen Jahre: U14N3, U14N6, U14N9,U14N12,U15N3,U15N6,U15N9,U15N12?
Mit "N" ist bei mir "Niederlassung" gemeint, "Z" für "Zentral" gibt es leider auch.
So langsam muss ich ja mal die Kurve kriegen ;-)


Viele Grüße

der Joe

 

Was einen aber nicht daran hindern muss, solche - per VBA oder mit select into - anzulegen *wink.gif*

 

Hallo,

nein, das ist immer noch Exeldenke.
Die Tabelle sollte so aussehen:

Code:

Das Quartal ist eine Zahl mit dem Jahr (JJ) und dem Quartal. Erst das Jahr und dann das Quartal wegen einer eventuellen Sortierung. Das Jahr kann natürlich auch 4-stellig sein.
UmsatzID ist einfach nur ein Autowert als Primärschlüssel. Die Tabelle muss noch um ein Feld für die Niederlassung erweitert werden. Diese Tabelle hat immer nur 5 Spalten (mit Niederlassung), unabhängig von der Kundenzahl, den Quartalen und den Niederlassungen.

Nachtrag:
Es wäre besser das Jahr und das Quartal in getrennten Spalten zu führen. Die Tabelle hat dann 6 Spalten.

 

\@Joe-OH: Du hast fertige Quartalsumsätze (die Du erhältst), oder produziert Ihr auch laufende Umsätze?

 

Hallo GPSWanderer,
ich merke schon, die Tabellen müssen "Maschinen-lesbar" sein, nicht "Mensch-lesbar". Die 6-Spaltige Tabelle würde ich bevorzugen.
Ja, die Normalisierungen..., da ist schon was dran ;-)
Für Niederlassungen und Zentralen gibt es jeweilig eigene Kundennummern,
von daher lässt sich so schon alles unterkriegen.

Nun muss ich nur noch einen Weg finden, meine alten Tabellen in das neue Format umzuwandeln.

Das Primärschlüsselprinzip für jeden Datensatz ist verstanden. Wenn ich für eine Kundennummer 4x Umsatz im Jahr habe, sind das 4 Zeilen. Falls ich ggf. die letzten 6 Jahre nehmen sollte, sind das 24 Zeilen pro KdNr, bei 500 Kunden sind das 12000 Programmzeilen ? Nicht, dass ich da was falsch verstehe ?

Ich schätze, danach wird für mich einiges durchsichtiger, was die Abfragen betrifft.

@ebs17: ich erhalte die Quartalsumsätze und fülle damit meine Tabellen.

Besten Dank an Euch!


Joe aus OH

 

Hallo,

wenn Du eine extra Tabelle anlegst in der die Kundennummern den Niederlassungen und Zentralen zugeordnet werden, so kannst Du über die Kundennummer auf die Niederlassungen und Zentralen zugreifen. Eine extra Spalte für die Niederlassungen/Zentralen in der Umsatztabelle kannst Du dann verzichten.

ja, das hast Du richtig verstanden, das hängt aber nicht vom Primärschlüssel ab. Die Schlüsselfelder (PS und FS) werden erst benötigt um die Beziehungen zwischen den Tabellen herstellen zu können.