SQL oder VBA?

Computer: Software & Programmierung Programmierung allgemein
#1

Hallo,
ich würde mich gerne näher, bzw. tiefer mit Excel und Access beschäftigen. Da wird es auf lange Sicht nicht ausbleiben sich mit dem Programmieren von Scripts auseinanderzusetzen.

Nun wird ja in der Regel SQL oder VBA als Programmiersprache in Office-Anwendungen „anerkannt“. Sie sollen wohl auch recht ähnlich sein, habe ich mal gelesen.
Meine Frage wäre, in welche der beiden Sprachen man sich am besten einarbeiten sollte. Gerade in Bezug auf Einsteigerfreundlichkeit, da ich schon etwas älter bin.
Programmiert habe ich mal ein kleines bisschen als Kind mit Basic auf alten 8-Bit-Computern :smiley:
Habe es dann immer mal wieder probiert, bin aber gescheitert.

Vielen Dank für eure Tips. Gerne auch Einsteigerfreundliche Literatur empfehlen.

Danke!

#2

Hi,

äh, nein … VBA=Visual Basic for Application
SQL=structured query language.

Auch wenn SQL ein L wie language im Namen hat, aber das hat mit einer Programmiersprache nicht wirklich zu tun. Momentan wüsste ich auch nicht, was man außer VBA bei Office-Anwendungen benutzen kann.

Man kann wohl SQL in VBA nutzen, aber es ist keinesfalls eine Alternative.

Dann hätte ich, auch im Hinblick auf Programmierung, VBA empfohlen. Aber wenn ich dann wiederum

lese, ist die Frage, ob du dich überhaupt damit beschäftigen solltest, oder ob du dir eher etwas suchst, was dir liegt. :slight_smile:

Gruß
Christa

3 Like
#3

Wenn Du mit Access arbeiten willst und ggf. Excel dabei einbinden möchtest, dann wirst Du beides brauchen. SQL ist eine Sprache, die ausschließlich zur Abfrage/Manipulation von Datenbanken auf Ebene der rohen Daten dient. D.h. damit kannst Du keinerlei Oberflächen gestalten, nicht auf Aktionen in einer Oberfläche reagieren, schön gestaltete Reports und sonstige Ausgaben erzeugen, … Für all dies ist VBA im Rahmen der MS Office Produkte zuständig.

Bei Access kommt noch hinzu, dass recht viel über eine grafische Oberfläche gemacht werden kann. D.h. Du musst die SQL-Statements, die bei der Erzeugung von Reports die passenden Daten liefern, nicht händisch eintippen, sondern kannst sie durch Anklicken von Feldbezeichnern und Bedingungen von Access selbst erzeugen lassen. Auch die Oberflächen selbst lassen sich grundsätzlich mit der Maus und wenig Texteingaben erzeugen. D.h. viele einfache Access-Anwendungen benötigen gar keinen manuell erzeugten Code. Weder VBA noch SQL. Aber man kommt so doch recht schnell an Grenzen. Und dann nimmt man sich z.B. mal eines der von Access selbst erzeugten SQL-Statements, schaut sich das genau an und sieht dann ggf. recht schnell, dass es einfacher ist darin rein textlich etwas zu ändern, als die ganze Klickerei zu betreiben, kopiert sich mal schnell ein Statement und passt es mit drei Buchstaben für einen anderen Zweck an, besorgt sich aus dem Internet einen kleinen Code-Schnipsel hier und da, kommt damit dann auch mehr und mehr in VBA rein, …

Access ist mE extrem unterschätzt und wirklich mächtig. In unzähligen Unternehmen wird Excel als Datenbank tausendfach missbraucht, wo Access die deutlich bessere Lösung wäre. Dies insbesondere deshalb weil man eine kleine Access-Anwendung mit sehr erträglichem Aufwand schnell aufteilen und das Backend dann auf einen SQL-Server schieben und z.B. eine Web-Oberfläche daran anbinden kann. Und schon hat man eine recht performante Multi-User Anwendung deren Backend professionell betrieben und administriert werden kann.

