Office: (Office 2010) Debug.Print

Die bisherige Einzel-DB (Add-In ist es noch nicht) kann
- vorhandene gespeicherte Abfragen formatiert anzeigen, ebenso einkopierte SQL-Anweisungen. Ich nutze das u.a. für die Forumsschreiberei.
- Gleichlautend kann man die SQL-Anweisungen editieren oder neu anlegen und als gespeicherte Abfrage ablegen.
- Aus der SQL-Anweisung kann unmittelbar verwendbarer VBA-Text erzeugt werden (Kopieren über Zwischenablage). Hier ist nun der Gedanke, ob man die Lauffähigkeit des Erzeugten bereits hier prüft, also im Idealfall etwas Fehlerfreies übergibt. Alternativ wäre dann das Prüfen im VBA-Editor mit Verwendung des Übertrags eine gesonderte Maßnahme, wie sie ja mit sDebugPrint gelöst ist, wobei sDebugPrint-Anweisungen extra einzufügen wären und die Anzeige irgendwie doppelt gemoppelt wirkt, wenn man beide Teile nur einfach kombiniert statt zusammenlegt.

Für die Parameterwerte würde ich zum Testen auf Lauffähigkeit an sich Ersatzwerte einsetzen, zur Wertformatierung würde ich so etwas einsetzen wie cSql, das ist auch bei Auflistungen, auch der Values-Auflistung in einer Angügeabfrage, ziemlich gleichbleibend verwendbar. Die Parameterübergabe ist noch kein Schwerpunkt und noch nicht wirklich durchdacht. Allerdings ist gerade diese Thematik eine sehr häufíge Fehlerquelle und damit wert, Routinearbeiten von Automatismen erledigen zu lassen.

Das Projekt ist auch deshalb halbfertig, weil es das tut, was ich will. Die verbleibenden Restprobleme löse ich schneller konkret am Beispiel als über eine dann allgemeingültige Programmierung. Bei einer Veröffentlichung müsste ich dann noch zusätzliche Probleme Dritter lösen, die ich selber gar nicht habe und vielleicht auch gar nicht prüfen mag.

Wie gesagt, ich nutze das sehr bei Aufgaben aus dem Forum. Dort habe ich auch eine Funktionalität gebaut, die aus einem VBA-Ausdruck strSQL = " ... " angenähert einen PUR-SQL-String erzeugt. Wenn das der VBA-Editor selber machen würde wie angefragt, wäre das selbstredend sauberer.

Datenbänkler und Accessverwender leben in verschiedenen Welten und haben da desweilen unterschiedliche Gedanken.

 

Das würde ich pragmatisch betrachten und darauf vertrauen, dass das Add-In eine funktionierende SQL-Anweisung zu VBA-Code konvertieren kann.
Wenn es einmal einen nicht funktionierenden VBA-Code erzeugt, ist das ein Bug im Add-In und kann dort korrigiert werden.

Es kommt vermutlich darauf an, für wen und für welchen Zweck das Add-In gedacht ist.
* Für den Entwickler der SQL kann und auch weiß wie man diesen Text in VBA zusammensetzt als Eingabeerleichterung
* Für Anfänger, die es nicht schaffen einen SQL-Text in VBA zu erstellen.

Für die erste Gruppe kann man auf die VBA-Code-Prüfung verzichten, da diese Gruppe selbst erkennen wird, wenn etwas nicht stimmt.

Für die zweite Gruppe ist vermutlich diese Prüfung auch nicht hilfreich, weil sie einerseits nicht wissen wird, wie das Problem behoben werden kann, das möglicherweise auftrat und anderseits am darauf folgenden Anfügen von Parameterwerten scheitern werden, falls das das Add-In nicht übernimmt. (Ich denke dabei an das Ergänzen von Werten für Filterkriterien aus VBA-Variablen.)
=> Wozu dann den Aufwand in eine Prüfung stecken? .. Lieber die Zeit für die Gestaltung der Variablenwert-Übergabe nutzen. *wink.gif*


Mich würde interessieren, wie man das Zusammensetzen einer SQL-Anweisung gestalten sollte, damit auch jemand, der keinen Text in VBA zusammensetzen kann, eine lauffähige SQL-Anweisung mit dynamischen Anteilen in VBA erstellen kann.


Als Ansatz:
Sql-Template-Text mit Parameter-"Symbolen" ... angelehnt an printf von C++ oder String.Format von .net
Code:

Anm.:
Statt einer Klasse kann auch nur eine Funktion verwendet werden. Die Klasse wird aber flexibler einsetzbar sein.
Die Platzhalter @X und @Y könnte auch nur {0} und{1} oder wie auch immer definiert werden.
Bei diesem Aufbau könnte im ersten Schritt der SQL-Vorlagentext mit deinem Add-In erzeugt werden. Im Add-In kannst dann auch relativ einfach die Funktionsfähigkeit prüfen, da du die Parameter erkennst und durch abgefragte Werte ersetzen kannst.

