Office: (Office 2010) Debug.Print

Hallo,
Da Josef so nett ist das AddIn in seine CodeLib-Downloadliste aufzunehmen (auch an
dieser Stelle noch einmal Dank dafür), möchte ich auch nicht versäumen den Link hier
einzustellen.
http://access-codelib.net/download/a...DebugPrint.zip

Ursprünglich für Anfänger konzipiert, die mit Debug.Print irgendwie nichts anfangen
können, muss ich sagen, dass es auch für Entwickler, die damit umgehen können ganz
hilfreich sein kann (wenn man keine bessere Methode kennt/hat). Es spart doch einige
Arbeitschritte.
gruss ekkehard

 

Code:

Bei den meisten sicher nicht, aber bei manchen könnte als Kriterium auch vorkommen ...
Code:

Somit läge nach Deiner Prüfung eine Auswahlabfrage vor.

Verbesserungsvorschlag: Nicht-Aktionsabfragen sind Auswahlabfragen oder Kreuztabellenabfragen und beginnen somit mit SELECT oder TRANSFORM als erstem Wort. Allerdings könnten allen Abfragen noch Parameterdefinitionen vorangestellt werden. Das Ganze würde ich wohl per RegEx lösen wollen, um nicht unzählige Einzelprüfungen anstellen zu müssen.

Code:

... könnte z.B. so aussehen:
Code:

 

Hallo Eberhard,
Habe ich noch nicht verstanden, fehlt mit irgendwie wieder der entscheidende
Klapps auf den Hinterkopf. Die Prozedur hatte ich ja aufgrund deiner früheren
Kritik so geändert und hier auch gepostet. Da waren dann von dir keine Einwände
mehr gekommen. Bei meinen zugegeben nicht so umfangreichen Tests hat das
auch immer geklappt.
Code:

steht doch immer nur im Zusammenhang mit einem übergeordnetem SELECT
oder einer Aktion, oder sehe ich das falsch?
Und wenn's eine Aktion ist, greift doch die Prüfung korrekt,
Code:

wird dann doch gar nicht mehr ausgeführt.
Und TRANSFORM geht doch nicht ohne ein SELECT. (?)
gruss ekkehard

 

Wenn einem etwas auffällt, heißt das noch nicht, dass man in diesem Moment alles im Blick hat.

Grundsätzlich: Das vorhandene Konstrukt wird in den allermeisten Fällen ausreichend sein und richtig arbeiten, zumal wenn man an die Zielgruppe denkt. Da wird es wohl nur einfache Auswahlabfragen geben.

Wenn man aber an Abfragen, also alle Abfragearten in möglichen und nicht nur "üblichen" Gestaltungskombinationen, denkt, reicht es dann nicht aus, nur die einfachen Fälle zu betrachten. Gleiches fällt einem ja auf, wenn man an die Formatierung von Abfragen denkt. Bei geschachtelten Abfragen kommt ein SELECT vielfach vor und ist für sich kein Maßstab für eine hinreichende Identifizierung.

Das Problem ist: Wenn man sich eine einigermaßen allgemeingültige Lösung erarbeiten will, muss man an sehr viel mehr Fälle denken als einem auf dem ersten Blick bewusst ist. Mancher hat ja eine Kreuztabellenabfrage noch nicht mal in SQL-Ansicht gesehen, wie soll man da noch an verschiedene Gestaltungen dieser denken können?
Sowie von sehr weit herangezogen: DDL-Anweisungen wären zusätzliche Aktionsabfragen. Aber wer kennt so etwas und setzt es gar ein?

Code:

... ist genau so ein Filter wie Vorname = 'Egon' und so verwendbar für Formular- und Berichtsfilter oder als Kriterium für Recordset-FindFirst oder Domänenaggregatfunktionen, aber eben nicht ohne weiteres in einem Editor zusammenklickbar und somit unüblich bis unbekannt in dieser Verwendung.


Insgesamt soll das aber keine Kritik an Deiner (Eurer) Leistung sein, sondern nur etwas Stoff für die Version 1.001.
Auch denke ich daran, einiges oder vieles von dieser Lösung mit meinem QueryHelper zu ergänzen bzw. zu kombinieren, aber ob und wann das wird, weiß ich noch nicht. Wahrscheinlich durch diese Rückkopplung sehe ich manche Dinge ein Stück kritischer. Auf der anderen Seite sind interessante Lösungen in Idee und Ausführung vorhanden, dass sich ein Nachdenken erst mal lohnt.
Also erst einmal ein "Gut gemacht".

 

