Office: (Office 2010) Debug.Print

Moin,
Irgendwie habe ich immer wieder das Gefühl, dass Fragesteller anscheinend Probleme mit
dem immer wieder empfohlenen Debug.Print haben. Meine Vermutung geht dahin,
dass sie das Direktfenster nicht kennen, und sich dann wundern, dass nichts passiert.

Deshalb habe ich mich am WE mal hingesetzt um ein "aufgepimptes" Debug.Print zu
basteln, siehe Anhang.
Das besteht aus einem Form (als Ersatz für das Direktfenster) mit 2 Buttons, und einem
Modul mit einer Sub als Ersatz für Debug.Print.
Allerdings bin ich damit noch nicht so wirklich glücklich.
Und zwar geht es um einen Button, der aus dem übergebenen String eine Abfrage erstellt,
um an die Fehlermeldung der JET zu kommen, wenn der String nicht korrekt ist.
Problem dabei,
1. bei Auswahlabfragen bekomme ich die nur, wenn ich die Abfrage fälschlicherweise mit
.Execute String "ausführe", den Fehler abfange und dort die Abfrage per DoCmd.OpenQuery öffne.
2. bei Aktionsabfragen bekomme ich bei korrektem String keine Rückfrage der JET bezügl.
der auszuführenden Aktion, heisst, dass die Abfrage direkt ausgeführt wird.
Und das finde ich nicht wirklich gut. *frown.gif*

Vielleicht mag sich das ja jemand anschauen und mir einen Tipp geben.

Dann hätte ich noch die Frage, wie man an die Menu-Befehle des VB-Editors kommt?
Ich fände es nämlich nicht schlecht, wenn man per Button auch den Code entgültig anhalten
könnte (VBE-Menu Ausführen -> Zurücksetzen). Jetzt ist es so, dass man per Parameter
WindowMode nur entscheiden kann, ob der Code direkt weiterläuft oder erst nach
Schliessen des Forms.

Freue mich über Kritik und Tipps.
gruss ekkehard


P.S. In der DB ist auch eine kleine Tabelle zum Testen dabei.

:)

 

Servus Beaker,
//OT:
"scheinbar" wäre hier der falsch angebrachte Terminus.
"anscheinend" ist der richtige.

"scheinbar" ist so als ob und ist doch nicht so.
"anscheinend" nicht nur so als ob, sondern sehr wahrscheinlich.

Sorry, dass es mich in den Fingern juckte.

 

Kein Problem, kann ich gut mit leben.
Hoffentlich kann ich mir das nun auch merken.

 

Ich würde mal sagen, alles, was das Anzeigen des erzeugten Strings (Entsprechung des Debug.Print) übersteigt, ist recht ambitioniert als Aufgabenstellung.

Optimist, wenn Du an nur einen Fehler glaubst.

Man bekommt aber durchaus Meldungen, wenn der verwendete SQL-String beim Anlegen einer gespeicherte Abfrage nicht korrekt ist. Jedoch wird hierbei die Vielfalt der möglichen Fehler nur teilweise berücksichtigt.

Du könntest hier den Test mit einer Transaktion ummanteln.

Ich halte sehr viel davon, dass man eine erzeugte SQL-Anweisung nicht nur anzeigt, sondern auch anschaut. Eine Formatierung würde eine solche Ansicht sehr unterstützen. Das Ganze würde natürlich nur Sinn machen, wenn der Betrachter auch eine Vorstellung davon hat, wie die korrekte Syntax der Anweisung aussehen müsste.
Code:

In einer Anfügeabfrage sowie in einer Tabellenerstellungsabfrage kommt auch ein SELECT vor, wenn man ein Konstrukt

 

Hallo!

Hast du die End-Anweisung schon probiert?

Prinzip:
Code:

mfg
Josef

 

Hallo,

@josef
Danke, funzt.
End kannte ich gar nicht; - wieder was gelernt.

@Eberhard

Bis jetzt noch nicht *wink.gif*

Na ja, mehrere Fehler kann man ja auf die herkömmliche Weise auch nur einem
nach dem anderen ermitteln. Und man kann ja den String auch im Formular ändern und erneut testen.

"beim Anlegen" meint .CreateQueryDef? Dann sage mir bitte wie.

Hatte ich auch drüber nachgedacht, muss ich mich aber erst wieder einlesen. Wenn's aber nicht einfacher geht, versuche ich das mal.

Auch diese Idee hatte ich Kopf, traue es mir allerdings nicht zu. Da wird es für mich dann ambitioniert.

Ist mir wohl bewusst (s. Kommentar in der Prüfprozedur). Ich schrieb ja auch, dass ich noch nicht ganz glücklich mit der DB bin.
Vielleicht magst du mir ja ein bisschen unter die Arme greifen.

gruss ekkehard

 

Hallo!

Im Anhang ist eine angepasste Variante deines Beispiels.

Ein paar Anmerkungen zum Code:
Wenn du eine Funktion wie IsNumeric(...) siehst, welchen Rückgabewert erwartest du?
Bei deiner IstSql-Funktion wird ein Enum-Wert zurückgegeben. ;-)