Für Recordsets gibt es diese Funktionalität schon, wenn man ein DAO.QueryDef oder ADODB.Command verwendet.


Wenn man möchte, könnte man diese Klasse dann auch erweitern, damit auch die Template-SQL-Anweisung über Methoden erzeugt wird. (Diese Variante würde ich allerdings nicht nutzen, da ich lieber einen vollständigen SQL-Text lese.)

mfg
Josef

 

Moin,
Erstmal antworten ...

@markus
Eigentlich dachte ich, dass ganz am Anfang schon angedeutet, - ein einfaches Tool,
das es, vor allen, Anfängern erleichtert, die immer wieder vorgeschlagene Vorgehensweise
- Debug.Print sSQL
- kopieren aus dem Direktfenster (das bekannt sein muss)
- einfügen in eine leere Abfrage
zu erleichtern.

@josef

Also eine extra Klasse wollte ich da nicht noch mit reinbringen.
I.Ü. auf diese Option-Geschichte muss man erst mal kommen

Aber da braucht man das ja auch nicht mehr.

O.K., war mir halt nicht sicher ob es eine technische Bewandnis hat. Dann ändere ich das.

Verstehe ich.
Aber warum wird dann, auch wenn ich einen Namen festlege, keine Abfrage gespeichert? In meiner
ersten Version ging es doch auch.

O.K., habe ich jetzt so gemacht
Code:

*frown.gif* siehe Kommentar. Gibt es evtl. noch eine Einstellung/Option?
Dies
Code:

habe ich so gelassen.

Na ja, wenn du es nicht weisst, ...
Oder ist das ein dezenter Hinweis?

@Eberhard

Die hatte ich, glaub ich, schon soweit verstanden. Nur denke ich, dass ich damit einfach
überfordert bin. Auch im Hinblick auf Eure letzten Posts (s.u.)

Zur "Rückumwandlung" könnte ich mir vorstellen, dass dies

in diese Richtung geht.
Oh, schon überholt. Auch der Kommentar bezügl. Entwicklung/Auslieferung.

Ich mach jetzt erstmal mit dem weiter, was ich jetzt habe; - den Code noch ein bisschen aufräumen,
den Buttons noch einen Tipptext verpassen, es noch mal mit grösseren Abfrage testen und dann ist
für mich erst mal Schicht. Für Anfänger wird's reichen.

Da ich für diesen Post doch einige Zeit benötigt habe, haben eure letzten Posts sich mit diesem
überschnitten. Nachdem ich die jetzt aber noch gelesen habe, muss ich mich leider endgültig "verabschieden".
Die "aufgeräumte" DB stelle ich aber auf jeden Fall noch hier rein, wenn ich sie "fertig" habe.

gruss ekkehard

 

Hallo,

Das war ja nicht meine Absicht.

Dafür ist es gedacht.

Jetzt ist mir aber noch was eingefallen, an das ich eben nicht mehr gedacht hatte.
Und zwar die Verbesserung der Prüfprozedur "GetQueryTyp". Darauf hatte Eberhard ja
schon hingewiesen. Versuche ich auch noch bevor ich's noch mal reinstelle.

gruss ekkehard

 

Du meinst irgendwie erreichen, dass die "Programmierer" sich ja nicht mit der Materie auseinandersetzen müssen.

Besser wäre doch eine Kurzanleitung auf die man sie verweisen könnte.
Im Forum ist so was leider nicht vorgesehen.
So wird halt jedes Thema 100dertmal behandelt.

 

Da würde ich die Prüflogik umstellen. Alles (alle SQL-Anweisungen), was UPDATE, INSERT INTO, INTO, DELETE enthält, müsste Aktionsabfrage sein.
Wenn einer diese geschützen Begriffe als Bezeichner für Felder, Tabellen usw. einsetzt per Maskierung mit eckigen Klammern, dann ist diesem vermutlich nicht zu helfen.
DDL-Anweisungen sind dann zusätzlich auch Aktionsabfragen, dürften aber selten vorkommen, und wer sie schreiben kann, kann auch damit umgehen.

Anfänger, die nicht den Unterschied zwischen Semikolon und Komma oder zwischen Text oder Ganzzahl bei Kriterien sehen, will ich nicht bedienen. Wenn sich aber Hilfeeffekte auch in diese Richtung ausdehnen lassen, ohne großen Zusatzaufwand zu betreiben, so würde ich die gerne mitnehmen. Die Automatismen sollen ja Arbeit abnehmen, nicht zusätzlich erzeugen. Ich habe jedenfalls einige interessante Gedanken aus diesem Thread gezogen, wofür ich mich auch bedanken möchte, so dass ich mich jetzt dem Putzen und Verspeisen der eben eigengeernteten Erdbeeren widmen kann.

Wenn man fünfzigmal die gleiche Frage beantwortet (mit sinkender Begeisterung), ist das doch Anlass genug, einen solchen Fall ausführlich und tiefgründig zu behandeln und die Erläuterung ins Code-Archiv zu stellen. Dann ist der Beitrag, auf den man verweisen kann, bei der Hand. Unter Umständen findet der Leser diesen sogar selbst.

 