Hallo Eberhard,

War ja nicht bös gemeint.

Das soll mir erstmal auch genügen.

Das stimmt allerdings. Mir fehlt da allerdings doch eine Menge an Erfahrung.

Alles klar, verstanden. Das schaue ich mir auf jeden Fall noch mal an.

Ich habe kein Problem mit Kritik, und von dir schon gar nicht.

Vielen Dank.

gruss ekkehard

 

Hallo!

Ich würde dafür den eventuell enthaltenen Parameter-Abschnitt wegschneiden und dann das erste Wort prüfen (bei select noch "select into" ausschließen).

Wäre es möglich, dass du deinen SQL-Formatierungscode öffentlich machst (oder erstmal nur diese Funktionalität in einem Add-In nutzbar machst - es würde nur die String-Umwandlung ohne visuelle Ausgabe benötigt), damit es im Add-In von Ekkehard verwendet werden kann? Das würde nämlich gut zum Anzeigeformular passen.

mfg
Josef

 

Die SQL-Formatierung selber habe ich dem ACCESS Dependency Checker entnommen, auch noch etwas unfertig, weil die genannte Lösung da einiges verstrickt und meine Vereinfachung sicher verbesserungswürdig ist.

 

Hallo,
Wenn's dann hier wohl doch noch weitergeht, setze ich den Thread mal wieder auf "unerledigt".
Im Rahmen meiner Möglichkeiten arbeite ich auch gerne weiter daran mit.
gruss ekkehard

 