6 Like
#4

Ähm, hier würde ich doch einwerfen, dass das stinkige select-Statement einiges auch an Formatierungen bewältigen kann - zwar etwas rudimentär, aber Möglichkeiten gibt es einige.

Ich hab da noch einige ältere Selects, die ich 1:1 für PDF-Ausgaben benutze. (Die werden irgendwann dann portiert, wenn ich mal Zeit habe, diese genau zu analysieren - was weiß denn ich noch, was ich mir vor 25 Jahren dabei gedachte habe …)

Nachdem es mir bei diesem Satz kurz den Magen zusammengekrampft hat: Es ist den meisten Entscheidungsträgern oft gar nicht bewusst, wie einfach und schnell ihre Trillionen verknüpften Excel-Sheets in Access abgebildet werden könnten und es trotzdem noch Excel-Like aussieht und bedienbar ist - der Dosenöffner ist dann meist der Export einer Auswertung nach Excel … im besten Fall noch mit einer bunten Grafik …
Beim SQL-Server schrecken meist die Kosten ab (von Oracle o.ä. brauch ich da gar nicht erst anzufangen)

2 Like
#5

Ja, was die reine Datenformatierung angeht, kann man da schon einiges machen. Aber die Leute wollen es ja heute alle wie von der Werbeagentur gestaltet und aus der Druckerei mit Firmenbriefkopf, Diagrammen, Bildern, … Die Zeit der Kettendrucker neigt sich halt dem Ende zu :wink:

Ich müsste jetzt lügen, weil ich schon lange nichts mehr mit Access gemacht habe, aber wieviel Zeilen Code waren das noch aus einem select ein Excel Spreadsheet zu erzeugen? Und der Einstieg in Access ist nun wirklich banal und einfach und man hat so schnell einen Stand erreicht, an den Excel alleine nie auch nur ansatzweise dran kommt.

Wenn ich mir die ganzen neuen No-/Low-Code Umgebungen ansehe, die aktuell so gehyped werden, und mir dann ansehe, was da dann doch an neuem Einarbeitungsaufwand dran hängen würde, dann denke ich mir, warum man den Leuten nicht vor Jahren schon einfach mal Access etwas näher gebracht hat.

Zugegebener Maßen hat allerdings auch MS im Office-Paket so einiges falsch gemacht, weil bis heute die Interoperabilität der teilweise extern zugekauften/in getrennten Entwicklerteams entwickelten Anwendungen den einfachen Anwender nach wir vor vor viel zu große Einstiegshürden stellen. Schon Works, Q&Q oder TexAs-Windows zu DOS-Zeiten waren da deutlich einfacher und logischer aufgebaut, boten die Dinge, die man im Büroalltag brauchte in sehr handlicher Form an, … Um heute seine in Outlook, Excel oder Access gespeicherten Informationen in einem Word-Dokument nutzen zu können, braucht es einen vollkommen unverhältnismäßige Aufwand. Und dann sehen die Leute eben nicht den Vorteil solche Dinge dann gleich mal richtig aufzuziehen.

#6

Nein, nein, da war/ist schon etwas mehr möglich - solange es nix grafisches ist.

Bunt, bunt, bunt … nicht zuviele Zahlen, viele Diagramme mit nicht zu vielen Segmenten

Ähm, bei einem Access-Report ist es ein Klick auf die linke Maustaste, „Export“-> Excel … ich meinte keinen automatisierten, sondern einen manuellen Export, mit genau den Daten einer Abfrage, die der User gerade ausgeführt hat.
EDIT: Sobald aber bemerkt wird, dass man Diagramme ebenfalls exportieren kann, schwindet die Aufmerksamkeit auf Excel schnell dahin.

#7