Hallo,

@markus

Mit welcher Materie? Dem beschriebenen Vorgehen beim Testen von Strings?
Die Fehler in ihren zusammengesetzten Strings müssen sie doch trotzdem immer noch
selber finden.

Die "Kurzanleitung", wenn du meinst auf die verlinkte zu verweisen, ist in dem Zusammenhang
auch nicht wirklich hilfreich. 1. musst du den Abschnitt über Debug.Print erstmal finden,
und dann geht der 2. auch gar nicht auf die diskutierte Vorgehensweise ein.

@Eberhard
Wenn in deiner Liste nichts fehlt, habe ich das schon (hätte ich als nächstes gepostet
Code:

Noch nicht getestet, sollte aber passen, - oder?

Ansonsten freue ich mich zu einer wertschöpfenden Diskussion angeregt zu haben.

gruss ekkehard
gruss ekkehard

 

Code:

Das wäre nach Deiner Prüflogik eine Auswahlabfrage.


Etwas herbeigezogen: Die Prüfung auf KeinSQL ist nicht überzeugend. SELECT kommt auch in einem Select Case vor, UPDATE und DELETE gibt es als Recordsetmethoden. Wer also irgendwas prüft statt wie erwartet eine SQL-Anweisung, kann auch fehlgehen.

 

Hallo Eberhard,

Alles klar, - hoffe ich *wink.gif*
Also umstellen, erst Aktionsabfragen "ausfiltern" und was übrig bleibt sind Auswahlabfragen.
Versuche ich heute Abend.

Bezügl. "KeinSQL", - können Select Case und Recordsetmethoden sinnvoll in zusammengesetzten
Strings vorkommen?
Ich habe da eher an Filterstrings gedacht. Die kann man zwar nur über das Einfügen in Form/Bericht
per Zwischenablage testen, aber nichts ist vollkommen *wink.gif*
gruss ekkehard

 

Hallo,
Lässt einem ja keine Ruhe.
So sollte jetzt aber richtig sein
Code:

Jetzt brauch ich aber wirklich eine Pause, - das artet ja in Arbeit aus *wink.gif*

gruss ekkehard

 

Hallo!

Weil eine Test-SqlBuilder-Klasse schnell erstellt war, gibt es im Anhang ein Beispiel zum Ansehen.

Im Modul "__0_SqlBuilder_Vorgehensweise" zeige ich eine Vorgehensweise, die aus meiner Sicht den Schreibaufwand bei der Entwicklung vereinfacht und einen lesbaren Code erzeugt.

In 3 Zeilen zusammengefasst:
1. SQL-Vorlagen-Text mit Platzhaltern erstellen (Add-In von Eberhard)
2. Mittels SqlBuilder aus dem Vorlagentext und den Paramterdefinitionen einen SQL-Text generieren
3. Bei Bedarf den fertigen SQL-Text mit DebugPrint von ekkehard ausgeben und prüfen.


Bei folgendem Code würde mich interessieren, wie ihr die Lesbarkeit beurteilt:
Code:

 

O.K., der Zusammenhang KeinSQL und Filter erschließt sich mir nicht automatisch, denn ein Filter ist pures SQL, egal ob Formfilter, Recordsetfilter, Kriterium bei DLookup & Co., nur eben auf diesen notwendigen Anteil gekürzt.

 

Hallo Eberhard,

Ist mir schon klar und ich muss dir auch recht geben. Vor allem weil es genau das vor den
Anfängern verschleiert. *frown.gif*

Aber wie soll man es nennen?
"FilterString" klingt auch irgendwie eingeschränkt. Am Besten würde mir noch "Kriterium"
gefallen. Bin aber für alle Vorschläge offen.

gruss ekkehard

 

Hallo!

Ich stelle die Frage anders: Was willst du kennzeichnen?

Du willst doch folgendes erkennen:
* Aktionsabfragen
* Auswahlabfragen (inkl. Pivot)
* Kein ausführbarer (SQL-)Text
.. um die Sql-Anweisung prüfen zu können.


/edit:
Eine Frage von dir übersah ich:

Das wird wegen der Transaktion sein.

mfg
Josef

 

Einen Filter würde ich Filter nennen. Der Begriff ist immer im gleichen Sinne im Gebrauch, und es ist dann auch offenbar, dass ein Filter für sich alleine nicht ausführbar oder testbar ist, im Zusammenwirken mit einer bekannten Datenbasis dann schon, wenn auch die Vergleichswerte bekannt sind in Datentyp sowie Gestaltung. Das letztere wird aber für die Prüfroutine recht schwierig, und der unerfahrene Entwickler wird Schwierigkeiten haben, bei Anforderung richtige Werte zu übergeben, zumindest keine kleineren Schwierigkeiten, als den Filter gleich richtig zu schreiben.