Weitere nette Features:
Eine weitere Funktionalität ist mir noch eingefallen, als ich dein Beispiel ansah:
Den umgekehrten Weg gehen ... nicht nur die fertige SQL-Anweisung ansehen, sondern per "Editor" einen Code erstellen, der eine SQL-Anweisung zusammensetzt.

Vorgehensweise:
Im Editor schreibt man die SQL-Anweisung, fügt Platzhalter oder Parameter ein und der Editor erzeugt daraus einen VBA-Code der die Anweisung zusammensetzt.
Im Editor steht:
Code:

Daraus entsteht dann so etwas wie (nur Luftcode):
Code:

.. wenn man dann den Code, der den SqlGenerator verwendet, öfter gesehen hat, wird man den Editor gar nicht mehr verwenden. *wink.gif*

mfg
Josef

 

Hallo Josef,
Danke erstmal. Kann mich allerdings erst morgen intensiv damit beschäftigen.

Ja, Benamsung hab' ich es nicht so *frown.gif* . Werde sie umbenennen, - "GetStringTyp" sollte treffender sein.

Bezügl. "Editor"; - jetzt wird's aber wirklich ambitioniert. Geht aber für meine Begriffe auch schon weit
über die ursprüngliche Idee hinaus.

Man wird sehen, - ich bleib dran.

gruss ekkehard

 

Hallo Josef,
Mann, da bleiben ja keine Wünsche offen. Ausser vielleicht Eberhards *wink.gif* , aber daran
versuche ich mich auch noch.

Benamsung der Prüfprozedur und der Enum habe ich schon geändert, - heissen jetzt
"GetQueryTyp" und "QueryTyp".

Ich hätte aber noch ein paar Fragen eher grundsätzl. Natur.
1. Macht es Sinn das ErrorTrapping in das Modul zu verlagern? Hat ja mit dem Form an
sich nichts zu tun.
2. Warum deklarierst du m_CurrentErrorTrapping als Long und nicht direkt als
ErrorTrapping?
3. Ist es i.Ü. nötig beim Zugriff auf die Enums diese komplett zu referenzieren, oder ist
das Stilsache bezügl. Lesbarkeit?

Und dann noch dies
Code:

im Zusammenhang hiermit
Code:

Hier habe ich Verständnisprobleme und hänge fest.
Es wird ja ein temporäres QueryDef-Objekt angelegt, dass dann mit Ende der Prozedur
seine Gültigkeit verliert. Trage ich einen Namen ein wird es trotzdem nicht als Abfrage
gespeichert. Das war in meiner ersten Version nicht so. Wird das durch das .RollBack
verhindert?
Wie kann ich die Abfrage dann über den Button öffnen?
Oder muss ich es hier explizit erst der QueryDefs-Auflistung hinzufügen?
Trage ich jeweils einen Namen ein, kommt beim Klicken der Fehler 7874, Access kann das
Objekt "Name" nicht finden.

In der Hoffnung nicht wieder das Offensichtliche übersehen zu haben, bedanke ich mich
schon mal im Voraus für deine, immer lehrreichen, Hinweise.

gruss ekkehard

 

Hallo!

Falls du die Prozeduren meinst, die das ErrorTrapping ändern, dann könnte man diese schon in ein Modul verlagern. Es sollte meiner Meinung nach nur nicht dauerhaft geändert werden.

wenn du das vereinheitlichen willst, würde ich es so lösen:

Code:

Anm.: diese Vorgehensweise ist übrigens nur während der Entwicklung erforderlich. Bei einer mde/accde ist das nicht mehr notwendig, da wird man "bei jedem Fehler anhalten" nicht haben wollen.

Weil ich es übersehen habe, zu ändern.
Anm.: zuerst definierte ich die m_CurrentErrorTrapping-Variable, später ergänzte ich das Enum, da ich es im Code besser lesbar fand. *wink.gif*

Ich schreibe es meist mit der Enum-Bezeichnung, da ich diese sicher kenne und dann kann ich den Rest mit Intellisense auswählen.
Nebenbei vermeidet man so auch Konflikte bei Namensgleichheit, falls diese einmal vorkommen sollte.


Code:

Das temporäres QueryDef ist Absicht, damit nicht irrtümlich ein bestehendes QueryDef überschrieben wird.


Code:

Genau. Du musst erst ein QueryDef erzeugen.
Vielleicht gibt es auch eine Möglichkeit ein QueryDef im Entwurfsmodus zu erzeugen, das nicht gespeichert ist.

mfg
Josef

 

\@ekkehard,
was willst du mit dem Projekt erreichen?

 

Ich hänge mich einfach mal in dieses Thema mit einer eigenen Frage rein, da sie das vorhandene Thema tangiert (und ich ekkehard meine Gedanken bzw. Anforderungen bekannt machen will):
Ich habe ein halbfertiges liegengebliebenes Projekt namens QueryHelper. Das ist ein Formular, das jede Abfrage des aktuellen Projektes (bei Auswahl) formatiert anzeigt. Neben einer besseren Übersicht gegenüber der SQL-Ansicht wird u.a. das Erstellen komplexerer Abfragen erleichtert.