Hallo,
Es lässt einem ja keine Ruhe*wink.gif* . Auch wenn ich mich die letzte Woche nur am
Rande damit beschäftigt habe, möchte ich doch noch einmal auf Eberhards
Hinweis bezügl. Kriteriumsausdrücken (siehe #79) zurückkommen.
Mit der jetzigen Prüfung ist dem wohl nicht bei zu kommen.
Bleibt für mich nur eine neue Funktion CriteriaDebug in das Factory-Modul
einzuführen. Meine Überlegung ging dahin, dass ein Kriterium doch eigentlich nur
eine verkürzte Auswahlabfrage (SELECT) ist. Oder denke ich da wieder zu kurz?
Erster Versuch also
Code:

Das funzt auch soweit, ausser dass im Formular natürlich die ganze, generierte Abfrage gezeigt
wird, und nicht nur der Kriteriumsausdruck. Hat aber auch den Vorteil, dass man über SQL-(Entwurfs)
Ansicht -> Datenblatt gleich prüfen kann, ob überhaupt DS dem Kriterium entsprechen.
Ist das ein brauchbarer Ansatz zur Lösung des Problems?
gruss ekkehard

 

Hallo!

Ich bringe einmal 3 Beispiel, die deren Schema meiner Meinung nach öfter vorkommen wird.
Annahme für beide Varianten: Formular mit Datenquelle, Gefiltert wird über die Filter-Eigenschaft.

Code:
Code:

Beispiel 1:
Formulardatenquelle: TabelleXyz
Zusammengesetzte Filterbedingung: Feld1 = 1 and Feld2 = 'a'

Beispiel 2:
Formulardatenquelle: select * from TabelleXyz where FeldX = True
Zusammengesetzte Filterbedingung: Feld1 = 1 and Feld2 = 'a'

Beispiel 3:
Formulardatenquelle: select A.* from TabelleXyz X inner join TabelleAbc A On A.fiX = X.idX
Zusammengesetzte Filterbedingung: X.Feld1 = 1 and A.Feld2 = 'a'


Variante 1 und 2 wird mit deinem Ansatz funktionieren (eventuell ist eine kleine Anpassung notwendig).
Bei Variante 3 wird der Where-Teil nicht passen, weil die Alias X und A nicht passen.

mfg
Josef

 

Zum Testen (nur Luftcode):

Code:

Auf einen Feldnamen als Parameter würde ich verzichten.

mfg
Josef

 

Hallo Josef,
Danke für deine Antwort und die Beispiele.
An den Code setze ich mich morgen dran.
gruss ekkehard

 

Hallo Josef,
Irgendwie geht's mal wieder nicht voran.
Deinen Code ins Modul einzufügen war kein Problem, und funzt auch soweit.

Folgendes, auf das ich bei der Textanpassung des Startformulars gestossen
bin; - WENN ein Anwender ein Kriterium, wie es von Eberhard gezeigt wurde
Code:

fälschlicherweise mit SqlDebug verwendet, löst der Klick auf cmdOpenSqlQueryDef
den Fehler 3129 (gleicher Text wie im Info-Fenster, - Unzulässige SQL-Anweisung;
'DELETE', ... erwartet) aus beim Versuch .CreateQueryDef auszuführen.
Soweit klar und verständlich für mich.

Überlegung also, wie kann ich den Button in diesem Fall einfach ausschalten?
Das geht IMO nur über die Prüfung auf Code:

.
Nur wie reiche ich diesen Wert von CriteriaDebug bis SetControlEnableMode
durch? Er wird ja sonst durch die vorhandene Prüfung immer wieder als "Auswahl"/
"Aktion" erkannt; - ein Teufelskreis *wink.gif*
Meine Idee dazu wäre eine Public Property in SqlDebugger anzulegen.
Entspräche das in etwa deiner Vorgehensweise? Probiert habe ich es noch nicht, würde
ich aber hinbekommen, denke ich.
Ich würde dies (Fehler vermeiden) auch bevorzugen, denn die zweite Möglichkeit, den
Fehler zu behandeln, habe ich so probiert
Code:

Das funzt in so weit, dass in der unkompilierten DB ganz brav die Fehlermeldung erscheint
mit den gewohnten Möglichkeiten ("Debuggen"/"Beenden").
Beim kompilierten AddIn kommt allerdings die Fehlermeldung aus Access (nicht VBA)
"Sie haben als Einstellung blabla ". Wenn das nicht an einer falschen Umsetzung deiner
Fehlerbehandlung (also an mir) liegt, finde ich das nun für einen Anwender (vor allem der
Zielgruppe) nicht sehr hilfreich.
Frage: Wenn ich an dieser Stelle doch eh nichts anderes mache/machen kann als den
Fehler abzufangen, dann wäre doch eine einfache Msgbox, die ihm die Meldung auch
wirklich anzeigt besser, oder nicht?

gruss ekkhard

 

Hallo!

Das hatte Eberhard in diesem thread doch schon angesprochen, dass dieses Konstrukt von deiner Prüfung als Select-Anweisung ausgegeben wird.
Abhilfe: Prüfung umbauen. *wink.gif*

Die Frage kann ich dir nicht beantworten, da ich nicht verstehe, was du erreichen willst.
Was hat TransferCodeModule mit einer SQL-Query-Prüfung zu tun?
Hast du in einer der übergeordneten Prozeduren eine Fehlerbehandlung, in der du den Fehler auffangen kannst, den du mit Err.Raise auslöst?

mfg
Josef

 

Hallo Josef,

Ja-a, das war doch der Auslöser. Die "Lösung" mit einer zweiten Function,
der dann aber die ursprüngliche Prüfung wieder dazwischen funkt ist aber
wohl auch nicht der Stein der Weisen, wie ich inzwischen einsehen muss.
Habe ich aber erstmal so gelassen, da das mit der Fehlerbehandlung ja
abgehakt ist (siehe unten).
Also

Da hatte ich ja vorher stundenlang davor gesessen und habe immer noch
keine Lösung gefunden. Falls dir was einfällt ...

Nix, hatte nur gedacht ich könnte die Prozedur "RaiseError" zum Testen
zweckentfremden. Habe jetzt aber inzwischen verstanden warum es so
nicht funzte wie gewünscht/erwartet.

Nein, ist ja die Click-Ereignisprozedur. Da fange ich den Fehler an der
Stelle direkt ab und gebe eine Meldung aus.
Thema Fehlerbehandlung also abgehakt. *Smilie

Dann beschäftige ich mich als nächstes mit einer kleinen Erweiterung, die
ich im Kopf habe bezügl. der Ansicht der Abfrage (SQL/Daten). Denn wenn
ich eine korrekte SQL-Anweisung habe, dann interessiert mich die SQL-
Ansicht ja nicht mehr unbedingt, eher doch ob auch die gewünschten DS
geliefert werden, - also direkt in die Datenblattansicht wechseln. In alle
anderen Ansichten kann er dann ja immer noch umschalten.

gruss ekkehard