Ich meinte jetzt einen netten Button auf die Oberfläche zu legen, bei dessen Anklicken dann eine Dateiauswahlbox zur Eingabe des Dateinamens und des Speicherziels kommt, oder das Öffnen von Excel mit einem Spreadsheet mit den Daten aus dem Report. Das sind alles minimal wenige Zeilen.

#8

Das ist genau die Funktion der rechten (also das andere „links“, nicht wie ich vorhin schrieb) Maustaste - Dateiname, Format und ev. sogar gleich Öffnen dieser Datei (Häckchen setzen).

#9

Ich weiß, das hatte ich allerdings nicht gemeint. Es ging mir um den Aufwand genau diese Funktion für Otto-Ich habe keine Ahnung/will mich nicht mit Access beschäftigen-User hinter einen hübschen Button mit der Aufschrift „Excel-Export“ präsent auf die Oberfläche einer kleinen Access-Anwendung zu legen. K.A. ob man das jetzt direkt in den OnClickEvent des Buttons schreiben kann, oder ob das eine kleine Sub mit ein oder drei Zeilen Inhalt braucht. Ist einfach zu lange her, dass ich was mit Access gemacht habe.

Ist aber auch nicht so wichtig, weil das eine eher rhetorische Frage war. Es ging nur darum, dass der Aufwand eben minimal ist, um Dinge mit Access gleich richtig zu machen.

#10

Dann will ich da auch nochmal meinen Senf zu geben …

Dass SQL keine Programmiersprache ist, wurde ja schon angedeutet.

Bzgl. SQL und VBA solltest Du zwischen Abfrage/Wegschreiben der Daten (SQL) und manipulieren/Nutzen der Daten (VBA) unterscheiden. Wo man da genau die Grenze setzt, ist teilweise eher eine philosophische Frage, aber als Grundgedanke sollte man das beherzigen.

Ich persönlich packe relativ viel in das SQL-Statement, so dass der Programmcode sind auf die Anzeige der Dialoge und der Entgegennahme der Datenänderung vom Benutzer konzentriert.

Access ist IMHO eines der besten Tools, was Desktop-Datenbanken angeht. Aber sein großer Vorteil ist auch gleichzeitig sein größter Nachteil.

Man kann sich mal schnell was zusammenklicken. Es gibt es schnelle Lösungen. Aber wehe, es müssen mal Änderung vorgenommen werden. Da ist es dann sinnvoll von vornherein den erzeugte Code der Assistenten nur als ersten Entwurf anzusehen und den dann zu überarbeiten. (BTW: Das von @Tomh ist Spiel gebrachte Formatieren über das SQL-Statement ist IMHO auch sowas Kontraproduktives)

Das Gleiche gilt für die kombinierte Nutzung sowohl als Frontend (Dialoge usw.) und Backend (Datenbank) in einer Datei.

Jetzt kommt noch hinzu, dass Access mittelfristig scheinbar nicht mehr von Microsoft weiterentwickelt wird. Die Symptomatik ist ähnlich zum klassischen VisualBasic Anfang der 2000er. Inzwischen ist sogar die Nachfolge-Sprache VB.net erledigt.

Es finden schon länger quasi keine Neuerungen rund um Access mehr statt. Es ist bis heute nicht in die DotNet-Landschaft integriert.

An die Abkündigung von VBA traut sich Microsoft noch nicht ran. Aber so richtig Neuerungen gibt es da auch nicht mehr. Microsoft setzt schon lange auf andere Sprachen. Meine Glaskugel sagt mir, dass spätestens mit einem Ende von Access es auch VBA an den Kragen geht.

#11

Du meinst vermutlich die Funktion TransferSpreadsheet. So ein Import/Export ist im einfachsten Fall ein Einzeiler … allerdings sollte da zumindest noch ein Fehlerhandling dazukommen.

1 Like
#12

Genau das meinte ich!