Daneben kann man auch Abfragen in der Textbox des Formulars selber schreiben oder Abfragen aus dem Forum verarbeiten, also solche, wo man nicht die entsprechenden Tabellen dahinter verfügbar hat.

Neben Suchen&Ersetzen ist dort auch eine unmittelbare Erzeugung eines VBA-tauglichen Strings in Varianten möglich. Aus ...
Code:

wird da z.B.
Code:

Jetzt kommt der Berührungspunkt zum Debug.Print. Die gezeigten Codeteile liegen als Text in einer Textbox vor. Wie kann ich die analog zum Debug.Print wieder in eine pure SQL-Anweisung verwandeln? Das also so, dass der VBA-Editor wirkt und ich nicht durch eigene Maßnahmen meine "Zusätze" wieder entferne.

Momentan fällt mir nur ein, im VBA-Editor eine entsprechende Prozedur anzulegen bzw. zu editieren und da den String verarbeiten zu lassen.
Geht das auch anders / eleganter? Das Projekt soll eigentlich als Add-In enden, und da würde man dann auch je nach Auslieferung auf einen gesperrten Editor treffen können.

Im Anhang ein Ausschnitt des Formulars zu Veranschaulichung.

 

Hallo!

Ich stelle einmal eine Gegenfrage: Warum muss aus dem VBA-Text ein SQL-Text werden?
Ich würde eine Zischenschicht einziehen, die die SQL-Anweisung je nach Bedarf ausgeben kann.

So ähnlich wie bereits oben erwähnt:
Code:

.. man könnte bei Bedarf (Z. B. für dynamische Filter o. ä.) auch direkt diesen QueryBuilder-Code in VBA übernehmen.

Soll das nur ein Entwickler-Add-In oder auch ein Add-In für fertige Anwendungen werden? (Bei ersterem hat man eigentlich keinen gesperrten VBA-Editor, auch wenn das Add-In als mde/accde ausgeliefert wird.)

mfg
Josef

 

Ja, nur dieses.

Gedanke ist, den aus der SQL-Anweisung erzeugten VBA-Text auf Lauffähigkeit als Abfrage testen zu können, analog der oben gezeigten Lösung zu sDebugPrint.
Natürlich speichere ich die SQL-Anweisung vor Wandlung in VBA-Text zwischen und kann das Ganze zurücksetzen. Das ist aber nicht das Gleiche, als wenn VBA meine Anweisung verarbeitet.
Die Berücksichtigung von eingelagerten Funktionen wie DateAdd, DCount usw. mit ihrer besonderen Syntax funktioniert schon, die Berücksichtigung von Parametern mit der entsprechenden Formatierung für SQL wäre dann ein weiterer denkbarer Schritt, wobei ich aber dann auch eingesetzte Anteile wie Feld IN ('eins', 'zwei', 'drei') berücksichtigt sehen wollte.

Da ich dann an richtige Abfragen denke - dsie gezeigte einfache dient nur der kurzen Darstellung - mit mehrfachen JOIN's, Schachtelungen, Inkonsistenzprüfungen, Kriterien auch mit EXISTS- und IN-Konstrukten, Parametern auch in tieferen Ebenen und ich dabei nicht auf Auswahlabfragen beschränkt sein möchte, scheint mir das Einziehen der genannten Zwischenschicht als viel zu komplex in Ansatz und Umsetzung. Die dazu gezeigten Beispiele zum SqlGenerator auf access-codelib sind da als Beispiel noch weit entfernt.
Ich schreibe da lieber die SQL-Anweisung unmittelbar.

 

So mache ich das auch - allerdings mit dem Vorteil, dass ich die komplexeren SQL-Anweisung im SQL-Server-Managementstudio schreibe und in VBA im Prinzip nur einfache Anweisungen wie "select ... from .. where" oder "exec schema.Prozedur .." nutze. *wink.gif*

Komplex ist es nicht. Es ist nur viel Schreibarbeit.
Subselects & Co. sind durch Klassen gut abgrenzbar.

Ich persönlich finde allerdings die Anwendung so einer Klassenstruktur schlechter lesbar, als direkten SQL-Text in VBA.

Code:

ist für mich besser lesbar als
Code:

Verstehe ich dich richtig: wu willst nicht den erzeugten SQL-Text kopieren sondern direkt den VBA-Code, welcher dann vom Add-In ausgeführt werden soll, um z. B. die enthaltenen Variablen usw. mit unterschiedlichen (im Add-In anzugebenden) Werte testen zu können?

Prinzip:
Code:

Das Add-In erkennt, dass TabName und DatumswertAlsSqlText Variable sind und bietet eine Möglichkeit an, diese Variablen im Add-In auf einen Wert einzustellen, um die Anweisung zu testen.

mfg
Josef